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
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.com(a)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