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

[Lachlan Musicman]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170309/ab9e509e/attachment.htm>