RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 675352 - Unable to create encrypted connection with kerberos
Summary: Unable to create encrypted connection with kerberos
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa
Version: 6.0
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Rob Crittenden
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-05 01:16 UTC by Erinn Looney-Triggs
Modified: 2018-11-14 14:23 UTC (History)
9 users (show)

Fixed In Version: ipa-2.0.0-12.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 13:44:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:0631 0 normal SHIPPED_LIVE new package: ipa 2011-05-18 17:55:55 UTC

Description Erinn Looney-Triggs 2011-02-05 01:16:01 UTC
Description of problem:
An encrypted connection using kerberos is not able to be created, see the following:

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

Interesting thing is FOO.COM is not my Kerb Realm it is LINUX.FOO.COM, I am not sure where this misconfiguration is coming from. 

Here is a copy of my /etc/sssd.conf:

[sssd]
services = nss, pam
config_file_version = 2

domains = foo.com
[nss]

[pam]

[domain/foo.com]
cache_credentials = True
chpass_provider = ipa
ipa_domain = foo.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
debug_level = 0
ipa_server = ipa.foo.com

[domain/default]
cache_credentials = True
krb5_realm = LINUX.FOO.COM
chpass_provider = krb5
krb5_kdcip = ipa.foo.com:88
auth_provider = krb5
debug_level = 0
krb5_kpasswd = ipa.foo.com:749


In my /etc/krb5.keytab file there is a proper host key for the LINUX.FOO.COM realm, but clearly it is looking for the wrong realm, as well I am not sure what is going on with the 'null'. This is a default ipa-client-install run with a freeipa v2 beta 2 server. 

sssd-1.2.1-28.el6_0.4.x86_64
ipa-client-2.0-9.el6.x86_64

Comment 2 Dmitri Pal 2011-02-05 16:12:43 UTC
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?

Comment 3 Dmitri Pal 2011-02-05 17:24:13 UTC
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!

Comment 4 Erinn Looney-Triggs 2011-02-06 21:51:04 UTC
Same result when using --realm from the command line, but I think you knew that was happening already.

Comment 5 Stephen Gallagher 2011-02-17 18:10:31 UTC
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.

Comment 6 Erinn Looney-Triggs 2011-02-17 18:18:38 UTC
It does, also an easier way to get the listing is with klist -kK /etc/krb5.keytab.

-Erinn

Comment 7 Stephen Gallagher 2011-02-17 18:56:26 UTC
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).

Comment 8 Rob Crittenden 2011-02-17 22:16:14 UTC
It would help us understand if we could see /etc/krb5.conf too.

Comment 9 Erinn Looney-Triggs 2011-02-20 00:25:12 UTC
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
  }

Comment 10 Erinn Looney-Triggs 2011-02-20 00:35:56 UTC
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?

Comment 11 Stephen Gallagher 2011-02-21 11:57:02 UTC
(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.

Comment 12 Erinn Looney-Triggs 2011-02-21 15:59:34 UTC
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

Comment 13 Dmitri Pal 2011-02-21 20:37:11 UTC
(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.

Comment 14 Dmitri Pal 2011-02-23 22:48:06 UTC
master: f34c0ab91673ad12edd937e6f3b0e97811f06d6e
master: e7ed4035b5bc7bf57d54f5b8dfd789af16671d4b

Comment 18 Jenny Severance 2011-03-11 16:51:24 UTC
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
  }

Comment 19 errata-xmlrpc 2011-05-19 13:44:25 UTC
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


Note You need to log in before you can comment on or make changes to this bug.