Red Hat Bugzilla – Bug 1520984
getent output is not showing home directory for IPA AD trusted user
Last modified: 2018-04-10 13:19:42 EDT
Description of problem: IPA server with AD trust setup is showing AD users homedir as root (/) Version-Release number of selected component (if applicable): [root@qe-blade-01 ~]# rpm -qa ipa-server sssd ipa-server-4.5.4-6.el7.x86_64 sssd-1.16.0-9.el7.x86_64 [root@qe-blade-01 ~]# echo <XXXXX> | ipa trust-add ipaad2016.test --admin Administrator --range-type=ipa-ad-trust --password --two-way=True ----------------------------------------------- Re-established trust to domain "ipaad2016.test" ----------------------------------------------- Realm name: ipaad2016.test Domain NetBIOS name: IPAAD2016 Domain Security Identifier: S-1-5-21-813110839-3732285123-1597101681 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified [root@qe-blade-01 ~]# service sssd stop; rm -rf /var/lib/sss/{db,mc}/*; service sssd start Redirecting to /bin/systemctl stop sssd.service Redirecting to /bin/systemctl start sssd.service [root@qe-blade-01 ~]# getent passwd 'IPAAD2016\Administrator' administrator@ipaad2016.test:*:1577600500:1577600500:Administrator:/: [root@qe-blade-01 ~]# grep homedir /etc/sssd/sssd.conf homedir_substring = /home How reproducible: 100% Steps to Reproduce: 1. Setup AD server with user aduser 2. Setup IPA server with trust to AD 3. getent passwd 'AD.DOMAIN\aduser' Actual results: homedir is / Expected results: homedir is /home/AD.DOMAIN/aduser Additional info: Attached sssd_log
Created attachment 1363234 [details] sssd log
Is there a test setup where we can poke at the issue?
(In reply to Jakub Hrozek from comment #4) > Is there a test setup where we can poke at the issue? Sure, I will setup and share machine details ASAP.
Failing with latest sssd build (sssd-1.16.0-10) [root@auto-hv-02-guest04 ~]# rpm -qa sssd sssd-1.16.0-10.el7.x86_64 [root@auto-hv-02-guest04 ~]# grep homedir /etc/sssd/sssd.conf homedir_substring = /home [root@auto-hv-02-guest04 ~]# getent passwd 'IPAAD2016\Administrator' administrator@ipaad2016.test:*:1577600500:1577600500:Administrator:/:
(In reply to Varun Mylaraiah from comment #9) > Failing with latest sssd build (sssd-1.16.0-10) > > [root@auto-hv-02-guest04 ~]# rpm -qa sssd > sssd-1.16.0-10.el7.x86_64 > > [root@auto-hv-02-guest04 ~]# grep homedir /etc/sssd/sssd.conf > homedir_substring = /home > > [root@auto-hv-02-guest04 ~]# getent passwd 'IPAAD2016\Administrator' > administrator@ipaad2016.test:*:1577600500:1577600500:Administrator:/: I think this is expected since the bug status is still "NEW". When the patch makes its way to RHEL, the bug status will be MODIFIED, so you'll know you should re-run the test.
Upstream ticket: https://pagure.io/SSSD/sssd/issue/3599
master: * dc49e07a0dbbbf3d69d09a7c6f236d82c86c7def
Verified # rpm -qa ipa-server sssd ipa-server-4.5.4-6.el7.x86_64 sssd-1.16.0-11.el7.x86_64 # getent passwd 'IPAAD2016\Administrator' administrator@ipaad2016.test:*:1577600500:1577600500:Administrator:/home/ipaad2016.test/administrator:
Is it possible this one is still around? I saw this today: [root@seceng-idm-1 sssd]# getent passwd ipacertmultiuser2@ipaadcs12r2.test ipacertmultiuser2@ipaadcs12r2.test:*:1664401128:1664401128:ipacert multiuser2:/: [root@seceng-idm-1 adcertmultiuser2]# ldapsearch -o ldif-wrap=no -xLLL \ > -D "$AD_ADMIN" -w Secret123 \ > -h idm-qe-ipa-win7.ipaadcs12r2.test \ > -b "cn=ipacert multiuser2,cn=Users,$AD_BASEDN" \ > "(objectClass=*)" dn: CN=ipacert multiuser2,CN=Users,DC=ipaadcs12r2,DC=test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: ipacert multiuser2 sn: multiuser2 givenName: ipacert distinguishedName: CN=ipacert multiuser2,CN=Users,DC=ipaadcs12r2,DC=test instanceType: 4 whenCreated: 20170721231218.0Z whenChanged: 20171219173326.0Z displayName: ipacert multiuser2 uSNCreated: 28729 uSNChanged: 49747 name: ipacert multiuser2 objectGUID:: b6ElpQknNUqwa49aB/DGzg== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 131455562822558217 lastLogoff: 0 lastLogon: 131581788947074802 pwdLastSet: 131451523387232862 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAA8cNtfeS1TwfZ8ZuNaAQAAA== accountExpires: 9223372036854775807 logonCount: 37 sAMAccountName: ipacertmultiuser2 sAMAccountType: 805306368 userPrincipalName: ipacertmultiuser2@ipaadcs12r2.test objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ipaadcs12r2,DC=test altSecurityIdentities: X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1 dSCorePropagationData: 20170721231218.0Z dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 131574733155171437 [root@seceng-idm-1 ~]# rpm -q sssd sssd-1.16.0-14.el7.x86_64 It should be noted that some point after a restart and cache reset it's working as expected.
(In reply to Scott Poore from comment #15) > Is it possible this one is still around? > > I saw this today: > > [root@seceng-idm-1 sssd]# getent passwd ipacertmultiuser2@ipaadcs12r2.test > ipacertmultiuser2@ipaadcs12r2.test:*:1664401128:1664401128:ipacert > multiuser2:/: > > [root@seceng-idm-1 adcertmultiuser2]# ldapsearch -o ldif-wrap=no -xLLL \ > > -D "$AD_ADMIN" -w Secret123 \ > > -h idm-qe-ipa-win7.ipaadcs12r2.test \ > > -b "cn=ipacert multiuser2,cn=Users,$AD_BASEDN" \ > > "(objectClass=*)" > dn: CN=ipacert multiuser2,CN=Users,DC=ipaadcs12r2,DC=test > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: user > cn: ipacert multiuser2 > sn: multiuser2 > givenName: ipacert > distinguishedName: CN=ipacert multiuser2,CN=Users,DC=ipaadcs12r2,DC=test > instanceType: 4 > whenCreated: 20170721231218.0Z > whenChanged: 20171219173326.0Z > displayName: ipacert multiuser2 > uSNCreated: 28729 > uSNChanged: 49747 > name: ipacert multiuser2 > objectGUID:: b6ElpQknNUqwa49aB/DGzg== > userAccountControl: 66048 > badPwdCount: 0 > codePage: 0 > countryCode: 0 > badPasswordTime: 131455562822558217 > lastLogoff: 0 > lastLogon: 131581788947074802 > pwdLastSet: 131451523387232862 > primaryGroupID: 513 > objectSid:: AQUAAAAAAAUVAAAA8cNtfeS1TwfZ8ZuNaAQAAA== > accountExpires: 9223372036854775807 > logonCount: 37 > sAMAccountName: ipacertmultiuser2 > sAMAccountType: 805306368 > userPrincipalName: ipacertmultiuser2@ipaadcs12r2.test > objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ipaadcs12r2,DC=test > altSecurityIdentities: X509:<I>O=TESTRELM.TEST,CN=Certificate > Authority<S>O=TESTRELM.TEST,CN=ipauser1 > dSCorePropagationData: 20170721231218.0Z > dSCorePropagationData: 16010101000000.0Z > lastLogonTimestamp: 131574733155171437 > > > [root@seceng-idm-1 ~]# rpm -q sssd > sssd-1.16.0-14.el7.x86_64 > > It should be noted that some point after a restart and cache reset it's > working as expected. I guess this is a different issue. First I was going to say that this can be related to sssd sometimes reading the data from the global catalog and sometimes reading the data from LDAP, but since you're not using the POSIX attributes, it's not the case. I'm afraid I can't say more without either looking at the logs or poking at a system which reproduces this. Could you please send me either? Just please note that I'm starting my Christmas vacation tomorrow, on Thursday Dec-22 and won't be available until Jan-4.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:0929