The Stanford OpenLDAP service relies almost exclusively on GSSAPI
authentication for its access control. This means clients doing LDAP
searches use Kerberos. Normally, Kerberos authentication depends on
specific DNS configuration.
----
Example: A client search
ldapsearch -h ldap.stanford.edu uid=joeuser
1. The client resolves ldap.stanford.edu resolves to address 171.64.13.16
2. The client does a reverse DNS lookup on this IP address to get a
hostname, in this case, ldap-lb.stanford.edu
3. If the hostname from step 2 does not match the host part of the
principal in one of the entries on the server's keytab file, the
Kerberos authentication will fail. In our example, 171.64.13.16 resolves
to ldap-lb.stanford.edu, which is the name used in the keytab file, so
everything is fine.
----
Because we control the IP addresses and DNS records on campus, it is no
problem to make sure that the PTR (i.e., "reverse") DNS records are
configured so that process works properly.
However, for services in the cloud this becomes more of a problem. It
seems that Amazon Web Services does not give us the option to control
the PTR DNS records to support Kerberos's reverse DNS authentication, at
least not when we are using their ELB (Elastic Load Balancer) service.
1. One option is to require all of customers to use Kerberos with the
reverse DNS lookup disabled. How much extra risk do we take on by not
using the reverse DNS check?
2. Is there another way to configure our Kerberos and/or OpenLDAP so
that clients using Kerberos with reverse DNS as part of the
authentication process still works?
Thanks, Adam Lewenberg
