On Fri, Aug 01, 2014 at 08:20:16PM +0900, 杉山昌治 wrote: > Hello Jakub, > > 2014-07-31 18:02 GMT+09:00 Jakub Hrozek <[email protected]>: > > 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@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....@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? _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
