Hi There,
I have an openldap master (hosted by server) and an openldap replica (hosted by replica). Authentication use SASL/GSSAPI with kerberos.
On the master i get the following output : server:~ admin$ kinit root Please enter the password for root@SERVER.LAN: server:~ admin$ ldapsearch -b cn=mounts,dc=server,dc=lan SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific ) error (80)
On the replica all looks fine : replica:~ admin$ kinit root Please enter the password for root@SERVER.LAN: server:~ admin$ ldapsearch -b cn=mounts,dc=server,dc=lan SASL/GSSAPI authentication started SASL username: root@SERVER.LAN SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=mounts,dc=server,dc=lan> with scope subtree # filter: (objectclass=*) # requesting: ALL # etc ...
I saw some thread on mailing list that say to take care of owner, groups and permissions of files krb5.keytab and database. All looks good in this side.
Any other areas to check ?
Regards,
On 05/07/11 17:52 +0200, Fabien COMBERNOUS wrote:
Hi There,
I have an openldap master (hosted by server) and an openldap replica (hosted by replica). Authentication use SASL/GSSAPI with kerberos.
On the master i get the following output : server:~ admin$ kinit root Please enter the password for root@SERVER.LAN: server:~ admin$ ldapsearch -b cn=mounts,dc=server,dc=lan SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific ) error (80)
What does your /etc/ldap.conf and ~/.ldaprc look like?
You might try adding a '-d -1' to your ldapsearch command for additional debugging information.
What does you credentials cache look like after running the ldapsearch? Did you receive an ldap service ticket for the replica server? Are you sure you're referencing the replica by name, and not by IP address in your ldap.conf?
Do you see any additional errors in your local auth-facility syslog file? Do you see anything relevant in the syslog of your Kerberos server?
On the replica all looks fine : replica:~ admin$ kinit root Please enter the password for root@SERVER.LAN: server:~ admin$ ldapsearch -b cn=mounts,dc=server,dc=lan SASL/GSSAPI authentication started SASL username: root@SERVER.LAN SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=mounts,dc=server,dc=lan> with scope subtree # filter: (objectclass=*) # requesting: ALL # etc ...
I saw some thread on mailing list that say to take care of owner, groups and permissions of files krb5.keytab and database. All looks good in this side.
Any other areas to check ?
Hi there,
Thank you Dan to provide help.
On 07/07/2011 17:10, Dan White wrote:
On 05/07/11 17:52 +0200, Fabien COMBERNOUS wrote:
Hi There,
I have an openldap master (hosted by server) and an openldap replica (hosted by replica). Authentication use SASL/GSSAPI with kerberos.
On the master i get the following output : server:~ admin$ kinit root Please enter the password for root@SERVER.LAN: server:~ admin$ ldapsearch -b cn=mounts,dc=server,dc=lan SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific ) error (80)
What does your /etc/ldap.conf and ~/.ldaprc look like?
You might try adding a '-d -1' to your ldapsearch command for additional debugging information.
With the debug i get the following message
res_errno: 80, res_error: <SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Key table entry not found)>, res_matched: <>
(Remark : As information i provide the entire debug at the end of this message)
Because of the message "keytable entry not found", i tried to use kadmin and check if principle with root exists. But by using kadmin i get now this message :
server:~ admin$ kadmin -p root@SERVER.LAN Couldn't open log file /var/log/krb5kdc/kadmin.log: Permission denied Authenticating as principal root@SERVER.LAN with password. Password for root@SERVER.LAN: kadmin: Communication failure with server while initializing kadmin interface server:~ admin$
I check the logfile owner, group owner, and permission. Then i compared with one other kerberos server. Permission and owner was different. I set permission identically. But nothing was changed.
With kadmin.local i checked and root@SERVER.LAN exists in the list.
So it looks more a kerberos issues than a ldap one.
Regards,
PS : server:~ admin$ kinit root Please enter the password for root@SERVER.LAN: server:~ admin$ klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: root@SERVER.LAN
Valid Starting Expires Service Principal 07/07/11 17:50:19 07/08/11 03:50:09 krbtgt/SERVER.LAN@SERVER.LAN renew until 07/14/11 17:50:19
server:~ admin$ ldapsearch -d 1 -b cn=mounts,dc=server,dc=lan ldap_create ldap_pvt_sasl_getmech ldap_search put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 64 bytes to sd 3 ldap_result ld 0x100117f70 msgid 1 ldap_chkResponseList ld 0x100117f70 msgid 1 all 1 ldap_chkResponseList returns ld 0x100117f70 NULL wait4msg ld 0x100117f70 msgid 1 (infinite timeout) wait4msg continue ld 0x100117f70 msgid 1 all 1 ** ld 0x100117f70 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Thu Jul 7 17:51:40 2011
** ld 0x100117f70 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x100117f70 request count 1 (abandoned 0) ** ld 0x100117f70 Red-Black Tree Response Queue: Empty ld 0x100117f70 response count 1 ldap_chkResponseList ld 0x100117f70 msgid 1 all 1 ldap_chkResponseList returns ld 0x100117f70 NULL ldap_int_select read1msg: ld 0x100117f70 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 56 contents: read1msg: ld 0x100117f70 msgid 1 message type search-entry wait4msg continue ld 0x100117f70 msgid 1 all 1 ** ld 0x100117f70 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Thu Jul 7 17:51:40 2011
** ld 0x100117f70 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x100117f70 request count 1 (abandoned 0) ** ld 0x100117f70 Red-Black Tree Response Queue: * msgid 1, type 100 ld 0x100117f70 response count 1 ldap_chkResponseList ld 0x100117f70 msgid 1 all 1 ldap_chkResponseList returns ld 0x100117f70 NULL ldap_int_select read1msg: ld 0x100117f70 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x100117f70 msgid 1 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x100117f70 0 new referrals read1msg: mark request completed, ld 0x100117f70 msgid 1 request done: ld 0x100117f70 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 adding response ld 0x100117f70 msgid 1 type 101: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_get_values ber_scanf fmt ({x{{a) ber: ber_scanf fmt ([v]) ber: ldap_msgfree ldap_sasl_interactive_bind_s: server supports: CRAM-MD5 GSSAPI ldap_int_sasl_bind: CRAM-MD5 GSSAPI ldap_int_sasl_open: host=server.lan SASL/GSSAPI authentication started ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 703 bytes to sd 3 ldap_result ld 0x100117f70 msgid 2 ldap_chkResponseList ld 0x100117f70 msgid 2 all 1 ldap_chkResponseList returns ld 0x100117f70 NULL wait4msg ld 0x100117f70 msgid 2 (infinite timeout) wait4msg continue ld 0x100117f70 msgid 2 all 1 ** ld 0x100117f70 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Thu Jul 7 17:51:40 2011
** ld 0x100117f70 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x100117f70 request count 1 (abandoned 0) ** ld 0x100117f70 Red-Black Tree Response Queue: Empty ld 0x100117f70 response count 1 ldap_chkResponseList ld 0x100117f70 msgid 2 all 1 ldap_chkResponseList returns ld 0x100117f70 NULL ldap_int_select read1msg: ld 0x100117f70 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 148 contents: read1msg: ld 0x100117f70 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x100117f70 0 new referrals read1msg: mark request completed, ld 0x100117f70 msgid 2 request done: ld 0x100117f70 msgid 2 res_errno: 80, res_error: <SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Key table entry not found)>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) server:~ admin$ klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: root@SERVER.LAN
Valid Starting Expires Service Principal 07/07/11 17:50:19 07/08/11 03:50:09 krbtgt/SERVER.LAN@SERVER.LAN renew until 07/14/11 17:50:19
07/07/11 17:51:40 07/08/11 03:50:09 ldap/SERVER.LAN@SERVER.LAN renew until 07/14/11 17:50:19
openldap-technical@openldap.org