<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hola,<br><br></div>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. <a href="http://unix.name.org">unix.name.org</a> -> <a href="http://name.org">name.org</a><br><br>I've seen some interesting behaviour. <br><br></div>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...). <br><br></div>Turns out some of the groups in AD have an @ symbol in them. <br><br></div>The behavioural difference we see is: given userA in group "name @ of group" that on the FreeIPA server:<br><br></div>[<a href="mailto:root@vmpr-freeipa.unix.name.org">root@vmpr-freeipa.unix.name.org</a> ~]# id <a href="mailto:userA@name.org">userA@name.org</a><br><br></div>works as expected.<br><br></div>But on a client <br><br></div>[<a href="mailto:root@vmpr-linuxclient1.unix.name.org">root@vmpr-linuxclient1.unix.name.org</a> ~]# id <a href="mailto:userA@name.org">userA@name.org</a><br><br></div>returns nothing.<br><div><div><div><div><div><div><div><div><br></div><div>We believe it is because of the group with the @ in the name. <br><br></div><div>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 <a href="mailto:userA@name.org">userA@name.org</a> now works on the sssd client.<br></div><div><br></div><div>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.<br><br></div><div>This was a guess based on seeing this in the logs:<br><br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [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].<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [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].<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sss_domain_get_state] (0x1000): Domain <a href="http://unix.name.org">unix.name.org</a> is Active<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sss_domain_get_state] (0x1000): Domain <a href="http://name.org">name.org</a> is Active<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null).<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sss_domain_get_state] (0x1000): Domain <a href="http://unix.name.org">unix.name.org</a> is Active<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sss_domain_get_state] (0x1000): Domain <a href="http://name.org">name.org</a> is Active<br>...<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sss_domain_get_state] (0x1000): Domain <a href="http://unix.name.org">unix.name.org</a> is Active<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sss_domain_get_state] (0x1000): Domain <a href="http://name.org">name.org</a> is Active<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sss_domain_get_state] (0x1000): Domain <a href="http://unix.name.org">unix.name.org</a> is Active<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [sss_domain_get_state] (0x1000): Domain <a href="http://name.org">name.org</a> is Active<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [add_v1_user_data] (0x0040): find_domain_by_name failed.<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [s2n_response_to_attrs] (0x0040): add_v1_user_data failed.<br>(Wed Mar 8 12:03:02 2017) [sssd[be[<a href="http://unix.name.org">unix.name.org</a>]]] [ipa_s2n_get_user_done] (0x0040): s2n_response_to_attrs failed.<br></div><div><br><br></div><div>The last three lines tipped off a colleague who was debugging why this userA couldn't login to anything.<br><br></div><div>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. <br><br></div><div>Cheers<br><br></div><div>L.<br></div><div><br><br></div><div><br></div><div><br></div><div><br clear="all"><div><div><div><div class="gmail_signature"><div dir="ltr"><div>------<br>The most dangerous phrase in the language is, "We've always done it this way."<br><br>- Grace Hopper<br></div></div></div></div> </div></div></div></div></div></div></div></div></div></div></div>