Bug 675352

Stephen will correct me if I am wrong but it seems that you have the domain foo.com configured. See the line:
domains = foo.com

Everything from the second domain (the default one) is ignored.

When you installed IPA what is the domain that you used? 
Did you use --realm argument when you installed IPA client?
If you do not specify it the client will assume that names of the IPA domain and Kerberos realm are the same (just capitalized). If you did and ended up with this, there is definitely a bug. If you didn't would you mind re-installing the client with the right command line options?

I took a look at the code. I see two problems here:

1) https://fedorahosted.org/freeipa/ticket/925
2) https://fedorahosted.org/freeipa/ticket/926

Thank you for reporting the issue!

Same result when using --realm from the command line, but I think you knew that was happening already.

Can you tell us what the contents of /etc/krb5.keytab are?

Please run the following as root:
ktutil

At the prompts, type:
ktutil:  rkt /etc/krb5.keytab
ktutil:  l

You should see output similar to:
slot KVNO Principal
---- ---- -----------------------------------
   1    2 host/vm-130.example.com
   2    2 host/vm-130.example.com
   3    2 host/vm-130.example.com
   4    2 host/vm-130.example.com
   5    2 host/vm-130.example.com
   6    2 host/vm-130.example.com


Please tell us whether host/sb.foo.com appears at least once in this list.

It does, also an easier way to get the listing is with klist -kK /etc/krb5.keytab.

-Erinn

I have two other ideas:

1) Can you try setting SELinux to permissive? I wonder if you are hitting a denial while reading the keytab.


2) Could you try adding:
ldap_krb5_keytab = /etc/krb5.keytab

To the [domain/foo.com] section of your sssd.conf? I'm wondering if for some reason your local copy of MIT kerberos doesn't default to /etc/krb5.keytab. (The message keytab file [(null)] means that it was trying to use the system default keytab). It's possible that the system default keytab location is set incorrectly (or that something is setting the KRB5_KTNAME environment variable).

It would help us understand if we could see /etc/krb5.conf too.

krb5.conf:

#File modified by ipa-client-install

[libdefaults]
  default_realm = LINUX.FOO.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  LINUX.FOO.COM = {
    kdc = ipa.foo.com:88
    admin_server = ipa.foo.com:749
    default_domain = foo.com
  }

[domain_realm]
  .foo.com = LINUX.FOO.COM
  foo.com = LINUX.FOO.COM

[appdefaults]
  pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
  }

1) Can you try setting SELinux to permissive? I wonder if you are hitting a
denial while reading the keytab.

Checked the audit logs and nothing, unless there is a dontaudit rule for this problem which isn't likely. Dropped it into permissive mode anyway and still the same

2) Could you try adding:
ldap_krb5_keytab = /etc/krb5.keytab

To the [domain/foo.com] section of your sssd.conf? I'm wondering if for some
reason your local copy of MIT kerberos doesn't default to /etc/krb5.keytab.
(The message keytab file [(null)] means that it was trying to use the system
default keytab). It's possible that the system default keytab location is set
incorrectly (or that something is setting the KRB5_KTNAME environment
variable).


Same result doing with that change added to sssd.conf. sssd was restarted as well. 

I want to draw your attention again to the error message and what appears to be going wrong to me, you may already be aware of this, but I just want to make sure:

Feb 20 00:29:57 sb [sssd[ldap_child[4092]]]: Error processing keytab file [(null)]: Principal [host/sb.foo.com] was not found. Unable to create GSSAPI-encrypted LDAP connection.

FOO.COM is not my realm, LINUX.FOO.COM is, why does it continue to search for that realm? Is this perhaps the crux of the issue, that it is searching for a key with that realm, which doesn't exist?

(In reply to comment #10)
> FOO.COM is not my realm, LINUX.FOO.COM is, why does it continue to search for
> that realm? Is this perhaps the crux of the issue, that it is searching for a
> key with that realm, which doesn't exist?

You are correct, I misread your initial bug report and thought that FOO.COM was the correct realm. If that's the case, the problem here is simple and obvious.

By default, the IPA provider in SSSD (when id_provider = ipa) uses the name of the SSSD domain as both the "IPA domain" and the "Kerberos Realm" for the purposes of setting up the connection.

Since your configuration domain is [domain/foo.com], SSSD assumes that the IPA domain name is "foo.com" and the associated Kerberos realm is "FOO.COM".

I'm assuming that foo.com IS in fact the IPA domain name, but that you chose a different REALM name. So in essence, your IPA domain name is "foo.com", but your Kerberos realm is "LINUX.FOO.COM".

This can be resolved by adding the line:
krb5_realm = LINUX.FOO.COM
into the [domain/foo.com] section of your sssd.conf.

Assuming that this works, I'm turning this bug back over to ipa-client, as it's a bug in the client setup that it did not set this option appropriately when the Kerberos realm != IPA domain.

Correct, and adding that line resolved that issue (on to the next issues;), and it looks like a patch was submitted to fix the ipa-client issue. I don't know what sort of magic it takes to get that back ported into RHEL 6, but let me know if you need a support ticket opened so that resources can be assigned.

-Erinn

(In reply to comment #12)
> Correct, and adding that line resolved that issue (on to the next issues;), and
> it looks like a patch was submitted to fix the ipa-client issue. I don't know
> what sort of magic it takes to get that back ported into RHEL 6, but let me
> know if you need a support ticket opened so that resources can be assigned.
> 
> -Erinn

The ipa-client in 6.1 will have significant changes over the one in 6.0 so this effort is already accounted for.

master: f34c0ab91673ad12edd937e6f3b0e97811f06d6e
master: e7ed4035b5bc7bf57d54f5b8dfd789af16671d4b

verified:

install IPA with :

ipa-server-install --setup-dns --hostname=hp-sl2x170zg6-02.linux.testrelm -r TESTRELM -n linux.testrelm -p password -P password -a password -U

sssd.conf after installation:

[sssd]
services = nss, pam
config_file_version = 2

domains = linux.testrelm
[nss]

[pam]

[domain/linux.testrelm]
cache_credentials = True
krb5_realm = TESTRELM   <================================
ipa_domain = linux.testrelm  <===============================
id_provider = ipa
auth_provider = ipa
access_provider = ipa
chpass_provider = ipa
ipa_server = _srv_, hp-sl2x170zg6-02.linux.testrelm

[domain/default]
cache_credentials = True
krb5_realm = TESTRELM   <================================
krb5_kdcip = hp-sl2x170zg6-02.linux.testrelm:88
auth_provider = krb5
chpass_provider = krb5
krb5_kpasswd = hp-sl2x170zg6-02.linux.testrelm:749


# kinit admin
Password for admin@TESTRELM: 

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@TESTRELM

Valid starting     Expires            Service principal
03/11/11 11:44:02  03/12/11 11:43:59  krbtgt/TESTRELM@TESTRELM

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@TESTRELM

Valid starting     Expires            Service principal
03/11/11 11:44:02  03/12/11 11:43:59  krbtgt/TESTRELM@TESTRELM


# klist -k
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/hp-sl2x170zg6-02.linux.testrelm@TESTRELM
   2 host/hp-sl2x170zg6-02.linux.testrelm@TESTRELM
   2 host/hp-sl2x170zg6-02.linux.testrelm@TESTRELM
   2 host/hp-sl2x170zg6-02.linux.testrelm@TESTRELM
   2 host/hp-sl2x170zg6-02.linux.testrelm@TESTRELM
   2 host/hp-sl2x170zg6-02.linux.testrelm@TESTRELM

krb5.conf

# 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 = TESTRELM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 rdns = false
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 TESTRELM = {
  kdc = hp-sl2x170zg6-02.linux.testrelm:88
  admin_server = hp-sl2x170zg6-02.linux.testrelm:749
  default_domain = linux.testrelm
  pkinit_anchors = FILE:/etc/ipa/ca.crt
}

[domain_realm]
 .linux.testrelm = TESTRELM
 linux.testrelm = TESTRELM

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

[dbmodules]
  TESTRELM = {
    db_library = kldap
    ldap_servers = ldapi://%2fvar%2frun%2fslapd-TESTRELM.socket
    ldap_kerberos_container_dn = cn=kerberos,dc=testrelm
    ldap_kdc_dn = uid=kdc,cn=sysaccounts,cn=etc,dc=testrelm
    ldap_kadmind_dn = uid=kdc,cn=sysaccounts,cn=etc,dc=testrelm
    ldap_service_password_file = /var/kerberos/krb5kdc/ldappwd
  }

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0631.html