I'm sorry, but I can't reproduce either of the cases locally. Would you mind adding an example of the user's samaccountname attribute?

As a matter of fact, AD seems to canonicalize the samaccountname with the at-sign in it except the UPN:

# atsign, Users, win.trust.test
dn: CN=atsign,CN=Users,DC=win,DC=trust,DC=test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: atsign
givenName: atsign
distinguishedName: CN=atsign,CN=Users,DC=win,DC=trust,DC=test
instanceType: 4
whenCreated: 20160818092348.0Z
whenChanged: 20160818092348.0Z
displayName: atsign
uSNCreated: 291101
uSNChanged: 291106
name: atsign
objectGUID:: HlKZvNTPq0aMFSirD2b2fQ==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 131159858281367958
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA7MyrD9WWJf4D7yaHNwwAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: at_sign
sAMAccountType: 805306368
userPrincipalName: at@sign@win.trust.test
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=win,DC=trust,DC=test
dSCorePropagationData: 16010101000000.0Z

The lookup works with the canonicalized name being returned, so I guess the UPN matches on the server side:

getent passwd at@sign@win.trust.test
at_sign:*:300403127:300403127:atsign:/home/win.trust.test/at_sign:/bin/zsh

And this is how my user with a space in their name looks like:

# space user, Users, win.trust.test
dn: CN=space user,CN=Users,DC=win,DC=trust,DC=test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: space user
sn: user
givenName: space
distinguishedName: CN=space user,CN=Users,DC=win,DC=trust,DC=test
instanceType: 4
whenCreated: 20160818091839.0Z
whenChanged: 20160818091839.0Z
displayName: space user
uSNCreated: 291084
uSNChanged: 291089
name: space user
objectGUID:: d/eZa4JxRk6Q2isvUpmvRQ==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 131159855193086920
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAA7MyrD9WWJf4D7yaHNgwAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: space user
sAMAccountType: 805306368
userPrincipalName: space user@win.trust.test
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=win,DC=trust,DC=test
dSCorePropagationData: 16010101000000.0Z

Here the lookups just works:

getent passwd "space user"@win.trust.test
space user:*:300403126:300403126:space user:/home/win.trust.test/space user:/bin/zsh

Hmm, more questions: did either of the two worked before you went with 1.14 on the client side? At least whatever user turns up on the server side /should/ be returned to the client side as well.

1.14.0-3 is quite buggy.
Are you able to reproduce with latest 1.13.x?
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/

cc: => lslebodn

Jakub,

First let me apologize; you have been fantastically responsive and supportive for us on a wide range of issues as we move forward with our IPA/SSSD implementation; I hate to waste your time. I have to backpedal a little bit. I AM in fact able to lookup a user ID with a space in the name. I do not believe this to be a bug, rather an error in my analysis (I apologize for this).

That being said, I believe the inability to lookup a user with an @ sign in a group name they are a member of to still be an issue in an sssd 1.14 client. Your test apparently tests for an @ in the username, not in the group name that the user is a member of. Here is an example of something that I think will break the ability to enumerate a user in sssd 1.14:

User’s login name “happyuser”[[BR]]
User’s domain name “mydomain"[[BR]]
User’s a member of group 1: “my@happyusers”[[BR]]
User’s a member of group 2: admins[[BR]]

NOTE: happyusers (a substring of group1’s name) is NOT the domain name. If I lookup this user on a DC, the output will look like:

id happyuser

uid=788657006(happyuser@mydomain) gid=788657006(happyuser@mydomain) groups=788657006(admins@mydomain),788600513(my@happyusers)

Note that the group name for my@happyusers is NOT my@happyusers@mydomain, and that happyusers is NOT a domain. This is the output I see on the DC with that configuration.

Now, if I try to lookup that same user on the client (i.e. non-DC), it fails. lslebodn, I do not have a 1.13 client available to test this, and I am going on vacation until 8/24, but will give this some attention when I get back.

Thank you for your help.

Best,

Dan

_comment0: Jakub,

First let me apologize; you have been fantastically responsive and supportive for us on a wide range of issues as we move forward with our IPA/SSSD implementation; I hate to waste your time. I have to backpedal a little bit. I AM in fact able to lookup a user ID with a space in the name. I do not believe this to be a bug, rather an error in my analysis (I apologize for this).

That being said, I believe the inability to lookup a user with an @ sign in a group name they are a member of to still be an issue in an sssd 1.14 client. Your test apparently tests for an @ in the username, not in the group name that the user is a member of. Here is an example of something that I think will break the ability to enumerate a user in sssd 1.14:

User’s login name “happyuser”
User’s domain name “mydomain"
User’s a member of group 1: “my@happyusers”
User’s a member of group 2: admins

NOTE: happyusers (a substring of group1’s name) is NOT the domain name. If I lookup this user on a DC, the output will look like:

id happyuser

uid=788657006(happyuser@mydomain) gid=788657006(happyuser@mydomain) groups=788657006(admins@mydomain),788600513(my@happyusers)

Note that the group name for my@happyusers is NOT my@happyusers@mydomain, and that happyusers is NOT a domain. This is the output I see on the DC with that configuration.

Now, if I try to lookup that same user on the client (i.e. non-DC), it fails. lslebodn, I do not have a 1.13 client available to test this, and I am going on vacation until 8/24, but will give this some attention when I get back.

Thank you for your help.

Best,

Dan Sullivan

=> 1471559296678233

OK, I can reproduce this, but I'm not sure it's a bug in the code, perhaps a bug in our default re_expression value. This is the part that matches:

((?P<name>[^@]+)@(?P<domain>.+$))

What is says is that the name cannot contain @ and the domain is anything after the @. I tried changing to:

re_expression = ((?P<name>.+)@(?P<domain>[^@]+$))

but so far I ran into issues even on the server..

Looking at extop code, this might need fixes on the extop side as well, because that codebase is also looking for the first @ often, just grepping for strchr reveals a few.

I doubt that name of group "my@happyusers" could ever worked in IPA environment. I would not recommend to use it. I would prefer to close this bug as WON'T FIX.

Yes, it never worked, but if it's a correct name in AD environment, we can't just close the bug. But after spending some time, I don't think it easily solvable.

I appreciate you verifying the existing of this issue, Jakub.

lslebodn, the name of the groups where we see this is where it is used in an ACL in an exchange environment, i.e a group was created with the name "delegation for admin@department mailbox" or something of that nature. For us, it's not really a problem that the group cannot be enumerated, rather that being a member of it prevents the user from being enumerated.

This is really an edge case in our environment, impacting a very small number of users. It is not introducing a critical path problem for us, although it was somewhat difficult to diagnose, and could cause confusion for other users. I am reporting this issue for due diligence and to let the sssd team know about it.

Since this can be reproduced internally, I don't intend on spending time on it doing testing with 1.13 as previously discussed.

Dan

Replying to [comment:9 dsulli99]:

I appreciate you verifying the existing of this issue, Jakub.

lslebodn, the name of the groups where we see this is where it is used in an ACL in an exchange environment, i.e a group was created with the name "delegation for admin@department mailbox" or something of that nature. For us, it's not really a problem that the group cannot be enumerated, rather that being a member of it prevents the user from being enumerated.

This is really an edge case in our environment, impacting a very small number of users.
So, would it be a big problem to rename the group?

No, renaming the group is not a problem. The main issue is that we are in a federated OU AD environment and have a large number of people provisioning groups across a large number of OUs. This particular bug is problematic because;

1) it is difficult to ascertain when it is actually presenting itself
2) it can take an existing user that can be enumerated fine, and then subsequently break it. this basically allows any AD OU administrator to inadvertently introduce breaking changes into our IPA environment.

This isn't the end of the world. Like I said it is only impacting a small number of our users. As a workaround we can attempt a rename of all groups with @ names in them, and then try to proactively monitor AD for any group that are created or renamed to include an @ sign in them (currently this isn't planned).

This ticket is mostly a due diligence on our part to make your aware of the issue. Of course we would like to see this issue fixed but we won't do much more about it more than opening this ticket. Thank you for your time and attention.

_comment0: No, renaming the group is not a problem. The main issue is that we are in a federated OU AD environment and have a large number of people provisioning groups across a large number of OUs. This particular bug is problematic because;

1) it is difficult to ascertain when it is actually presenting itself
2) it can take an existing user that can be enumerated fine, and then subsequently break it. this basically allows any AD OU administrator to inadvertently introduce breaking changes into our IPA environment.

This isn't the end of the world. Like I said it is only impacting a small number of our users. As a workaround we attempt a rename of all groups with @ names in them, and then try to proactively monitor AD for any group that are created or renamed to include an @ sign in them (currently this isn't planned).

This ticket is mostly a due diligence on our part to make your aware of the issue. Of course we would like to see this issue fixed but we won't do much more about it more than opening this ticket. Thank you for your time and attention. => 1472147330827974

Since fixing this issue properly requires work across several components, I'm moving to deferred for the time being.

milestone: NEEDS_TRIAGE => SSSD Deferred

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1375575 (Red Hat Enterprise Linux 7)

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=1375575 1375575]

Closing as a duplicate of #3219, mostly because that one has more suitable description

resolution: => duplicate
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4174

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.