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

Jakub Hrozek jhrozek at redhat.com
Mon Aug 4 12:55:36 UTC 2014


On Fri, Aug 01, 2014 at 08:20:16PM +0900, 杉山昌治 wrote:
> Hello Jakub,
> 
> 2014-07-31 18:02 GMT+09:00 Jakub Hrozek <jhrozek at redhat.com>:
> > On Wed, Jul 30, 2014 at 01:18:40PM +0900, 杉山昌治 wrote:
> >> Hello Jakub,
> >>
> >> Thank you for your quick reply and explanation.
> >> I understand the domain local group defined in the sub-domain
> >> (LABBU=labbu.sso.example.com) is not able to be a group for a user who
> >> enrolled
> >> So, I created a new universal group (U-Role-Labbu-Test) in the LABBU
> >> domain and assigned "U-Role-ISOps-Server" (in LABSSO domain) as a
> >> member.
> >> Thru Windows server, I can see "U-Role-Labbu-Test (LABBU)" in "Member
> >> Of" tab of "U-Role-ISOps-Server (LABSSO)" group.
> >> So I believed I could get the new group information thru LABSSO domain server.
> >>
> >> User/Groups in Domain sso.example.com
> >> ========================
> >> User    test_user (MemberOf=G-Group-Server)
> >> Group    G-Role-ISOps-Server (Type: Global Group,
> >> Members=test_user,MemberOf=U-Role-ISOps-Server)
> >> Group    U-Role-ISOps-Server (Type: Universal
> >> Group,Members=G-Role-ISOps-Server,MemberOf=U-Role-Labbu-Test)
> >>
> >> User/Groups in Domain labbu.sso.example.com
> >> ========================
> >> Group    D-Role-ISOps-Server (Type: Domain Local
> >> Group,Members=U-Role-ISOps-Server)
> >> Group    U-Role-Labbu-Test    (Type: Universal
> >> Group,Members=U-Role-ISOps-Server)
> >
> > OK, but which domain is the client enrolled with? You'll only see
> > domain-local groups of the same domain. If your client is enrolled with
> > labbu.sso.example.com then I would expect to see the group, if it's
> > enrolled with sso.example.com then I don't think you would be listed as
> > a group member..
> 
> Yes, the client enrolled with "labbu.sso.example.com".
> So the domain local group should not be listed up.
> 
> >
> >>
> >> I also confirmed the "MemberOf" attribute is set.
> >>
> >> << ldapsearch result >>
> >> [root at jpbl0-in00-is11 ~]# ldapsearch  -Y GSSAPI -LLL -H
> >> "ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com:3268" -b
> >> "DC=labsso,DC=labroot,DC=isops,DC=example,DC=com"
> >> "(&(name=u-role-isops-server)(objectclass=group)(name=*))"
> >>
> >> SASL/GSSAPI authentication started
> >> SASL username: host/jpbl0-in00-is11.lab.isops.example.com at LABSSO.LABROOT.ISOPS.EXAMPLE.COM
> >> SASL SSF: 56
> >> SASL data security layer installed.
> >> dn: CN=U-Role-ISOps-Server,OU=UGroups,OU=BU0-ISOps,OU=Roles,DC=labsso,DC=labro
> >>  ot,DC=isops,DC=example,DC=com
> >> objectClass: top
> >> objectClass: group
> >> cn: U-Role-ISOps-Server
> >> description: Server Team in Troy's Org
> >> member: CN=G-Role-ISOps-Server,OU=BU0-ISOps,OU=Roles,DC=labsso,DC=labroot,DC=i
> >>  sops,DC=example,DC=com
> >> distinguishedName: CN=U-Role-ISOps-Server,OU=UGroups,OU=BU0-ISOps,OU=Roles,DC=
> >>  labsso,DC=labroot,DC=isops,DC=example,DC=com
> >> instanceType: 4
> >> whenCreated: 20131029182314.0Z
> >> whenChanged: 20140709064747.0Z
> >> uSNCreated: 17692
> >> memberOf: CN=U-Role-Labbu-Test,OU=BU0-ISOps,OU=Roles,DC=labbu,DC=labsso,DC=lab
> >>  root,DC=isops,DC=example,DC=com
> >> uSNChanged: 4548023
> >> name: U-Role-ISOps-Server
> >> objectGUID:: RQlz+uYst0mHr6qbRRXZ+A==
> >> objectSid:: AQUAAAAAAAUVAAAAVGGMU3Tsm6M4EewvXgQAAA==
> >> sAMAccountName: U-Role-ISOps-Server
> >> sAMAccountType: 268435456
> >> groupType: -2147483640
> >> objectCategory:
> >> CN=Group,CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example
> >>  ,DC=com
> >> dSCorePropagationData: 16010101000000.0Z
> >>
> >> Then I modified sssd.config only use "LABSSO" domain and tried to
> >> retrieve group information of "U-Role-Labbu-Test" by "getent group
> >> U-Role-Labbu-Test" command. But it returned nothing. I tried both case
> >> "ad_enable_gc=False"  and "ad_enable_gct=True", but the result was the
> >> same.
> >>
> >> I checked log message when invoked "getent group U-Role-Labbu-Test" command.
> >> It looks like the AD provider used normal LDAP port for
> >> ldap_search_ext() rather global catalog port (3268).
> >> It also looks like the AD provider checks the AD server with global
> >> catalog port (3268) to detect its compatibility level.
> >> I believed the AD provider tried to search in the global catalog first
> >> to search a specified group name.
> >>
> >> << log messages >>
> >> [sssd[be[sso-ad-ad]]] [be_resolve_server_process] (0x0200): Found
> >> address for server jpbw0-in00-is82.labsso.labroot.isops.example.com:
> >> [10.58.30.95] TTL 3600
> >> [sssd[be[sso-ad-ad]]] [ad_resolve_callback] (0x0100): Constructed uri
> >> 'ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com'
> >> [sssd[be[sso-ad-ad]]] [ad_resolve_callback] (0x0100): Constructed GC
> >> uri 'ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com:3268'
> >> [sssd[be[sso-ad-ad]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds
> >> timeout for connecting
> >> [sssd[be[sso-ad-ad]]] [sdap_ldap_connect_callback_add] (0x1000): New
> >> LDAP connection to
> >> [ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com:3268/??base]
> >> with fd [17].
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x0400): calling
> >> ldap_search_ext with [(objectclass=*)][].
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [*]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [altServer]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [namingContexts]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [supportedControl]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [supportedExtension]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [supportedFeatures]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [supportedLDAPVersion]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [supportedSASLMechanisms]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [domainControllerFunctionality]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [defaultNamingContext]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [lastUSN]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [highestCommittedUSN]
> >> [sssd[be[sso-ad-ad]]] [sdap_parse_entry] (0x1000): OriginalDN: [].
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_done] (0x0400): Search
> >> result: Success(0), no errmsg set
> >> [sssd[be[sso-ad-ad]]] [sdap_get_server_opts_from_rootdse] (0x0100):
> >> Setting AD compatibility level to [4]
> >>   << snipped >>
> >> [sssd[be[sso-ad-ad]]] [sdap_get_groups_next_base] (0x0400): Searching
> >> for groups with base [DC=labsso,DC=labroot,DC=isops,DC=example,DC=com]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x0400): calling
> >> ldap_search_ext with
> >> [(&(name=u-role-labbu-test)(objectclass=group)(name=*))][DC=labsso,DC=labroot,DC=isops,DC=example,DC=com].
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [objectClass]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [name]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [gidNumber]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [member]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [objectSID]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [whenChanged]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [uSNChanged]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> >> attrs: [groupType]
> >> [sssd[be[sso-ad-ad]]] [sdap_get_generic_ext_done] (0x0400): Search
> >> result: Success(0), no errmsg set
> >> [sssd[be[sso-ad-ad]]] [sdap_get_groups_process] (0x0400): Search for
> >> groups, returned 0 results.
> >> [sssd[be[sso-ad-ad]]] [sysdb_search_group_by_name] (0x0400): No such entry
> >> [sssd[be[sso-ad-ad]]] [sysdb_delete_group] (0x0400): Error: 2 (No such
> >> file or directory)
> >> [sssd[be[sso-ad-ad]]] [acctinfo_callback] (0x0100): Request processed.
> >> Returned 0,0,Success
> >>
> >> Could you kindly help me what's wrong on my configuration or the AD
> >> provider to get the new grouop (U-Role-Labbu-Test : defined in LABBU
> >> sub-domain) thru LABSSO domain ?
> >>
> >> Regards,
> >> Shoji
> >
> > The above search ran to completion but didn't find anything. Can you check
> > if the domain-local group u-role-labbu-test is present in GC? I suspect
> > it wouldn't..
> >
> > You can try if disabling GC makes a difference here:
> >     ad_enable_gc = False
> 
> I checked sssd log file and found "Domain not found for SID
> S-1-5......-1149" as below.
> 
> << log file >>
> [sssd[be[sso]]] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000):
> Processing membership SID
> [S-1-5-21-1401708884-2744904820-804000056-1172]
> [sssd[be[sso]]] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000):
> SID [S-1-5-21-1401708884-2744904820-804000056-1172] maps to GID
> [638201172]
> [sssd[be[sso]]] [sysdb_search_group_by_gid] (0x0400): No such entry
> [sssd[be[sso]]] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000):
> Processing membership SID
> [S-1-5-21-1176919450-1931656763-3149421143-1149]
> [sssd[be[sso]]] [sdap_ad_tokengroups_initgr_mapping_done] (0x0080):
> Domain not found for SID
> S-1-5-21-1176919450-1931656763-3149421143-1149
> [sssd[be[sso]]] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000):
> Processing membership SID
> [S-1-5-21-1401708884-2744904820-804000056-1170]
> [sssd[be[sso]]] [sdap_ad_tokengroups_initgr_mapping_done] (0x1000):
> SID [S-1-5-21-1401708884-2744904820-804000056-1170] maps to GID
> [638201170]
> [sssd[be[sso]]] [sysdb_search_group_by_gid] (0x0400): No such entry
> 
> Where
> SID S-1-*-1172 = U-Role-LABSSO (SSO domain, Universal Group)
> SID S-1-*-1170 = G-Role-LABSSO (SSO domain, Global Group)
> SID S-1-*-1149 = U-Role-LABBU (BU domain, Universal Group)
> 
> So it looks like sssd failed to get domain of U-Role-LABBU.
> I suspect this is a possible cause.
> Is there any hint why the domain was not found ?

I think earlier in the logs where we discover the subdomains, all SIDs
should be listed, do you see the one that SSSD later claims matches no
domain?


More information about the sssd-users mailing list