We've finally reached the point in replacing our old authentication system that I'm attempting to get GSSAPI working with our ldap.uvm.edu system.
We have five systems that are behind the LVS (Linux Virtual System) load balancer.
I've got GSSAPI partially working.
As long as I use the real name of the servers, ldapwhoami will return the correct information. However, when I try to use the load balanced name (ldap.uvm.edu), then the ldapwhoami fails with the following:
$ ldapwhoami -H ldap://ldap.uvm.edu SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49)
and what I find in syslog on the server that got the traffic is:
SASL [conn=864335] Failure: GSSAPI Error: Miscellaneous failure (Wrong principal in request) conn=864335 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
Our DNS is configured so that ldap.uvm.edu is 132.198.101.196, the PTR for that returns vip1.uvm.edu (which also forward resolves to 132.198.101.196).
I have set the KRB5_KTNAME environment variable to /etc/openldap/ldap.keytab, which contains the following keys ldap/<realname>.uvm.edu -- this is the real name of each of the five servers ldap/ldap.uvm.edu -- which I assume is extraneous ldap/vip1.uvm.edu
The /etc/krb5.keytab holds keys for host/<realname>.uvm.edu, host/ldap.uvm.edu, and host/vip1.uvm.edu. Again, I assume that the entry for host/ldap.uvm.edu is extraneous.
As I'm running on Linux, the 132.198.101.196 address is attached to the loopback interface on each of the ldap servers. Slapd is listening on 0.0.0.0:389 and 0.0.0.0:636.
I'm using OpenLDAP 2.3.43 and (Red Hat's) cyrus-sasl-2.1.19-14 package.
Is this a stupid configuration problem that I've somehow missed in the documentation, a bug that Red Hat hasn't back-ported in cyrus-sasl, or something else?
Thanks,