Bug 525822

Summary: SASL/GSSAPI bind in server to server connections doesn't work when the kdc uses 389 as its backend
Product: [Retired] 389 Reporter: Loris Santamaria <loris>
Component: Replication - GeneralAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: high Docs Contact:
Priority: high    
Version: 1.2.1CC: amsharma, dpal, jgalipea, nkinder, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 17:09:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 576869, 639035    

Description Loris Santamaria 2009-09-26 00:38:13 UTC
Description of problem:

Trying SASL/GSSAPI in replication we found that if the kdc stores the data in 389ds, when starting the server it cannot obtains its ticket, so it won't connect to the replicas.

This is obvious, the kdc can't grant a ticket if it's backend hasn't started yet, so the solution would be that 389 should try to obtain its ticket later. But it doesn't

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

1.2.2

How reproducible:

Always

Steps to Reproduce:
1. restart dirsrv
  
Actual results:

[25/Sep/2009:20:06:15 -041800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [uid=rmanager,cn=config] mech [GSSAPI]: error 82 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Unknown code krb5 195))
[25/Sep/2009:20:06:15 -041800] slapi_ldap_bind - Error: could not perform interactive bind for id [uid=rmanager,cn=config] mech [GSSAPI]: error 82 (Local error)
[25/Sep/2009:20:06:15 -041800] NSMMReplicationPlugin - agmt="cn=pzo2ccs" (central:389): Replication bind with GSSAPI auth failed: LDAP error 82 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Unknown code krb5 195))

Expected results:

replication starts normally after a while

Comment 4 Nathan Kinder 2010-12-15 22:13:41 UTC
I have not been able to reproduce this problem.  Here's what I did to try to reproduce:

- Install FreeIPA with DS (FreeIPA sets up a KDC using 389 as the backend).
- Configure a second DS instance.
- Configure replication over SASL/GSSAPI from the IPA/KDC 389 instance to the second instance.

The total update works fine, and restarting the 389 instance used by the KDC works fine.  The way FreeIPA configures 389 for SASL/GSSAPI is to use a keytab that is referenced by the KRB5_KTNAME environment variable that is set in /etc/sysconfig/dirsrv.

When the problem occurred, were you using a keytab for the 389 ticket, or were you using kinit to get the ticket from /etc/sysconfig/dirsrv?

Comment 5 Nathan Kinder 2010-12-16 18:26:19 UTC
After discussing this issue with Simo, I was able to reproduce the issue.  It requiried restarting my kdc prior to restarting 389.  In my case, I saw errors attempting to get the ticket on startup, but we retry getting the ticket again when we attempt to bind to the replica.  Here are my logs:

[15/Dec/2010:14:48:10 -0800] - slapd started.  Listening on All Interfaces port 389 for LDAP requests
[15/Dec/2010:14:48:10 -0800] - Listening on All Interfaces port 636 for LDAPS requests
[15/Dec/2010:14:48:10 -0800] - Listening on /var/run/slapd-EXAMPLE-COM.socket for LDAPI requests
[15/Dec/2010:14:48:10 -0800] set_krb5_creds - Could not get initial credentials for principal [ldap/spool.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text))
[15/Dec/2010:14:48:10 -0800] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_490' not found))
[15/Dec/2010:14:48:10 -0800] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
[15/Dec/2010:14:48:10 -0800] NSMMReplicationPlugin - agmt="cn=ipaToTest" (spool:1389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Credentials cache file '/tmp/krb5cc_490' not found))
[15/Dec/2010:14:48:16 -0800] NSMMReplicationPlugin - agmt="cn=ipaToTest" (spool:1389): Replication bind with GSSAPI auth resumed

My errors do look a bit different than those reported, so I'm not sure if there is something else to this issue.  From looking at the code, we should attempt to get the ticket if it is not available each time we bind to the replica.

Comment 6 Nathan Kinder 2010-12-16 18:59:21 UTC
If you are able to reproduce this issue, please set nsslapd-errorlog-level to 1024 in "cn=config".  This will produce debug logging around getting the ticket.

Comment 7 Simo Sorce 2010-12-16 21:00:42 UTC
Apparently I can't reproduce the issue anymore with latest 389 ds.
I tried both on F14 and F13 and replication just resumes 6 seconds after the first try, and the second time DS can get its ticket and all is fine.

From my pov I guess we can consider this fixed, unless the original reporter can reproduce.

Comment 8 Nathan Kinder 2010-12-18 00:05:09 UTC
Putting in the NEEDINFO state to see if the original bug reporter can still reproduce this issue.

Comment 9 Loris Santamaria 2010-12-20 14:54:56 UTC
(In reply to comment #5)

> My errors do look a bit different than those reported, so I'm not sure if there
> is something else to this issue.  From looking at the code, we should attempt
> to get the ticket if it is not available each time we bind to the replica.

Using 389-ds-base-1.2.6 I get the same errors as in comment #5, but with 389-ds-base-1.2.7.5 replication seems to work correctly.

So yes, it looks like the issue has been solved!

Comment 10 Nathan Kinder 2011-01-03 15:35:51 UTC
(In reply to comment #9)
> 
> Using 389-ds-base-1.2.6 I get the same errors as in comment #5, but with
> 389-ds-base-1.2.7.5 replication seems to work correctly.
> 
> So yes, it looks like the issue has been solved!

Thanks for the update.  I'm going to mark this as MODIFIED.

Comment 11 Amita Sharma 2011-06-02 17:47:01 UTC
This is covered under the test suit SSSASL test case  - sssaslgss_002().
Marking this as VERIFIED. (thanks to Chandra for quick help).