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

[Jakub Hrozek]

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.
> 
> We believe it is because of the group with the @ in the name.
> 
> The AD management team agreed to change the name of one group with an @ in
> it's name, and that has solved the problem - id userA at name.org now works on
> the sssd client.
> 
> Putting aside the critiques of having an @ in a group name, I believe that
> if there isn't a bug, there is at least an inconsistency, between how
> FreeIPA and sssd handle this situation.
> 
> This was a guess based on seeing this in the logs:
> 
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(objectClass=ipaUserOverride)(uid=awong))][cn=Default Trust
> View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_parse_entry]
> (0x1000): OriginalDN:
> [ipaanchoruuid=:SID:S-1-5-21-55386287-1424373824-1154838474-83519,cn=Default
> Trust View,cn=views,cn=accounts,dc=unix,dc=name,dc=org].
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no
> errmsg set
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_send]
> (0x0400): Executing extended operation
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_done]
> (0x0400): ldap_extended_operation result: Success(0), (null).
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> ...
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain unix.name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state]
> (0x1000): Domain name.org is Active
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]] [add_v1_user_data]
> (0x0040): find_domain_by_name failed.
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [s2n_response_to_attrs] (0x0040): add_v1_user_data failed.
> (Wed Mar  8 12:03:02 2017) [sssd[be[unix.name.org]]]
> [ipa_s2n_get_user_done] (0x0040): s2n_response_to_attrs failed.
> 
> 
> The last three lines tipped off a colleague who was debugging why this
> userA couldn't login to anything.
> 
> Since then we have created IPA over rides for the groups with @ symbols in
> them. This also works as a solution. It's not our preferred solution, but
> we are users, not managers, of the AD system.
> 
> Cheers
> 
> L.
> 
> 
> 
> 
> 
> ------
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project