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




Reply via email to