Hello,

I'm trying to implement an SSSD-based LDAP/Kerberos (with the LDAP authenticator, because we use SFU attributes) configuration, where the users primarily life at the root of the AD forest.

For example, our tree looks like this:

- example.org -> ou=User Accounts,dc=example,dc=org
|
|--> project1.example.org => ou=User Accounts,dc=project1,dc=example,dc=org
|
|--> project2.example.org => ou=User Accounts,dc=project2,dc=example,dc=org

So, most user accounts are loated in the top accounts container, with a few accounts, specific to their projects, located at the lower levels.

Where I am having issues is that my test infrastructure (Windows 2008 R2, CentOS 6.x) works fine, but the production infrastructure does not.  I have tried a variety of SSSD configs, but the current one looks like this.  The CentOS 6.x host is 'scm.project1.example.org'.  I am using the example from the Red Hat Active Directory Integration white paper, v1.4, so I generated a krb5.keytab on dc001.project1.example.org, so that scm.project1.example.org could query for user accounts.

# cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
domains = example.org, project1.example.org
services = nss, pam
debug_level = 0

[nss]

[pam]

[domain/example.org]
debug_level = 5
cache_credentials = True
enumerate = False

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/scm.project1.example.org@PROJECT1.EXAMPLE.ORG

ldap_schema = rfc2307bis

ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_user_name = sAMAccountName

ldap_group_object_class = group

ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = True
ldap_referrals = true

krb5_realm = EXAMPLE.ORG

ldap_search_base = dc=example,dc=org

[domain/project1.example.org]
debug_level = 5
cache_credentials = True
enumerate = False

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
access_provider = ldap

ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/scm.project1.example.org@PROJECT1.EXAMPLE.ORG

ldap_schema = rfc2307bis

ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_user_name = sAMAccountName

ldap_group_object_class = group

ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = True
ldap_referrals = true

krb5_realm = PROJECT1.EXAMPLE.ORG

ldap_search_base = dc=project1,dc=example,dc=org

[sudo]

[autofs]

[ssh]

[pac]

# cat /etc/krb5.conf
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.ORG
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
  EXAMPLE.ORG = {
  kdc = dc001.example.org
  kdc = dc002.example.org
  admin_server = dc001.example.org
 }

 PROJECT1.EXAMPLE.ORG = {
  kdc = dc001.project1.example.org
  admin_server = dc001.project1.example.org
 }

[domain_realm]
 example.org = EXAMPLE.ORG
 .example.org = EXAMPLE.ORG
 project1.example.org = PROJECT1.EXAMPLE.ORG
 .project1.example.org = PROJECT1.EXAMPLE.ORG

In the production infrascructure, scm1.project1.example.org doesn't seem to be able to login, using it's krb5.keytab, to dc001.example.org to make LDAP queries, and I'm not sure why.  For example:

# kinit -k -t /etc/krb5.keytab
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/scm.project1.example.org@PROJECT1.EXAMPLE.ORG

Valid starting     Expires            Service principal
12/17/13 16:42:33  12/18/13 02:43:03  krbtgt/PROJECT1.EXAMPLE.ORG@PROJECT1.EXAMPLE.ORG
        renew until 12/24/13 16:42:33
12/17/13 16:43:07  12/18/13 02:43:03  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
        renew until 12/24/13 16:42:33
# ldapsearch -H ldap://example.org -Y GSSAPI -N -b dc=example,dc=org "(&(objectClass=user)(sAMAccountName=username))"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Realm not local to KDC)

The "Realm not local to KDC" error could make me think that the search base that I am requesting isn't the same as that hosted by the domain controller, but that isn't the case.  If I query the local domain (project1.example.org), I get the expected referral:

# ldapsearch -H ldap://project1.example.org -Y GSSAPI -N -b dc=example,dc=org "(&(objectClass=user)(sAMAccountName=username))"
SASL/GSSAPI authentication started
SASL username: host/scm.project1.example.org@PROJECT1.EXAMPLE.ORG
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=org> with scope subtree
# filter: (&(objectClass=user)(sAMAccountName=username))
# requesting: ALL
#

# search result
search: 4
result: 10 Referral
text: 0000202B: RefErr: DSID-03100742, data 0, 1 access points
        ref 1: 'examp
 le.org'

ref: ldap://example.org/dc=example,dc=org

# numResponses: 1

Any suggestions would be greatly appreciated.

Thanks!
- Alex