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
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@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.
"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 ldap://example.org -Y GSSAPI ...
to see where the request fails?
bye, Sumit
Thanks!
- Alex
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
"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 ldap://example.org -Y GSSAPI ...
to see where the request fails?
Sure, here is the output:
# KRB5_TRACE=/dev/stdout ldapsearch -H ldap://dc001.example.org -Y GSSAPI -N -b dc=example,dc=org "(&(objectClass=user)(sAMAccountName=username))" SASL/GSSAPI authentication started [15321] 1387302064.607342: ccselect can't find appropriate cache for server principal ldap/dc001.example.org@EXAMPLE.ORG [15321] 1387302064.607479: Retrieving host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [15321] 1387302064.607522: Getting credentials host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> ldap/ dc001.example.org@EXAMPLE.ORG using ccache FILE:/tmp/krb5cc_0 [15321] 1387302064.607644: Retrieving host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> ldap/ dc001.example.org@EXAMPLE.ORG from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [15321] 1387302064.607874: Retrieving host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> krbtgt/ EXAMPLE.ORG@PROJECT1.EXAMPLE.ORG from FILE:/tmp/krb5cc_0 with result: 0/Success [15321] 1387302064.607893: Found cached TGT for service realm: host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> krbtgt/ EXAMPLE.ORG@PROJECT1.EXAMPLE.ORG [15321] 1387302064.607904: Requesting tickets for ldap/ dc001.example.org@EXAMPLE.ORG, referrals on [15321] 1387302064.607973: Generated subkey for TGS request: rc4-hmac/E967 [15321] 1387302064.607993: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac [15321] 1387302064.608245: Sending request (1650 bytes) to EXAMPLE.ORG [15321] 1387302064.608565: Initiating TCP connection to stream 172.16.50.2:88 [15321] 1387302064.609355: Sending TCP request to stream 172.16.50.2:88 [15321] 1387302064.610199: Received answer from stream 172.16.50.2:88 [15321] 1387302064.610398: Response was from master KDC [15321] 1387302064.610432: TGS request result: -1765328316/Realm not local to KDC [15321] 1387302064.610443: Requesting tickets for ldap/ dc001.example.org@EXAMPLE.ORG, referrals off [15321] 1387302064.610479: Generated subkey for TGS request: rc4-hmac/3291 [15321] 1387302064.610498: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac [15321] 1387302064.610636: Sending request (1650 bytes) to EXAMPLE.ORG [15321] 1387302064.610987: Initiating TCP connection to stream 172.16.50.2:88 [15321] 1387302064.611340: Sending TCP request to stream 172.16.50.2:88 [15321] 1387302064.611909: Received answer from stream 172.16.50.2:88 [15321] 1387302064.612016: Response was from master KDC [15321] 1387302064.612042: TGS request result: -1765328316/Realm not local to KDC 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 odd thing that I see here is that EXAMPLE.ORG is not IP address 172.16.50.2. That IP address belongs to dc001.project1.example.org. Any thoughts on that?
Thanks! - Alex
On Tue, Dec 17, 2013 at 12:50:47PM -0500, J. Alexander Jacocks wrote:
"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 ldap://example.org -Y GSSAPI ...
to see where the request fails?
Sure, here is the output:
# KRB5_TRACE=/dev/stdout ldapsearch -H ldap://dc001.example.org -Y GSSAPI -N -b dc=example,dc=org "(&(objectClass=user)(sAMAccountName=username))" SASL/GSSAPI authentication started [15321] 1387302064.607342: ccselect can't find appropriate cache for server principal ldap/dc001.example.org@EXAMPLE.ORG [15321] 1387302064.607479: Retrieving host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> krb5_ccache_conf_data/proxy_impersonator@X-CACHECONF: from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [15321] 1387302064.607522: Getting credentials host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> ldap/ dc001.example.org@EXAMPLE.ORG using ccache FILE:/tmp/krb5cc_0 [15321] 1387302064.607644: Retrieving host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> ldap/ dc001.example.org@EXAMPLE.ORG from FILE:/tmp/krb5cc_0 with result: -1765328243/Matching credential not found [15321] 1387302064.607874: Retrieving host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> krbtgt/ EXAMPLE.ORG@PROJECT1.EXAMPLE.ORG from FILE:/tmp/krb5cc_0 with result: 0/Success [15321] 1387302064.607893: Found cached TGT for service realm: host/ scm.project1.example.org@PROJECT1.EXAMPLE.ORG -> krbtgt/ EXAMPLE.ORG@PROJECT1.EXAMPLE.ORG [15321] 1387302064.607904: Requesting tickets for ldap/ dc001.example.org@EXAMPLE.ORG, referrals on [15321] 1387302064.607973: Generated subkey for TGS request: rc4-hmac/E967 [15321] 1387302064.607993: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac [15321] 1387302064.608245: Sending request (1650 bytes) to EXAMPLE.ORG [15321] 1387302064.608565: Initiating TCP connection to stream 172.16.50.2:88 [15321] 1387302064.609355: Sending TCP request to stream 172.16.50.2:88 [15321] 1387302064.610199: Received answer from stream 172.16.50.2:88 [15321] 1387302064.610398: Response was from master KDC [15321] 1387302064.610432: TGS request result: -1765328316/Realm not local to KDC [15321] 1387302064.610443: Requesting tickets for ldap/ dc001.example.org@EXAMPLE.ORG, referrals off [15321] 1387302064.610479: Generated subkey for TGS request: rc4-hmac/3291 [15321] 1387302064.610498: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac [15321] 1387302064.610636: Sending request (1650 bytes) to EXAMPLE.ORG [15321] 1387302064.610987: Initiating TCP connection to stream 172.16.50.2:88 [15321] 1387302064.611340: Sending TCP request to stream 172.16.50.2:88 [15321] 1387302064.611909: Received answer from stream 172.16.50.2:88 [15321] 1387302064.612016: Response was from master KDC [15321] 1387302064.612042: TGS request result: -1765328316/Realm not local to KDC 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 odd thing that I see here is that EXAMPLE.ORG is not IP address 172.16.50.2. That IP address belongs to dc001.project1.example.org. Any thoughts on that?
yes, that's odd and would explain the issue. Please check /etc/hosts if all entries for dc001.example.org, dc002.example.org and dc001.project1.example.org are correct. If this is the case, please check you DNS servers.
HTH
bye, Sumit
Thanks!
- Alex
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 12/17/2013 11:51 AM, 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 http://example.org -> ou=User Accounts,dc=example,dc=org
| |--> project1.example.org http://project1.example.org => ou=User Accounts,dc=project1,dc=example,dc=org | |--> project2.example.org http://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 http://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 http://dc001.project1.example.org, so that scm.project1.example.org http://scm.project1.example.org could query for user accounts.
# cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 domains = example.org http://example.org, project1.example.org http://project1.example.org services = nss, pam debug_level = 0
[nss]
[pam]
[domain/example.org http://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 mailto: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 http://EXAMPLE.ORG
ldap_search_base = dc=example,dc=org
[domain/project1.example.org http://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 mailto: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 http://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 http://EXAMPLE.ORG dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true
[realms] EXAMPLE.ORG http://EXAMPLE.ORG = { kdc = dc001.example.org http://dc001.example.org kdc = dc002.example.org http://dc002.example.org admin_server = dc001.example.org http://dc001.example.org }
PROJECT1.EXAMPLE.ORG http://PROJECT1.EXAMPLE.ORG = { kdc = dc001.project1.example.org http://dc001.project1.example.org admin_server = dc001.project1.example.org http://dc001.project1.example.org }
[domain_realm] example.org http://example.org = EXAMPLE.ORG http://EXAMPLE.ORG .example.org http://example.org = EXAMPLE.ORG http://EXAMPLE.ORG project1.example.org http://project1.example.org = PROJECT1.EXAMPLE.ORG http://PROJECT1.EXAMPLE.ORG .project1.example.org http://project1.example.org = PROJECT1.EXAMPLE.ORG http://PROJECT1.EXAMPLE.ORG
In the production infrascructure, scm1.project1.example.org http://scm1.project1.example.org doesn't seem to be able to login, using it's krb5.keytab, to dc001.example.org http://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 mailto: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 mailto: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 mailto:EXAMPLE.ORG@EXAMPLE.ORG renew until 12/24/13 16:42:33 # ldapsearch -H ldap://example.org http://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 http://project1.example.org), I get the expected referral:
# ldapsearch -H ldap://project1.example.org http://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 mailto: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 http://le.org'
ref: ldap://example.org/dc=example,dc=org http://example.org/dc=example,dc=org
# numResponses: 1
Any suggestions would be greatly appreciated.
Thanks!
- Alex
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Just FYI, the latest released upstream SSSD 1.11 has the support of the multiple domains.
On Tue, Dec 17, 2013 at 4:06 PM, Dmitri Pal dpal@redhat.com wrote:
Just FYI, the latest released upstream SSSD 1.11 has the support of the multiple domains.
Dmitri,
Are you saying that the current version of sssd, in RHEL/clones will not support the config that I have? If so, what path should I take? I am not under the impression that SSSD's major version will be bumped, in RHEL 6.
Thanks! - Alex
On 12/17/2013 04:19 PM, J. Alexander Jacocks wrote:
On Tue, Dec 17, 2013 at 4:06 PM, Dmitri Pal <dpal@redhat.com mailto:dpal@redhat.com> wrote:
Just FYI, the latest released upstream SSSD 1.11 has the support of the multiple domains.Dmitri,
Are you saying that the current version of sssd, in RHEL/clones will not support the config that I have? If so, what path should I take? I am not under the impression that SSSD's major version will be bumped, in RHEL 6.
Thanks!
- Alex
I am just saying that you are trying to emulate multiple AD domains support with the LDAP back end and kerberos. You might be successful but it is complex so we created AD provider in version SSSD 1.9 that went into 6.4. But it did not support multiple domains. Just one. In the course of versions 1.10 and 1.11 we added ability to support trusted AD domains in the same forest. This is coming in RHEL7 which is in beta now. But since you are using RHEL clones you might consider taking upstream release 1.11.x, building it yourself and trying.
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
J. Alexander Jacocks -
Sumit Bose