[Freeipa-users] SSSD bug found? FreeIPA vs SSSD

[Alexander Bokovoy]

On to, 09 maalis 2017, Jakub Hrozek wrote:
>On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
>> Hola,
>>
>> On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd
>> (via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org
>> -> name.org
>>
>> I've seen some interesting behaviour.
>>
>> Being part of a large organisation with a smaller nix environment and a
>> larger Windows environment we see all the best of odd AD management
>> behaviour (eg spaces in usernames...).
>>
>> Turns out some of the groups in AD have an @ symbol in them.
>>
>> The behavioural difference we see is: given userA in group "name @ of
>> group" that on the FreeIPA server:
>>
>> [root at vmpr-freeipa.unix.name.org ~]# id userA at name.org
>>
>> works as expected.
>>
>> But on a client
>>
>> [root at vmpr-linuxclient1.unix.name.org ~]# id userA at name.org
>>
>> returns nothing.
>
>Yes, it is a know issue:
>    https://pagure.io/SSSD/sssd/issue/3219
>
>There were some users who reported this works better with a modified
>re_expression:
>    re_expression = ((?P<name>.+)@(?P<domain>[^@]+$))
>but I agree we should fix this by default. However, the fix must be done
>at both the SSSD level and the IPA extdom plugin, which also searches
>for the @-sign in the user and group names.
Luckily, a change for extdom plugin seem to be straightforward -- search
for the *last* occurence of the domain separator, not the first one. We
had a similar issue with nfs idmapd code too.

-- 
/ Alexander Bokovoy
-------------- next part --------------
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index e629247..7c67fb7 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -515,7 +515,7 @@ int pack_ber_user(struct ipa_extdom_ctx *ctx,
     char *short_user_name = NULL;
 
     short_user_name = strdup(user_name);
-    if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+    if ((locat = strrchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
         if (strcasecmp(locat+1, domain_name) == 0  ) {
             locat[0] = '\0';
         } else {
@@ -626,7 +626,7 @@ int pack_ber_group(enum response_types response_type,
     char *short_group_name = NULL;
 
     short_group_name = strdup(group_name);
-    if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+    if ((locat = strrchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
         if (strcasecmp(locat+1, domain_name) == 0  ) {
             locat[0] = '\0';
         } else {
@@ -901,7 +901,7 @@ static int handle_sid_or_cert_request(struct ipa_extdom_ctx *ctx,
         goto done;
     }
 
-    sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR);
+    sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR);
     if (sep == NULL) {
         set_err_msg(req, "Failed to split fully qualified name");
         ret = LDAP_OPERATIONS_ERROR;
@@ -1023,7 +1023,7 @@ static int handle_name_request(struct ipa_extdom_ctx *ctx,
     char *buf = NULL;
     struct sss_nss_kv *kv_list = NULL;
 
-    if (strchr(name, SSSD_DOMAIN_SEPARATOR) == NULL) {
+    if (strrchr(name, SSSD_DOMAIN_SEPARATOR) == NULL) {
         ret = asprintf(&fq_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR,
                                            domain_name);
     } else {