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

[杉山昌治]

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/
[e-mail]
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/
[e-mail]
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

[Jakub Hrozek]

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/
> [e-mail]
> 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/
> [e-mail]
> 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
> [e-mail]
> 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/[e-mail]
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/
> > [e-mail]
> > 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/
> > [e-mail]
> > 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

[Jakub Hrozek]

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/[e-mail]
> 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 :
> 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/[e-mail]
> > 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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Jakub Hrozek]

On Fri, Aug 01, 2014 at 08:20:16PM +0900, 杉山昌治 wrote:
> Hello Jakub,
>
> 2014-07-31 18:02 GMT+09:00 Jakub Hrozek :
> > 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/[e-mail]
> > > 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 :
> On Fri, Aug 01, 2014 at 08:20:16PM +0900, 杉山昌治 wrote:
> > Hello Jakub,
> >
> > 2014-07-31 18:02 GMT+09:00 Jakub Hrozek :
> > > 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/[e-mail]
> > > > 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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Jakub Hrozek]

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 :
> 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

[Jakub Hrozek]

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 :
> 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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Jakub Hrozek]

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.