I have slapd listening on port 636 only because I want to enforce use of SSL/TLS
It all works successfully (I now have my UNIX users, mail, and about a dozen apps authenticating against it), however...
I wanted fault tolerance, and I thought that the way to achieve this would be using DNS SRV and replication (which was also easy to get working)
What I've observed:
- if I create _ldaps._tcp.example.org SRV records, they are ignored
- if I create _ldap._tcp.example.org SRV records, and I ldapsearch with a URI of the form "ldaps:///dc%3Dexample%2Cdc%3Dorg" it works
So, it seems to be the combination of the ldaps URI prefix with the _ldap._tcp SRV record that is working, this doesn't seem right
I've also found that other LDAP apps have slightly different expectations too:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661955
I went searching for a definite answer:
+site:ietf.org ldaps srv
http://tools.ietf.org/html/rfc2782 refers to the name of the service from `Assigned Numbers', http://tools.ietf.org/html/rfc1700 which omits ldaps, but it is defined elsewhere as a distinct service name: http://www.ietf.org/assignments/service-names-port-numbers/service-names-por...
Therefore, my feeling is that
- if an ldaps: URI is used, the SRV query should be seeking _ldaps._tcp, and
-if an ldap: URI is used (and StartTLS may or may not be requested by the user), the SRV query should be looking for _ldap._tcp
Also, can anyone comment on why the URI needs to be escaped manually when using DNS SRV?
Daniel Pocock wrote:
I have slapd listening on port 636 only because I want to enforce use of SSL/TLS
It all works successfully (I now have my UNIX users, mail, and about a dozen apps authenticating against it), however...
I wanted fault tolerance, and I thought that the way to achieve this would be using DNS SRV and replication (which was also easy to get working)
What I've observed:
if I create _ldaps._tcp.example.org SRV records, they are ignored
if I create _ldap._tcp.example.org SRV records, and I ldapsearch with
a URI of the form "ldaps:///dc%3Dexample%2Cdc%3Dorg" it works
So, it seems to be the combination of the ldaps URI prefix with the _ldap._tcp SRV record that is working, this doesn't seem right
1. Why do you mandate the use of SSL/TLS when you then completely trust DNS SRV RRs? IMO this does not make sense.
2. You could configure LDAP(S) URIs of all replicas in your client (space-separated list).
Ciao, Michael.
On 03/03/12 10:30, Michael Ströder wrote:
Daniel Pocock wrote:
I have slapd listening on port 636 only because I want to enforce use of SSL/TLS
It all works successfully (I now have my UNIX users, mail, and about a dozen apps authenticating against it), however...
I wanted fault tolerance, and I thought that the way to achieve this would be using DNS SRV and replication (which was also easy to get working)
What I've observed:
if I create _ldaps._tcp.example.org SRV records, they are ignored
if I create _ldap._tcp.example.org SRV records, and I ldapsearch with
a URI of the form "ldaps:///dc%3Dexample%2Cdc%3Dorg" it works
So, it seems to be the combination of the ldaps URI prefix with the _ldap._tcp SRV record that is working, this doesn't seem right
- Why do you mandate the use of SSL/TLS when you then completely trust
DNS SRV RRs? IMO this does not make sense.
I think that is a separate question, I've started a new thread on it
- You could configure LDAP(S) URIs of all replicas in your client
(space-separated list).
I'm aiming to avoid that and just have the clients discover as much as possible using DNS SRV. I already do such things with SIP, for example.
Daniel Pocock wrote:
On 03/03/12 10:30, Michael Ströder wrote:
Daniel Pocock wrote:
I have slapd listening on port 636 only because I want to enforce use of SSL/TLS
It all works successfully (I now have my UNIX users, mail, and about a dozen apps authenticating against it), however...
I wanted fault tolerance, and I thought that the way to achieve this would be using DNS SRV and replication (which was also easy to get working)
What I've observed:
if I create _ldaps._tcp.example.org SRV records, they are ignored
if I create _ldap._tcp.example.org SRV records, and I ldapsearch with
a URI of the form "ldaps:///dc%3Dexample%2Cdc%3Dorg" it works
So, it seems to be the combination of the ldaps URI prefix with the _ldap._tcp SRV record that is working, this doesn't seem right
- Why do you mandate the use of SSL/TLS when you then completely trust
DNS SRV RRs? IMO this does not make sense.
I think that is a separate question, I've started a new thread on it
IMO it's not a separate topic. Anyway I already responded.
- You could configure LDAP(S) URIs of all replicas in your client
(space-separated list).
I'm aiming to avoid that and just have the clients discover as much as possible using DNS SRV.
If you don't want to configure an a priori known hostname or DNSSEC then you're risking possibility of MITM attacks because the hostname check needed with SSL/TLS cannot be performed at all.
Ciao, Michael.
openldap-technical@openldap.org
-
Daniel Pocock -
Michael Ströder