[SSSD-users] SSSD with AD provider - can't obtain group information in subdomain

Jakub Hrozek jhrozek at redhat.com
Wed Aug 6 17:59:24 UTC 2014


On Wed, Aug 06, 2014 at 08:38:30PM +0900, 杉山昌治 wrote:
> Hello,
> 
> Here is the result without specifying netlogon attribute.
> # In my previous mail, I attached (pasted) ldapseach result without
> specifying netlogon attribute and filters.
> 
> [root at jpbl0-in00-is11 ~]# ldapsearch -x -D 'labsso\admin' -W -H
> ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base
> '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))'
> # extended LDIF
> #
> # LDAPv3
> # base <> with scope baseObject
> # filter: (&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))
> # requesting: ALL
> #
> 
> #
> dn:
> currentTime: 20140806113154.0Z
> subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=labroot,DC=isops
>  ,DC=example,DC=com
> dsServiceName: CN=NTDS Settings,CN=JPBW0-IN00-IS82,CN=Servers,CN=NK1,CN=Sites,
>  CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com
> namingContexts: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com
> namingContexts: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com
> namingContexts: DC=ForestDnsZones,DC=labroot,DC=isops,DC=example,DC=com
> namingContexts: DC=labsso,DC=labroot,DC=isops,DC=example,DC=com
> namingContexts:
> DC=DomainDnsZones,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com
> defaultNamingContext: DC=labsso,DC=labroot,DC=isops,DC=example,DC=com
> schemaNamingContext:
> CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=
>  com
> configurationNamingContext:
> CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com
> rootDomainNamingContext: DC=labroot,DC=isops,DC=example,DC=com
> supportedControl: 1.2.840.113556.1.4.319
> supportedControl: 1.2.840.113556.1.4.801
> supportedControl: 1.2.840.113556.1.4.473
> supportedControl: 1.2.840.113556.1.4.528
> supportedControl: 1.2.840.113556.1.4.417
> supportedControl: 1.2.840.113556.1.4.619
> supportedControl: 1.2.840.113556.1.4.841
> supportedControl: 1.2.840.113556.1.4.529
> supportedControl: 1.2.840.113556.1.4.805
> supportedControl: 1.2.840.113556.1.4.521
> supportedControl: 1.2.840.113556.1.4.970
> supportedControl: 1.2.840.113556.1.4.1338
> supportedControl: 1.2.840.113556.1.4.474
> supportedControl: 1.2.840.113556.1.4.1339
> supportedControl: 1.2.840.113556.1.4.1340
> supportedControl: 1.2.840.113556.1.4.1413
> supportedControl: 2.16.840.1.113730.3.4.9
> supportedControl: 2.16.840.1.113730.3.4.10
> supportedControl: 1.2.840.113556.1.4.1504
> supportedControl: 1.2.840.113556.1.4.1852
> supportedControl: 1.2.840.113556.1.4.802
> supportedControl: 1.2.840.113556.1.4.1907
> supportedControl: 1.2.840.113556.1.4.1948
> supportedControl: 1.2.840.113556.1.4.1974
> supportedControl: 1.2.840.113556.1.4.1341
> supportedControl: 1.2.840.113556.1.4.2026
> supportedControl: 1.2.840.113556.1.4.2064
> supportedControl: 1.2.840.113556.1.4.2065
> supportedControl: 1.2.840.113556.1.4.2066
> supportedLDAPVersion: 3
> supportedLDAPVersion: 2
> supportedLDAPPolicies: MaxPoolThreads
> supportedLDAPPolicies: MaxDatagramRecv
> supportedLDAPPolicies: MaxReceiveBuffer
> supportedLDAPPolicies: InitRecvTimeout
> supportedLDAPPolicies: MaxConnections
> supportedLDAPPolicies: MaxConnIdleTime
> supportedLDAPPolicies: MaxPageSize
> supportedLDAPPolicies: MaxQueryDuration
> supportedLDAPPolicies: MaxTempTableSize
> supportedLDAPPolicies: MaxResultSetSize
> supportedLDAPPolicies: MinResultSets
> supportedLDAPPolicies: MaxResultSetsPerConn
> supportedLDAPPolicies: MaxNotificationPerConn
> supportedLDAPPolicies: MaxValRange
> supportedLDAPPolicies: ThreadMemoryLimit
> supportedLDAPPolicies: SystemMemoryLimitPercent
> highestCommittedUSN: 5293709
> supportedSASLMechanisms: GSSAPI
> supportedSASLMechanisms: GSS-SPNEGO
> supportedSASLMechanisms: EXTERNAL
> supportedSASLMechanisms: DIGEST-MD5
> dnsHostName: jpbw0-in00-is82.labsso.labroot.isops.example.com
> ldapServiceName:
> labroot.isops.example.com:jpbw0-in00-is82$@LABSSO.LABROOT.ISOPS.EXAMPLE.COM
> serverName: CN=JPBW0-IN00-IS82,CN=Servers,CN=NK1,CN=Sites,CN=Configuration,DC=
>  labroot,DC=isops,DC=example,DC=com
> supportedCapabilities: 1.2.840.113556.1.4.800
> supportedCapabilities: 1.2.840.113556.1.4.1670
> supportedCapabilities: 1.2.840.113556.1.4.1791
> supportedCapabilities: 1.2.840.113556.1.4.1935
> supportedCapabilities: 1.2.840.113556.1.4.2080
> isSynchronized: TRUE
> isGlobalCatalogReady: TRUE
> domainFunctionality: 4
> forestFunctionality: 4
> domainControllerFunctionality: 4
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 2
> # numEntries: 1
> 
> Regards,
> Shoji
> 

Thank you. This seems about right. I guess we need to take another look
at how we detect which forest we belong to..

One of our Samba experts says we should be looking up the forest with a
UDP cldap search and not the ordinary TCP search, but currently there's
no cldap code in SSSD I'm afraid. I need to do a bit more digging.

In the meantime, I will send a patch to avoid looking up the forest root
if the forest name cannot be discovered, that's clearly wrong.

Also, as a temporary workaround, you can enroll your client with the
forest root directly if possible..

Thank you for bringing up the issue.


More information about the sssd-users mailing list