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: [r...@vmpr-freeipa.unix.name.org ~]# id us...@name.org works as expected. But on a client [r...@vmpr-linuxclient1.unix.name.org ~]# id us...@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 us...@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