Hi all,
In the course of my research into a solution involving Kerberos, OpenLDAP and OpenAFS (a.k.a. the Magic Trio), I've discovered that both Kerberos and OpenAFS support methods of DNS discovery, but that OpenLDAP apparently does not. Is this correct?
If so, might there be a reason for this, other than that it has occurred to the developers, but that they just haven't had time yet to create it? It seems to me that it would be great to have.
Thanks,
Jaap
Jaap Winius jwinius@umrk.nl writes:
In the course of my research into a solution involving Kerberos, OpenLDAP and OpenAFS (a.k.a. the Magic Trio), I've discovered that both Kerberos and OpenAFS support methods of DNS discovery, but that OpenLDAP apparently does not. Is this correct?
OpenLDAP's command-line tools support service discovery using DNS SRV records. See, for instance, the ldapsearch man page:
-H ldapuri Specify URI(s) referring to the ldap server(s); a list of URI, separated by whitespace or commas is expected; only the protocol/host/port fields are allowed. As an exception, if no host/port is specified, but a DN is, the DN is used to look up the corresponding host(s) using the DNS SRV records, according to RFC 2782.
I'm not sure if this is also available directly in the library or if the client has to implement it.
Russ Allbery wrote:
Jaap Winiusjwinius@umrk.nl writes:
In the course of my research into a solution involving Kerberos, OpenLDAP and OpenAFS (a.k.a. the Magic Trio), I've discovered that both Kerberos and OpenAFS support methods of DNS discovery, but that OpenLDAP apparently does not. Is this correct?
OpenLDAP's command-line tools support service discovery using DNS SRV records. See, for instance, the ldapsearch man page:
-H ldapuri Specify URI(s) referring to the ldap server(s); a list of URI, separated by whitespace or commas is expected; only the protocol/host/port fields are allowed. As an exception, if no host/port is specified, but a DN is, the DN is used to look up the corresponding host(s) using the DNS SRV records, according to RFC 2782.I'm not sure if this is also available directly in the library or if the client has to implement it.
This feature is implemented in the OpenLDAP client code, not in libldap.
Quoting Howard Chu hyc@symas.com:
Russ Allbery wrote:
I'm not sure if this is also available directly in the library or if the client has to implement it.
This feature is implemented in the OpenLDAP client code, not in libldap.
Okay, so I created these DNS records in my example.com zone file:
_ldap._tcp IN SRV 10 0 389 server1 _ldap._tcp IN SRV 20 0 389 server2
... and I got this to work:
ldapsearch -H ldap:///dc%3Dexample%2Cdc%3Dcom uid=jsmith
(That's "dc=example,dc=com" escaped according to RFC 2396).
However, if /etc/ldap/ldap.conf could be configured like this:
BASE dc=example,dc=com URI ldap:///dc%3Dexample%2Cdc%3Dcom
... and /etc/libnss-ldap.conf and /etc/pam_ldap.conf could support about the same, now that would be more like it! Unfortunately, that doesn't work.
Correct me if I'm wrong, but I get the impression that none of the above will be possible until support for DNS SRV records is added to libldap.
Thanks,
Jaap
On Sunday, 7 March 2010 05:12:13 Jaap Winius wrote:
Quoting Howard Chu hyc@symas.com:
Russ Allbery wrote:
I'm not sure if this is also available directly in the library or if the client has to implement it.
This feature is implemented in the OpenLDAP client code, not in libldap.
Okay, so I created these DNS records in my example.com zone file:
_ldap._tcp IN SRV 10 0 389 server1 _ldap._tcp IN SRV 20 0 389 server2... and I got this to work:
ldapsearch -H ldap:///dc%3Dexample%2Cdc%3Dcom uid=jsmith(That's "dc=example,dc=com" escaped according to RFC 2396).
However, if /etc/ldap/ldap.conf could be configured like this:
BASE dc=example,dc=com URI ldap:///dc%3Dexample%2Cdc%3Dcom... and /etc/libnss-ldap.conf and /etc/pam_ldap.conf could support about the same, now that would be more like it! Unfortunately, that doesn't work.
IIRC nss_ldap by supports DNS discovery, if you omit the URI. However, pam_ldap does not, and IMHO, shouldn't by default (as it would be too easy to trick a client to send a clear-text password - I believe Mac OS X had such a vulnerability ...). I think Red Hat may have a patch on pam_ldap to add the feature there, but I am not sure if it has gone upstream.
See the 'nss_srv_domain' option in 'man nss_ldap'.
What were you wanting to use pam_ldap for, if pam_krb5 should surely be doing authentication? LDAP-based authorization?
Correct me if I'm wrong, but I get the impression that none of the above will be possible until support for DNS SRV records is added to libldap.
Why is this a prerequisite?
Regards, Buchan
Quoting Buchan Milne bgmilne@staff.telkomsa.net:
IIRC nss_ldap by supports DNS discovery, if you omit the URI. ...
Did you mean to say that nss_ldap uses DNS discovery "by default"? Indeed, that is the way it seems to behave; I just ran some more tests, and apparently the nss_srv_domain option is not even necessary.
However, pam_ldap does not, and IMHO, shouldn't by default ...
Indeed, I can also omit the LDAP URI from /etc/pam_ldap.conf and still the users have no problem logging in. Kerberos is doing its job.
Now the only thing left is /etc/ldap/ldap.conf. Unfortunately, if no LDAP URI is included in this configuration file, most of the usual LDAP utilities will not work. If it includes an option like "URI ldap:///dc%3Dexample%2Cdc%3Dcom", not even ldapsearch will understand. What's the problem here... libldap?
Thanks,
Jaap
openldap-technical@openldap.org
-
Buchan Milne -
Howard Chu -
Jaap Winius -
Russ Allbery