Hello
I'm struggle with configuration of sssd to retrieve group information defined in a subdomain. I would have your support to solve my issue.
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)
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").
# 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.
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 ad_enable_gc = true ldap_id_mapping = true 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@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@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
On Mon, Jul 28, 2014 at 06:27:55PM +0900, 杉山昌治 wrote:
Hello
I'm struggle with configuration of sssd to retrieve group information defined in a subdomain. I would have your support to solve my issue.
Hi,
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@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@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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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@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@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@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
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..
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@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
Hello Jakub,
2014-07-31 18:02 GMT+09:00 Jakub Hrozek jhrozek@redhat.com:
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.com@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 ?
Thank you.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Fri, Aug 01, 2014 at 08:20:16PM +0900, 杉山昌治 wrote:
Hello Jakub,
2014-07-31 18:02 GMT+09:00 Jakub Hrozek jhrozek@redhat.com:
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.com@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?
Hello,
Thank you for your kind help.
I could not see it (successfully subdomains discovering) in the logs. It seems the subdmains forced set null.
<< log part 1 >> [sssd[be[labsso]]] [client_registration] (0x0100): Cancel DP ID timeout [0x1acb120] [sssd[be[labsso]]] [client_registration] (0x0100): Added Frontend client [PAM] [sssd[be[labsso]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][] [sssd[be[labsso]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' [sssd[be[labsso]]] [get_server_status] (0x1000): Status of server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is 'name not resolved' [sssd[be[labsso]]] [get_port_status] (0x1000): Port status of port 0 for server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is 'neutral' [sssd[be[labsso]]] [get_server_status] (0x1000): Status of server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is 'name not resolved' [sssd[be[labsso]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in files [sssd[be[labsso]]] [set_server_common_status] (0x0100): Marking server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' as 'resolving name' [sssd[be[labsso]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in files [sssd[be[labsso]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry [sssd[be[labsso]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in DNS << end log part 1 >>
I also found an error (malformed search filter) when searching trustedDomain with "cn=(null)".
<< log part 2 >> [sssd[be[labsso]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' as 'working' [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=domain][DC=labsso,DC=labroot,DC=isops,DC=example,DC=com]. [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] [sssd[be[labsso]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. [sssd[be[labsso]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set [sssd[be[labsso]]] [ad_master_domain_next_done] (0x0400): Found SID [S-1-5-21-1401708884-2744904820-804000056]. [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))][]. [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [netlogon] [sssd[be[labsso]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set [sssd[be[labsso]]] [ad_master_domain_netlogon_done] (0x0080): No netlogon data available. Flat name might not be usable [sssd[be[labsso]]] [ad_subdomains_master_dom_done] (0x0400): SSSD needs to look up the forest root domain [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=trustedDomain)(trustType=2)(!(msDS-TrustForestTrustInfo=*))(cn=(null)))][DC=labsso,DC=labroot,DC=isops,DC=example,DC=com]. [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [flatName] [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustPartner] [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [securityIdentifier] [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustType] [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustAttributes] [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0080): ldap_search_ext failed: Bad search filter [sssd[be[labsso]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [1432158235]: Malformed search filter [sssd[be[labsso]]] [ad_subdomains_get_root_domain_done] (0x0040): sdap_get_generic_send request failed. [sssd[be[labsso]]] [get_subdomains_callback] (0x0400): Backend returned: (3, 1432158235, <NULL>) [Internal Error (Unknown PAM error)] [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=domain][DC=labsso,DC=labroot,DC=isops,DC=example,DC=com]. [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 1432158235 error message: Internal Error (Unknown PAM error) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x40cf30:domains@labbu] [sssd[pam]] [sss_dp_get_domains_msg] (0x0400): Sending get domains request for [labbu][forced][] [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x40cf30:domains@labbu] [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x40cf30:domains@labsso] [sssd[be[labbu]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][] [sssd[be[labbu]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' << end of log part 2 >>
May I missed something on subdomain configuration on AD side ? # I can see correct hierarchy (labroot -> labsso -> labbu) thru "Active Directory Domains and Trusts" on Windows. Could you kindly how to check the subdomain configuration on AD side ? Also how sssd AD provider discover subdomains ?
Thank you for your kind support. Shoji
2014-08-04 21:55 GMT+09:00 Jakub Hrozek jhrozek@redhat.com:
On Fri, Aug 01, 2014 at 08:20:16PM +0900, 杉山昌治 wrote:
Hello Jakub,
2014-07-31 18:02 GMT+09:00 Jakub Hrozek jhrozek@redhat.com:
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.com@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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Aug 05, 2014 at 05:07:00PM +0900, 杉山昌治 wrote:
Hello,
Thank you for your kind help.
I could not see it (successfully subdomains discovering) in the logs. It seems the subdmains forced set null.
<< log part 1 >> [sssd[be[labsso]]] [client_registration] (0x0100): Cancel DP ID timeout [0x1acb120] [sssd[be[labsso]]] [client_registration] (0x0100): Added Frontend client [PAM] [sssd[be[labsso]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][] [sssd[be[labsso]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' [sssd[be[labsso]]] [get_server_status] (0x1000): Status of server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is 'name not resolved' [sssd[be[labsso]]] [get_port_status] (0x1000): Port status of port 0 for server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is 'neutral' [sssd[be[labsso]]] [get_server_status] (0x1000): Status of server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is 'name not resolved' [sssd[be[labsso]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in files [sssd[be[labsso]]] [set_server_common_status] (0x0100): Marking server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' as 'resolving name' [sssd[be[labsso]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in files [sssd[be[labsso]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry [sssd[be[labsso]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in DNS << end log part 1 >>
I also found an error (malformed search filter) when searching trustedDomain with "cn=(null)".
This shouldn't happen -- we have a bug in SSSD.
<< log part 2 >> [sssd[be[labsso]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' as 'working' [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=domain][DC=labsso,DC=labroot,DC=isops,DC=example,DC=com]. [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] [sssd[be[labsso]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. [sssd[be[labsso]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set [sssd[be[labsso]]] [ad_master_domain_next_done] (0x0400): Found SID [S-1-5-21-1401708884-2744904820-804000056]. [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))][]. [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [netlogon] [sssd[be[labsso]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set [sssd[be[labsso]]] [ad_master_domain_netlogon_done] (0x0080): No
Here is where things start to go south. We're not able to retrieve the netlogon data, which means we're not able to retrieve the forest we're part of. Later we hit the SSSD bug where we continue searching despite the forest being NULL.
Because we can't find the forest root, we're not able to see all trusted domains, which I think is the reason for your trouble. Thank you very much for your persistence, I'm glad we found the issue.
But before I send a patch to abort the request when we can't determine the forest, I'd like to debug why we can't see the forest data..
Can you try this ldapsearch?
ldapsearch -Y GSSAPI -H ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))' netlogon
The attribute would not be human-readable if found.
Are you aware of any non-standard access control on your server?
Can you run the same search against a different server, maybe the forest root?
Thank you very much for your help
Hello,
Thank you for your guide for the next step.
2014-08-06 4:17 GMT+09:00 Jakub Hrozek jhrozek@redhat.com:
Can you try this ldapsearch?
ldapsearch -Y GSSAPI -H ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))' netlogon
The attribute would not be human-readable if found.
Are you aware of any non-standard access control on your server?
All AD servers (LABROOT, LABSSO, LABBU) are Windows 2008 R2 SP1.
The current AD servers are configured by other engineer and I'm not familiar with AD server. I logon to LABSSO AD server and confirmed "LABSSO : labsso.labroot.isops.example.com" has the trusts on "LABBU : labbu.labsso.labroot.isops.example.com" as "Child" and on "LABROOT : labroot.isops.example.com" as "Parent". So I believe AD subtree (forest) configuration is OK. As for access control, I believe it should use standard access control. To avoid access control issue, I used administrators account for the following ldapseach.
Can you run the same search against a different server, maybe the forest root?
Here is the result of base object search against LABSSO and LABROOT (the forest root). I could not find "netlogon" attribute. So I'm afraid our AD configuration is something wrong, but I have no idea why "netlogon" attribute is missing.
<< LABSSO AD >>
[root@jpbl0-in00-is11 ~]# ldapsearch -x -D 'labroot\admin' -W -H ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))' netlogon # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (&(DnsDomain=LABSSO)(NtVer=\14\00\00\00)) # requesting: netlogon #
# search result search: 2 result: 0 Success
# numResponses: 1
<< LABROOT AD >>
[root@jpbl0-in00-is11 ~]# ldapsearch -x -D 'labroot\admin' -W -H ldap://jpbw0-in00-is83.labroot.isops.example.com -b '' -s base '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))' netlogon # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (&(DnsDomain=LABSSO)(NtVer=\14\00\00\00)) # requesting: netlogon #
# search result search: 2 result: 0 Success
# numResponses: 1
==================================================================
<< Full baseObject List - LABSSO >>
[root@jpbl0-in00-is11 ~]# ldapsearch -x -D 'labsso\admin' -W -H ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL #
# dn: currentTime: 20140806042727.0Z subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=labroot,DC=isops ,DC=example,DC=com dsServiceName: CN=NTDS Settings,CN=JPBW0-IN00-IS82,CN=Servers,CN=NK1,CN=Sites, CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=ForestDnsZones,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=labsso,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=DomainDnsZones,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com defaultNamingContext: DC=labsso,DC=labroot,DC=isops,DC=example,DC=com schemaNamingContext: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC= com configurationNamingContext: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com rootDomainNamingContext: DC=labroot,DC=isops,DC=example,DC=com supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.840.113556.1.4.801 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.528 supportedControl: 1.2.840.113556.1.4.417 supportedControl: 1.2.840.113556.1.4.619 supportedControl: 1.2.840.113556.1.4.841 supportedControl: 1.2.840.113556.1.4.529 supportedControl: 1.2.840.113556.1.4.805 supportedControl: 1.2.840.113556.1.4.521 supportedControl: 1.2.840.113556.1.4.970 supportedControl: 1.2.840.113556.1.4.1338 supportedControl: 1.2.840.113556.1.4.474 supportedControl: 1.2.840.113556.1.4.1339 supportedControl: 1.2.840.113556.1.4.1340 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.10 supportedControl: 1.2.840.113556.1.4.1504 supportedControl: 1.2.840.113556.1.4.1852 supportedControl: 1.2.840.113556.1.4.802 supportedControl: 1.2.840.113556.1.4.1907 supportedControl: 1.2.840.113556.1.4.1948 supportedControl: 1.2.840.113556.1.4.1974 supportedControl: 1.2.840.113556.1.4.1341 supportedControl: 1.2.840.113556.1.4.2026 supportedControl: 1.2.840.113556.1.4.2064 supportedControl: 1.2.840.113556.1.4.2065 supportedControl: 1.2.840.113556.1.4.2066 supportedLDAPVersion: 3 supportedLDAPVersion: 2 supportedLDAPPolicies: MaxPoolThreads supportedLDAPPolicies: MaxDatagramRecv supportedLDAPPolicies: MaxReceiveBuffer supportedLDAPPolicies: InitRecvTimeout supportedLDAPPolicies: MaxConnections supportedLDAPPolicies: MaxConnIdleTime supportedLDAPPolicies: MaxPageSize supportedLDAPPolicies: MaxQueryDuration supportedLDAPPolicies: MaxTempTableSize supportedLDAPPolicies: MaxResultSetSize supportedLDAPPolicies: MinResultSets supportedLDAPPolicies: MaxResultSetsPerConn supportedLDAPPolicies: MaxNotificationPerConn supportedLDAPPolicies: MaxValRange supportedLDAPPolicies: ThreadMemoryLimit supportedLDAPPolicies: SystemMemoryLimitPercent highestCommittedUSN: 5282424 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 dnsHostName: jpbw0-in00-is82.labsso.labroot.isops.example.com ldapServiceName: labroot.isops.example.com:jpbw0-in00-is82$@LABSSO.LABROOT.ISOPS.I BM.COM serverName: CN=JPBW0-IN00-IS82,CN=Servers,CN=NK1,CN=Sites,CN=Configuration,DC= labroot,DC=isops,DC=example,DC=com supportedCapabilities: 1.2.840.113556.1.4.800 supportedCapabilities: 1.2.840.113556.1.4.1670 supportedCapabilities: 1.2.840.113556.1.4.1791 supportedCapabilities: 1.2.840.113556.1.4.1935 supportedCapabilities: 1.2.840.113556.1.4.2080 isSynchronized: TRUE isGlobalCatalogReady: TRUE domainFunctionality: 4 forestFunctionality: 4 domainControllerFunctionality: 4
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
==================================================================
<< Full baseObject List : LABROOT >>
[root@jpbl0-in00-is11 ~]# ldapsearch -x -D 'labroot\admin' -w 'Tak3m3aLab!' -H ldap://jpbw0-in00-is83.labroot.isops.example.com -b '' -s base # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL #
# dn: currentTime: 20140806042954.0Z subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=labroot,DC=isops ,DC=example,DC=com dsServiceName: CN=NTDS Settings,CN=JPBW0-IN00-IS83,CN=Servers,CN=NK1,CN=Sites, CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=labroot,DC=isops,DC=example,DC=com namingContexts: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=DomainDnsZones,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=ForestDnsZones,DC=labroot,DC=isops,DC=example,DC=com defaultNamingContext: DC=labroot,DC=isops,DC=example,DC=com schemaNamingContext: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC= com configurationNamingContext: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com rootDomainNamingContext: DC=labroot,DC=isops,DC=example,DC=com supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.840.113556.1.4.801 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.528 supportedControl: 1.2.840.113556.1.4.417 supportedControl: 1.2.840.113556.1.4.619 supportedControl: 1.2.840.113556.1.4.841 supportedControl: 1.2.840.113556.1.4.529 supportedControl: 1.2.840.113556.1.4.805 supportedControl: 1.2.840.113556.1.4.521 supportedControl: 1.2.840.113556.1.4.970 supportedControl: 1.2.840.113556.1.4.1338 supportedControl: 1.2.840.113556.1.4.474 supportedControl: 1.2.840.113556.1.4.1339 supportedControl: 1.2.840.113556.1.4.1340 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.10 supportedControl: 1.2.840.113556.1.4.1504 supportedControl: 1.2.840.113556.1.4.1852 supportedControl: 1.2.840.113556.1.4.802 supportedControl: 1.2.840.113556.1.4.1907 supportedControl: 1.2.840.113556.1.4.1948 supportedControl: 1.2.840.113556.1.4.1974 supportedControl: 1.2.840.113556.1.4.1341 supportedControl: 1.2.840.113556.1.4.2026 supportedControl: 1.2.840.113556.1.4.2064 supportedControl: 1.2.840.113556.1.4.2065 supportedControl: 1.2.840.113556.1.4.2066 supportedLDAPVersion: 3 supportedLDAPVersion: 2 supportedLDAPPolicies: MaxPoolThreads supportedLDAPPolicies: MaxDatagramRecv supportedLDAPPolicies: MaxReceiveBuffer supportedLDAPPolicies: InitRecvTimeout supportedLDAPPolicies: MaxConnections supportedLDAPPolicies: MaxConnIdleTime supportedLDAPPolicies: MaxPageSize supportedLDAPPolicies: MaxQueryDuration supportedLDAPPolicies: MaxTempTableSize supportedLDAPPolicies: MaxResultSetSize supportedLDAPPolicies: MinResultSets supportedLDAPPolicies: MaxResultSetsPerConn supportedLDAPPolicies: MaxNotificationPerConn supportedLDAPPolicies: MaxValRange supportedLDAPPolicies: ThreadMemoryLimit supportedLDAPPolicies: SystemMemoryLimitPercent highestCommittedUSN: 5373198 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 dnsHostName: jpbw0-in00-is83.labroot.isops.example.com ldapServiceName: labroot.isops.example.com:jpbw0-in00-is83$@LABROOT.ISOPS.EXAMPLE.COM serverName: CN=JPBW0-IN00-IS83,CN=Servers,CN=NK1,CN=Sites,CN=Configuration,DC= labroot,DC=isops,DC=example,DC=com supportedCapabilities: 1.2.840.113556.1.4.800 supportedCapabilities: 1.2.840.113556.1.4.1670 supportedCapabilities: 1.2.840.113556.1.4.1791 supportedCapabilities: 1.2.840.113556.1.4.1935 supportedCapabilities: 1.2.840.113556.1.4.2080 isSynchronized: TRUE isGlobalCatalogReady: TRUE domainFunctionality: 4 forestFunctionality: 4 domainControllerFunctionality: 4
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Regards, Shoji
On Wed, Aug 06, 2014 at 01:58:02PM +0900, 杉山昌治 wrote:
Here is the result of base object search against LABSSO and LABROOT (the forest root). I could not find "netlogon" attribute. So I'm afraid our AD configuration is something wrong, but I have no idea why "netlogon" attribute is missing.
Thank you, can you also check if the DnsDomain object exists at all?
Just search with DnsDomain=LABSSO w/o requiring the netlogon attribute: # ldapsearch -x -D 'labroot\admin' -W -H ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))'
Are there maybe other DnsDomain=* objects instead? I'm tring to figure out if we're using a wrong name to search..
Hello,
Here is the result without specifying netlogon attribute. # In my previous mail, I attached (pasted) ldapseach result without specifying netlogon attribute and filters.
[root@jpbl0-in00-is11 ~]# ldapsearch -x -D 'labsso\admin' -W -H ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))' # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (&(DnsDomain=LABSSO)(NtVer=\14\00\00\00)) # requesting: ALL #
# dn: currentTime: 20140806113154.0Z subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=labroot,DC=isops ,DC=example,DC=com dsServiceName: CN=NTDS Settings,CN=JPBW0-IN00-IS82,CN=Servers,CN=NK1,CN=Sites, CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=ForestDnsZones,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=labsso,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=DomainDnsZones,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com defaultNamingContext: DC=labsso,DC=labroot,DC=isops,DC=example,DC=com schemaNamingContext: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC= com configurationNamingContext: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com rootDomainNamingContext: DC=labroot,DC=isops,DC=example,DC=com supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.840.113556.1.4.801 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.528 supportedControl: 1.2.840.113556.1.4.417 supportedControl: 1.2.840.113556.1.4.619 supportedControl: 1.2.840.113556.1.4.841 supportedControl: 1.2.840.113556.1.4.529 supportedControl: 1.2.840.113556.1.4.805 supportedControl: 1.2.840.113556.1.4.521 supportedControl: 1.2.840.113556.1.4.970 supportedControl: 1.2.840.113556.1.4.1338 supportedControl: 1.2.840.113556.1.4.474 supportedControl: 1.2.840.113556.1.4.1339 supportedControl: 1.2.840.113556.1.4.1340 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.10 supportedControl: 1.2.840.113556.1.4.1504 supportedControl: 1.2.840.113556.1.4.1852 supportedControl: 1.2.840.113556.1.4.802 supportedControl: 1.2.840.113556.1.4.1907 supportedControl: 1.2.840.113556.1.4.1948 supportedControl: 1.2.840.113556.1.4.1974 supportedControl: 1.2.840.113556.1.4.1341 supportedControl: 1.2.840.113556.1.4.2026 supportedControl: 1.2.840.113556.1.4.2064 supportedControl: 1.2.840.113556.1.4.2065 supportedControl: 1.2.840.113556.1.4.2066 supportedLDAPVersion: 3 supportedLDAPVersion: 2 supportedLDAPPolicies: MaxPoolThreads supportedLDAPPolicies: MaxDatagramRecv supportedLDAPPolicies: MaxReceiveBuffer supportedLDAPPolicies: InitRecvTimeout supportedLDAPPolicies: MaxConnections supportedLDAPPolicies: MaxConnIdleTime supportedLDAPPolicies: MaxPageSize supportedLDAPPolicies: MaxQueryDuration supportedLDAPPolicies: MaxTempTableSize supportedLDAPPolicies: MaxResultSetSize supportedLDAPPolicies: MinResultSets supportedLDAPPolicies: MaxResultSetsPerConn supportedLDAPPolicies: MaxNotificationPerConn supportedLDAPPolicies: MaxValRange supportedLDAPPolicies: ThreadMemoryLimit supportedLDAPPolicies: SystemMemoryLimitPercent highestCommittedUSN: 5293709 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 dnsHostName: jpbw0-in00-is82.labsso.labroot.isops.example.com ldapServiceName: labroot.isops.example.com:jpbw0-in00-is82$@LABSSO.LABROOT.ISOPS.EXAMPLE.COM serverName: CN=JPBW0-IN00-IS82,CN=Servers,CN=NK1,CN=Sites,CN=Configuration,DC= labroot,DC=isops,DC=example,DC=com supportedCapabilities: 1.2.840.113556.1.4.800 supportedCapabilities: 1.2.840.113556.1.4.1670 supportedCapabilities: 1.2.840.113556.1.4.1791 supportedCapabilities: 1.2.840.113556.1.4.1935 supportedCapabilities: 1.2.840.113556.1.4.2080 isSynchronized: TRUE isGlobalCatalogReady: TRUE domainFunctionality: 4 forestFunctionality: 4 domainControllerFunctionality: 4
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Regards, Shoji
2014-08-06 18:34 GMT+09:00 Jakub Hrozek jhrozek@redhat.com:
On Wed, Aug 06, 2014 at 01:58:02PM +0900, 杉山昌治 wrote:
Here is the result of base object search against LABSSO and LABROOT (the forest root). I could not find "netlogon" attribute. So I'm afraid our AD configuration is something wrong, but I have no idea why "netlogon" attribute is missing.
Thank you, can you also check if the DnsDomain object exists at all?
Just search with DnsDomain=LABSSO w/o requiring the netlogon attribute: # ldapsearch -x -D 'labroot\admin' -W -H ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))'
Are there maybe other DnsDomain=* objects instead? I'm tring to figure out if we're using a wrong name to search.. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, Aug 06, 2014 at 08:38:30PM +0900, 杉山昌治 wrote:
Hello,
Here is the result without specifying netlogon attribute. # In my previous mail, I attached (pasted) ldapseach result without specifying netlogon attribute and filters.
[root@jpbl0-in00-is11 ~]# ldapsearch -x -D 'labsso\admin' -W -H ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base '(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))' # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (&(DnsDomain=LABSSO)(NtVer=\14\00\00\00)) # requesting: ALL #
# dn: currentTime: 20140806113154.0Z subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=labroot,DC=isops ,DC=example,DC=com dsServiceName: CN=NTDS Settings,CN=JPBW0-IN00-IS82,CN=Servers,CN=NK1,CN=Sites, CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=ForestDnsZones,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=labsso,DC=labroot,DC=isops,DC=example,DC=com namingContexts: DC=DomainDnsZones,DC=labsso,DC=labroot,DC=isops,DC=example,DC=com defaultNamingContext: DC=labsso,DC=labroot,DC=isops,DC=example,DC=com schemaNamingContext: CN=Schema,CN=Configuration,DC=labroot,DC=isops,DC=example,DC= com configurationNamingContext: CN=Configuration,DC=labroot,DC=isops,DC=example,DC=com rootDomainNamingContext: DC=labroot,DC=isops,DC=example,DC=com supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.840.113556.1.4.801 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.528 supportedControl: 1.2.840.113556.1.4.417 supportedControl: 1.2.840.113556.1.4.619 supportedControl: 1.2.840.113556.1.4.841 supportedControl: 1.2.840.113556.1.4.529 supportedControl: 1.2.840.113556.1.4.805 supportedControl: 1.2.840.113556.1.4.521 supportedControl: 1.2.840.113556.1.4.970 supportedControl: 1.2.840.113556.1.4.1338 supportedControl: 1.2.840.113556.1.4.474 supportedControl: 1.2.840.113556.1.4.1339 supportedControl: 1.2.840.113556.1.4.1340 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.10 supportedControl: 1.2.840.113556.1.4.1504 supportedControl: 1.2.840.113556.1.4.1852 supportedControl: 1.2.840.113556.1.4.802 supportedControl: 1.2.840.113556.1.4.1907 supportedControl: 1.2.840.113556.1.4.1948 supportedControl: 1.2.840.113556.1.4.1974 supportedControl: 1.2.840.113556.1.4.1341 supportedControl: 1.2.840.113556.1.4.2026 supportedControl: 1.2.840.113556.1.4.2064 supportedControl: 1.2.840.113556.1.4.2065 supportedControl: 1.2.840.113556.1.4.2066 supportedLDAPVersion: 3 supportedLDAPVersion: 2 supportedLDAPPolicies: MaxPoolThreads supportedLDAPPolicies: MaxDatagramRecv supportedLDAPPolicies: MaxReceiveBuffer supportedLDAPPolicies: InitRecvTimeout supportedLDAPPolicies: MaxConnections supportedLDAPPolicies: MaxConnIdleTime supportedLDAPPolicies: MaxPageSize supportedLDAPPolicies: MaxQueryDuration supportedLDAPPolicies: MaxTempTableSize supportedLDAPPolicies: MaxResultSetSize supportedLDAPPolicies: MinResultSets supportedLDAPPolicies: MaxResultSetsPerConn supportedLDAPPolicies: MaxNotificationPerConn supportedLDAPPolicies: MaxValRange supportedLDAPPolicies: ThreadMemoryLimit supportedLDAPPolicies: SystemMemoryLimitPercent highestCommittedUSN: 5293709 supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 dnsHostName: jpbw0-in00-is82.labsso.labroot.isops.example.com ldapServiceName: labroot.isops.example.com:jpbw0-in00-is82$@LABSSO.LABROOT.ISOPS.EXAMPLE.COM serverName: CN=JPBW0-IN00-IS82,CN=Servers,CN=NK1,CN=Sites,CN=Configuration,DC= labroot,DC=isops,DC=example,DC=com supportedCapabilities: 1.2.840.113556.1.4.800 supportedCapabilities: 1.2.840.113556.1.4.1670 supportedCapabilities: 1.2.840.113556.1.4.1791 supportedCapabilities: 1.2.840.113556.1.4.1935 supportedCapabilities: 1.2.840.113556.1.4.2080 isSynchronized: TRUE isGlobalCatalogReady: TRUE domainFunctionality: 4 forestFunctionality: 4 domainControllerFunctionality: 4
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Regards, Shoji
Thank you. This seems about right. I guess we need to take another look at how we detect which forest we belong to..
One of our Samba experts says we should be looking up the forest with a UDP cldap search and not the ordinary TCP search, but currently there's no cldap code in SSSD I'm afraid. I need to do a bit more digging.
In the meantime, I will send a patch to avoid looking up the forest root if the forest name cannot be discovered, that's clearly wrong.
Also, as a temporary workaround, you can enroll your client with the forest root directly if possible..
Thank you for bringing up the issue.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
杉山昌治