6

I have a very similar problem as described in this thread on CentOS 6.3 authenticating against a 2008R2 AD DC.

Here is my krb5.conf, I know for a fact that XXXXXXX.LOCAL is the true domain name:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = XXXXXXX.LOCAL
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 verify_ap_req_nofail = false

[realms]
 XXXXXXX.LOCAL = {
 kdc = ad1.XXXXXXX.local
 kdc = ad2.XXXXXXX.local
 admin_server = ad1.XXXXXXX.local
 default_domain = XXXXXXX.LOCAL
}

[domain_realm]
 .XXXXXXX.local = XXXXXXX.LOCAL
 XXXXXXX.local = XXXXXXX.LOCAL
 .XXXXXXX.com = XXXXXXX.LOCAL
 XXXXXXX.com = XXXXXXX.LOCAL

When I do a:

kinit username@XXXXXXX.LOCAL

Everything works as intended, klist -e returns the details it should however when I try to:

su username

The sssd krb5_child.log shows the following:

[unpack_buffer] (0x0100): cmd [241] uid [10002] gid [10002] validate [false] offline [false] UPN [username@XXXXXXX.COM]
[unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_10002_XXXXXX] keytab: [/etc/krb5.keytab]
[krb5_child_setup] (0x0400): Will perform online auth
[krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
[krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment.
[krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [false]
[krb5_child_setup] (0x0100): Not using FAST.
[get_and_save_tgt] (0x0400): Attempting kinit for realm [XXXXXXX.COM]
[get_and_save_tgt] (0x0020): 977: [-1765328230][Cannot find KDC for requested realm]
[kerr_handle_error] (0x0020): 1030: [-1765328230][Cannot find KDC for requested realm]
[prepare_response_message] (0x0400): Building response for result [-1765328230]
[main] (0x0400): krb5_child completed successfully

I also know that XXXXXXX.COM is an alias for XXXXXXX.LOCAL in the AD tree and that running:

kinit username@XXXXXXX.COM

produces exactly the same error as in the krb5_child.log

kinit: Cannot find KDC for requested realm while getting initial credentials

I've been banging my head against the wall for several days on this problem and would appreciate any pointers. :)

Community
  • 1
Sauraus
  • 75
  • 1
  • 1
  • 7

4 Answers4

6

What you deal with is called enterprise principals. You have a single AD domain but users can have additional user principal names (UPN) associated, so in addition to XXXX.LOCAL they can have XXXX.COM and use user@XXXX.COM in place of user@XXXX.LOCAL.

SSSD does support enterprise principals starting with 1.10. There were few bugs in the implementation that affected 1.10 beta releases but they are solved prior to the final release which is available in Fedora 19+.

However, this change is not available in RHEL 6.x (or CentOS 6.x for that matter) since support for enterprise principals is relatively invasive and was not backported to 1.9.x.

You may be interested to look for details at https://bugzilla.redhat.com/show_bug.cgi?id=972357 and https://bugzilla.redhat.com/show_bug.cgi?id=924404

abbra
  • 1,085
  • 5
  • 8
4

If you don't specify the realm in the krb5.conf and you turn off DNS lookups, your host has no way of knowing that XXXXXX.COM is an alias for XXXXXX.LOCAL.

Add a realm section in your krb5.conf like this and see what happens. 

XXXXXXX.COM = {
 kdc = ad1.XXXXXXX.local
 kdc = ad2.XXXXXXX.local
 admin_server = ad1.XXXXXXX.local

}

Turning on dns lookups for realm and kdc would also accomplish the same thing. 

dig -t srv _kerberos._udp.XXXXXX.com

should be the real servers used above.

However, I'm not sure this is really the right thing. The krb5.conf should above should put you in the XXXXXX.LOCAL realm, trying to figure out why sssd is ignoring that might lead you more in the correct direction.

slm
  • 7,615
  • 16
  • 56
  • 76
Fred the Magic Wonder Dog
  • 2,095
  • 12
  • 17
  • If I do that and try to run kinit I get the following error: `kinit: Realm not local to KDC while getting initial credentials` – Sauraus Nov 20 '13 at 21:59
  • What are the results of `dig -t srv _kerberos._udp.XXXXXX.com` ? Those servers need to be in your krb5.conf or you need to convince sssd to use the realm mappings in krb5.conf. – Fred the Magic Wonder Dog Nov 21 '13 at 00:01
  • I ran the command unfortunately no dice :( `flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0` – Sauraus Nov 25 '13 at 18:25
2

I had a very similar problem on RHEL 6. I was already connected to the domain, but I kept seeing the error kinit-succeeded-but-ads_sasl_spnego_krb5_bind-failed in my logs.

This was the resolution for me, and I thought that it could be beneficial to you as well.

When I was looking in /var/log/samba I noticed two log.wb-* files. In my environment we have two different realms. I checked both log files. The log.wb-Correctrealm was empty. The log.wb-Incorrectrealm was the log file producing the error message listed above.

I checked out my samba config (/etc/samba/smb.conf) and I found the problem.

These lines had the incorrectrealm listed. 

idmap config Incorrectrealm:backend = rid
idmap config Incorrectrealm:range = 10000000-19999999

I changed the lines to reflect the correct realm

idmap config Correctrealm:backend = rid
idmap config Correctrealm:range = 10000000-19999999

and restarted the smb service. I then went back to my log files and the realm with log.wb-Correctrealm was now being populated.

This solved the error above.

I had not found this resolution anywhere else and just wanted to pass it along.

Signal15
  • 952
  • 7
  • 29
sjustice
  • 23
  • 3
1

You should properly configure not only krb5.conf but also sssd.conf -- either hard-code your server host names with krb5_server/ldap_server/whatnot or point resolv.conf at a server that can resolve the proper SRV records for you.

See also http://jhrozek.wordpress.com/2014/11/04/how-does-sssd-interact-with-tools-like-kinit/ for an overview of how sssd interacts with kinit/libkrb5.

jhrozek
  • 1,370
  • 6
  • 5