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@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
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@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(a)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@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(a)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