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....@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....@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....@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 _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
