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
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?
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.
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.
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.
Putting in the NEEDINFO state to see if the original bug reporter can still reproduce this issue.
(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!
(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.
This is covered under the test suit SSSASL test case - sssaslgss_002(). Marking this as VERIFIED. (thanks to Chandra for quick help).