On Tue, Dec 17, 2013 at 11:51:15AM -0500, J. Alexander Jacocks wrote:
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(a)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(a)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(a)PROJECT1.EXAMPLE.ORG
Valid starting Expires Service principal
12/17/13 16:42:33 12/18/13 02:43:03 krbtgt/
PROJECT1.EXAMPLE.ORG(a)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(a)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(a)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.
"Realm not local to KDC" should be accompanied with a Kerberos client
referral telling the client which would be the right KDC to get a
suitable ticket. Can you send the output of
KRB5_TRACE=/dev/stdout ldapsearch -H