Bug 1520984
Summary: | getent output is not showing home directory for IPA AD trusted user | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Varun Mylaraiah <mvarun> | ||||
Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> | ||||
Status: | CLOSED ERRATA | QA Contact: | ipa-qe <ipa-qe> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.5 | CC: | enewland, fidencio, grajaiya, jhrozek, ksiddiqu, lslebodn, mkosek, mvarun, mzidek, pbrezina, sgoveas, spoore, sssd-maint, tscherf | ||||
Target Milestone: | rc | Keywords: | Regression | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | sssd-1.16.0-11.el7 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-04-10 17:18:11 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Varun Mylaraiah
2017-12-05 15:06:24 UTC
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:*: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:*: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:*: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
ipacertmultiuser2:*: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
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 > ipacertmultiuser2:*: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 > 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 |