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 621963 - SSSD: Document how to manually configure GSSAPI with SSSD LDAP back end
Summary: SSSD: Document how to manually configure GSSAPI with SSSD LDAP back end
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Deployment_Guide
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Martin Prpič
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On: 621541
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-06 16:09 UTC by Dmitri Pal
Modified: 2018-11-29 21:09 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 621541
Environment:
Last Closed: 2011-05-25 11:51:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Dmitri Pal 2010-08-06 16:09:00 UTC 
+++ This bug was initially created as a clone of Bug #621541 +++

Description of problem:
LDAP provider forks out a child process to make its kinit request. However, when the child attempts to perform the kinit, it's getting an error from libkrb5 saying that it cannot find a KDC for the realm.

(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [sdap_kinit_send] (6): Attempting kinit (/etc/krb5.keytab, spn/host@DOMAIN, DOMAIN, 86400)
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [create_tgt_req_send_buffer] (7): buffer size: 69
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [set_tgt_child_timeout] (6): Setting 6 seconds timeout for tgt child
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [write_pipe_handler] (6): All data has been sent!
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [read_pipe_handler] (6): EOF received, client finished
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [sdap_get_tgt_recv] (6): Child responded: 14 [Bad address]
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [sdap_kinit_done] (4): Could not get TGT: 14 [Bad address]
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [fo_set_port_status] (4): Marking port 389 of server 'SERVER' as 'not working'
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [sdap_check_gssapi_reconnect] (7): Client principal name is: [spn/host@DOMAIN]
(Thu Aug  5 13:03:03 2010) [sssd[be[D]]] [sdap_check_gssapi_reconnect] (1): krb5_cc_retrieve_cred failed.

Aug  5 13:20:59 slabstb249 [sssd[ldap_child[1947]]]: Failed to initialize credentials using keytab [/etc/krb5.keytab]: Cannot find KDC for requested realm. Unable to create GSSAPI-encrypted LDAP connection.

Version-Release number of selected component (if applicable):
1.2.2

--- Additional comment from mail on 2010-08-05 08:43:32 EDT ---

Here is the relevant sssd configuration section:

[domain/MYDOMAIN]
debug_level = 7
min_id = 500
enumerate = true
id_provider = ldap
chpass_provider = krb5
ldap_uri = ldap://ldapserver.mydomain
ldap_schema = rfc2307bis
ldap_user_search_base = dc=mydomain,dc=mytld
ldap_group_search_base = dc=d,dc=mydomain,dc=mytld
tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_sasl_mech = gssapi
ldap_sasl_authid = spn/host@MYDOMAIN
ldap_krb5_keytab = /etc/krb5.keytab
ldap_krb5_init_creds = true
ldap_krb5_ticket_lifetime = 86400
ldap_force_upper_case_realm = True
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = LoginShell
ldap_user_object_class = person
ldap_group_object_class = group

auth_provider = krb5
krb5_kdcip = mykdc
krb5_realm = MYDOMAIN
krb5_changepw_principle = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15

--- Additional comment from jhrozek on 2010-08-05 09:44:35 EDT ---

Would you mind setting SSSD_KRB5_LOCATOR_DEBUG=1 and running SSSD interactively (sssd -i -d 9)? You should see some extra debug messages from the locator plugin that tells libkrb which KDCs to use.

Also the logs you posted indicate that the realm is "DOMAIN" but the example config says "MYDOMAIN", I take that is just a result of sanitizing logs and config file in two different ways?

--- Additional comment from mail on 2010-08-05 11:03:32 EDT ---

yup, sorry. it's just an result of sanitizing the logs.

--- Additional comment from dpal on 2010-08-05 13:58:44 EDT ---

Please provide the debug logs as mentioned in comment #2.

--- Additional comment from mail on 2010-08-06 03:21:04 EDT ---

Here is the relevant logfile output:

(Fri Aug  6 09:17:31 2010) [sssd] [main] (7): ldap_child started.
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [unpack_buffer] (7): total buffer size: 69
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [unpack_buffer] (7): realm_str size: 9
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [unpack_buffer] (7): got realm_str: MYDOMAIN
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [unpack_buffer] (7): princ_str size: 28
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [unpack_buffer] (7): got princ_str: spn/host@MYDOMAIN
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [unpack_buffer] (7): keytab_name size: 16
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [unpack_buffer] (7): got keytab_name: /etc/krb5.keytab
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [unpack_buffer] (7): lifetime: 86400
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [ldap_child_get_tgt_sync] (4): Principal name is: [spn/host@MYDOMAIN]
[sssd_krb5_locator] sssd_krb5_locator_init called
[sssd_krb5_locator] open failed [2][No such file or directory].
[sssd_krb5_locator] get_krb5info failed.
[sssd_krb5_locator] sssd_krb5_locator_close called
[sssd_krb5_locator] sssd_krb5_locator_init called
[sssd_krb5_locator] open failed [2][No such file or directory].
[sssd_krb5_locator] get_krb5info failed.
[sssd_krb5_locator] sssd_krb5_locator_close called
[sssd_krb5_locator] sssd_krb5_locator_init called
[sssd_krb5_locator] open failed [2][No such file or directory].
[sssd_krb5_locator] get_krb5info failed.
[sssd_krb5_locator] sssd_krb5_locator_close called
[sssd_krb5_locator] sssd_krb5_locator_init called
[sssd_krb5_locator] open failed [2][No such file or directory].
[sssd_krb5_locator] get_krb5info failed.
[sssd_krb5_locator] sssd_krb5_locator_close called
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: Cannot find KDC for requested realm
(Fri Aug  6 09:17:31 2010) [[sssd[ldap_child[1942]]]] [main] (1): ldap_child_get_tgt_sync failed.
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [read_pipe_handler] (6): EOF received, client finished
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [sdap_get_tgt_recv] (6): Child responded: 14 [Bad address]
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [sdap_kinit_done] (4): Could not get TGT: 14 [Ungültige Adresse]
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [fo_set_port_status] (4): Marking port 389 of server 'server.mydomain' as 'not working'
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [sdap_check_gssapi_reconnect] (7): Client principal name is: [spn/d.ethz.ch@MYDOMAIN]
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [sdap_check_gssapi_reconnect] (1): krb5_cc_retrieve_cred failed.
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [be_run_offline_cb] (3): Going offline. Running callbacks.
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [ldap_id_enum_users_done] (1): Failed to enumerate users, retrying later!
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [ldap_id_enumerate_set_timer] (6): Scheduling next enumeration at 1281079351.1615020
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [child_sig_handler] (7): Waiting for child [1942].
(Fri Aug  6 09:17:31 2010) [sssd[be[MYDOMAIN]]] [child_sig_handler] (4): child [1942] finished successfully.
(Fri Aug  6 09:17:32 2010) [sssd[be[MYDOMAIN]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kdcinfo.MYDOMAIN], [2][Datei oder Verzeichnis nicht gefunden]
(Fri Aug  6 09:17:32 2010) [sssd[be[MYDOMAIN]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.MYDOMAIN], [2][Datei oder Verzeichnis nicht gefunden]
(Fri Aug  6 09:17:34 2010) [sssd[be[MYDOMAIN]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kdcinfo.MYDOMAIN], [2][Datei oder Verzeichnis nicht gefunden]
(Fri Aug  6 09:17:34 2010) [sssd[be[MYDOMAIN]]] [remove_krb5_info_files] (5): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.MYDOMAIN], [2][Datei oder Verzeichnis nicht gefunden]
(Fri Aug  6 09:17:41 2010) [sssd] [service_check_alive] (4): Checking service MYDOMAIN(1939) is still alive
(Fri Aug  6 09:17:41 2010) [sssd] [service_send_ping] (4): Pinging MYDOMAIN
(Fri Aug  6 09:17:41 2010) [sssd] [sbus_add_timeout] (8): 0x91857b8
(Fri Aug  6 09:17:41 2010) [sssd] [service_check_alive] (4): Checking service nss(1940) is still alive
(Fri Aug  6 09:17:41 2010) [sssd] [service_send_ping] (4): Pinging nss
(Fri Aug  6 09:17:41 2010) [sssd] [sbus_add_timeout] (8): 0x9194a70
(Fri Aug  6 09:17:41 2010) [sssd] [service_check_alive] (4): Checking service pam(1941) is still alive
(Fri Aug  6 09:17:41 2010) [sssd] [service_send_ping] (4): Pinging pam
(Fri Aug  6 09:17:41 2010) [sssd[nss]] [sbus_dispatch] (9): (Fri Aug  6 09:17:41 2010) [sssd] [sbus_add_timeout] (8): dbus conn: 978FF58
0x9183c20
(Fri Aug  6 09:17:41 2010) [sssd[nss]] [sbus_dispatch] (9): Dispatching.

--- Additional comment from jhrozek on 2010-08-06 12:08:32 EDT ---

I think I have found the issue - we don't create the kdcinfo file for the krb5 plugin when using LDAP provider with GSSAPI.

Marcus, one more question to be sure - you did *not* create the realm and KDCs in /etc/krb5.conf, correct?
Comment 2 Marcus Moeller 2010-08-06 16:52:44 UTC 
I did not even create a krb5.conf in first stage as I thought it's no longer necessary with sssd

Of course, afterwards, to receive the TGT manually, I had to create one.

Besides that I want to use service discovery via DNS for both, LDAP and KDC, so I left them out in sssd.conf, now. In krb5.conf I did not specify KDC(s) but dns_lookup_kdc.
Comment 3 Stephen Gallagher 2010-08-06 17:02:24 UTC 
Marcus, we plan to fix this upstream and include it in the SSSD 1.4.0 release. This is just to document the issue and workaround for RHEL 6.0
Comment 4 Jakub Hrozek 2010-08-09 09:45:12 UTC 
(In reply to comment #2)
> I did not even create a krb5.conf in first stage as I thought it's no longer
> necessary with sssd
> 

I wasn't implying that you needed to create one - it should not be necessary for GSSAPI bind to work - I was just trying to confirm my theory. Creating a krb5.conf is just a workaround that tells libkrb the needed properties such as KDCs. When the fix is implemented, it should no longer be needed for this use case.
Comment 5 Marcus Moeller 2010-08-09 11:35:58 UTC 
Is the kdcinfo file only created once or do I have to renew the TGT regularly?
Comment 6 Jakub Hrozek 2010-08-09 11:45:17 UTC 
(In reply to comment #5)
> Is the kdcinfo file only created once or do I have to renew the TGT regularly?    

That should be totally transparent and handled by the SSSD. No manual intervention needed.
Comment 7 Marcus Moeller 2010-08-09 13:19:37 UTC 
So it's only necessary to have a valid krb5.conf present, not to fetch a TGT manually?
Comment 8 Stephen Gallagher 2010-08-09 17:21:56 UTC 
Correct. SSSD performs the kinit internally.
Comment 9 Marcus Moeller 2010-08-09 18:27:38 UTC 
Okay, as mentioned before, I have now  set up sssd to use service discovery for both, LDAP and krb which works if a krb5.conf with at least one kdc is present.

If I remove the kdc entry from krb5.conf and enable dns_lookup_kdc instead I get an error like:

(Mon Aug  9 20:17:44 2010) [[sssd[ldap_child[5750]]]] [ldap_child_get_tgt_sync] (4): Principal name is: [spn/hosth@MYDOMAIN]
(Mon Aug  9 20:17:45 2010) [[sssd[ldap_child[5750]]]] [ldap_child_get_tgt_sync] (0): Failed to init credentials: KDC has no support for encryption type

Best Regards
Marcus
Comment 10 Marcus Moeller 2010-08-09 19:16:34 UTC 
Ah, verify_ap_req_nofail = false was missing :)
Comment 11 Marcus Moeller 2010-10-21 12:07:08 UTC 
kdc service discovery with sssd 1.4.0 does not seem to work. 

ccache is not retreived if no krb5_kdcip is given.
Comment 12 Stephen Gallagher 2010-10-21 12:12:06 UTC 
(In reply to comment #11)
> kdc service discovery with sssd 1.4.0 does not seem to work. 
> 
> ccache is not retreived if no krb5_kdcip is given.

Please attach your (sanitized) sssd.conf.
Comment 13 Marcus Moeller 2010-10-21 12:17:40 UTC 
ah, had to set dns_discrovery_domain because of a variant hostname.
Comment 15 David O'Brien 2010-12-16 01:28:45 UTC 
I'll go through all this info and add to SSSD section of the RHEL Deployment Guide.
Comment 16 David O'Brien 2010-12-22 02:34:41 UTC 
Reassigning to default as per discussion with dept leaders.
Note You need to log in before you can comment on or make changes to this bug.