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

杉山昌治 sugishoji at gmail.com
Wed Jul 30 04:18:40 UTC 2014


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)

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

>
> thanks for the detailed e-mail. See some answers inline..
>
> >
> > Here is my AD configuration. There are 3 AD servers.
> >
> > Root Domain    labroot.example.com (just for top AD management)
> > Sub Domain    labsso.labroot.example.com (user, global group and universal
> > group are defined here)
> > Subsub Domain    labbu.labsso.labroot.example.com (local domain group is
> > defined here)
> >
> > I created a user and groups in those AD servers as below.
> >
> > 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)
> >
> > User/Groups in Domain sso.example.com
> > ========================
> > Group    D-Role-Server (Type: Domain Local Group,
> > Members=U-Role-ISOps-Server)
>
> Domain-local groups are only visible in the dame domain as the client is
> enrolled with. So if your domain-local groups is defined in
> labbu.labsso.labroot.example.com, only clients enrolled to that domain
> will be able to see that group.
>
> See also:
>     https://fedorahosted.org/sssd/ticket/2178
>
> >
> > As for SSSD, I tried to use both "1.11.6" and "1.12.1" with "AD provider"
> > as backend.
> >
> > I expected to get all groups (G-Role-ISOps-Server, U-Role-ISOps-Server and
> > D-ISOps-Server) as a result of
> > "id test_user" command.
> > But I could not find domain local group (D-Role-ISOps-Server) in groups of
> > the user "test_user".
> > as the result of "id test_user" command.
> > I also could not find any members as the result of "getent group
> > D-Role-ISOps-Server" command.
> > I tried to use single domain (sso-ad-ad) and multiple domains (sso-ad-ad
> > and bu-ad-ad) in sssd configuration, but the result is the almost same.
> > (when I use sso-ad-ad domain only, I could not get anything as result of
> > "getent group d-role-isops-server").
>
> The right way to configure sssd would be to only use one domain section
> in sssd.conf, with the domain your client was enrolled with.
>
> >
> > # id test_user
> > uid=638201126(test_user) gid=638200513(domain users)
> > groups=638200513(domain
> > users),638201113(g-role-server),638201118(u-role-server),638200512(domain
> > admins)
> >
> > # getent group d-role-isops-server
> > d-role-isops-server:*:927601110:
> >
> > I'm not sure how SSSD AD provider searches group information based on
> > members/memberOf attributes, I suspect missing "memberOf" in universal
> > group (U-Role-*) and "member of domain local group" (U-Role-ISOps-Server)
> > is out of scope of LABBU domain might be clue of my issue.
> > Please advise me what's wrong on my configuration and resolution of my
> > issue.
>
> By default, SSSD reads the tokenGroups attribute that contains the list
> of SIDs the user is a member of. You can disable this optimization and
> fall back to member/memberof processing by using the configuration
> option "ad_enable_gc = False".
>
> Is the only group that was missing from the output the domain-local one?
> If so, I believe sssd is actually working as expected..
>
> >
> > Thanks in advance.
> > Shoji
> >
> >
> > *** Configurations and LDAP search results ***
> >
> > sssd.conf file
> > ==========
> > [sssd]
> > config_file_version = 2
> > services = nss, pam
> > domains = sso-ad-ad, bu-ad-ad
> > # domains = sso-ad-ad
> > [nss]
> > fallback_homedir = /home/SSO/%u
> > default_shell = /bin/bash
> > [pam]
> > [domain/sso-ad-ad]
> > id_provider = ad
> > auth_provider = ad
> > access_provider = ad
> > ad_server = jpbw0-in00-is82.labsso.labroot.isops.example.com
> > ad_hostname =  jpbw0-in00-is82.labsso.labroot.isops.example.com
> > ldap_schema = ad
>
> You don't have to specify ldap-schema=ad yourself, it's already the
> default.
>
> > ad_enable_gc = true
>
> This is the default also.
>
> > ldap_id_mapping = true
>
> Again, this is the default.
>
> > debug_level = 1
> > [domain/bu-ad-ad]
> > id_provider = ad
> > auth_provider = ad
> > chpass_provider = ad
> > ad_server = jpbw0-in00-is81.labbu.labsso.labroot.isops.example.com
> > ad_hostname =  jpbw0-in00-is81.labbu.labsso.labroot.isops.example.com
> > ldap_id_mapping = true
> > debug_level = 1
> >
> > LDAP Search in Global Catalog of LABSSO
> > ==================================
> > I can search the domain local group in the global catalog.
> >
> > [root at jpbl0-in00-is11 providers]# 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=d-role-isops-server)(objectclass=group)(name=*))"
> > SASL/GSSAPI authentication started
> > SASL username: host/
> > jpbl0-in00-is11.lab.isops.ibm.com at LABSSO.LABROOT.ISOPS.EXAMPLE.COM
> > SASL SSF: 56
> > SASL data security layer installed.
> > dn:
> > CN=D-Role-ISOps-Server,OU=BU0-ISOps,OU=Roles,DC=labbu,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com
> > objectClass: top
> > objectClass: group
> > cn: D-Role-ISOps-Server
> > description: Server Team
> > distinguishedName:
> > CN=D-Role-ISOps-Server,OU=BU0-ISOps,OU=Roles,DC=labbu,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com
> > instanceType: 0
> > whenCreated: 20131029185150.0Z
> > whenChanged: 20131029185448.0Z
> > uSNCreated: 17964
> > uSNChanged: 18034
> > name: D-Role-ISOps-Server
> > objectGUID:: YflnJQk4IUK4YUAHO43J6w==
> > objectSid:: AQUAAAAAAAUVAAAAml0mRju+InNXWri7VgQAAA==
> > sAMAccountName: D-Role-ISOps-Server
> > sAMAccountType: 536870912
> > groupType: -2147483644
> > objectCategory:
> > CN=Group,CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com
> > dSCorePropagationData: 16010101000000.0Z
> >
> >
> > LDAP Search in LABSSO
> > ====================
> > I can not search the domain local group in normal domain.
> >
> > [root at jpbl0-in00-is11]# ldapsearch  -Y GSSAPI -LLL -H "ldap://
> > jpbw0-in00-is82.labsso.labroot.isops.example.com" -b
> > "DC=labsso,DC=labroot,DC=isops,DC=example,DC=com"
> > "(&(name=d-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.
> > # refldap://
> > labbu.labsso.labroot.isops.example.com/DC=labbu,DC=labsso,DC=labroot,
> >  DC=isops,DC=example,DC=com
> >
> > # refldap://
> > DomainDnsZones.labsso.labroot.isops.example.com/DC=DomainDnsZones,DC=
> >  labsso,DC=labroot,DC=isops,DC=example,DC=com


More information about the sssd-users mailing list