I am reading in the LDAP spec https://tools.ietf.org/html/rfc4511 about naming contexts and I am looking at my RootDSE.
Since my DIT mirrors DNS https://tools.ietf.org/html/rfc2247, there must be some way to route someone to the correct naming context based on the DNS they were using to access the LDAP server, otherwise I just don't understand the spec.
Hi John,
LDAP is a protocol, but implementations like OpenLDAP can distinguish "virtual hosts" based on trailers of the distinguishedName of each query. So, you would setup dc=example,dc=com for one "virtual host" and dc=example,dc=org for another. When you are looking for uid=john,ou=Personnel,dc=example,dc=com you would end up in the first "virtual host's" subtree. In OpenLDAP, it's called a backend database.
-Rick
John Lewis wrote:
I am reading in the LDAP spec https://tools.ietf.org/html/rfc4511 about naming contexts and I am looking at my RootDSE.
Since my DIT mirrors DNS https://tools.ietf.org/html/rfc2247, there must be some way to route someone to the correct naming context based on the DNS they were using to access the LDAP server, otherwise I just don't understand the spec.
https://tools.ietf.org/html/rfc2782
Note:
1. If you're using TLS there's AFAIK no specification how to implement the TLS hostname check (see https://tools.ietf.org/html/rfc6125) to prevent MITM attacks.
2. You still need a-priori configuration how the client should authenticate to the directory.
Ciao, Michael.
Hi,
- If you're using TLS there's AFAIK no specification how to implement the TLS hostname
check (see https://tools.ietf.org/html/rfc6125) to prevent MITM attacks.
IMHO, the hostname check is immaterial (and potentially confusing, when hosting multiple dc=,dc= trees) but DANE can be helpful by checking cert or key, regardless of naming information in the certificate,
https://tools.ietf.org/html/rfc6698
Example records can be generated on
https://www.huque.com/bin/gen_tlsa
Assuming no further server infra I would consider the following settings: * 1 - PKIX-EE: Service Certificate Constraint * 0 - Cert: Use full certificate * 1 - SHA-256: SHA-256 hash * [copy/paste X.509 certificate of the server] * port 389 (ldaps is deprecated AFAIK, and at least ill-advised) * transport tcp * domain name your.corner.of.the.world (for dc=your,dc=corner,dc=of,dc=the,dc=world)
It will generate a TLSA record under DNS name _389._tcp.your.corner.of.the.world.
Take note that DANE relies on DNSSEC for security.
- You still need a-priori configuration how the client should authenticate to the directory.
I would use a client that uses DANE. Not sure if this already exists, but it's something that we will probably be doing in LillyDAP in the coming year.
https://github.com/vanrein/lillydap
I hope this helps, -Rick
One addition,
- domain name your.corner.of.the.world (for
dc=your,dc=corner,dc=of,dc=the,dc=world)
When you server dc=example,dc=com from a server named ldap.example.com then you should ldap.example.com as the domain name, not example.com (as per RFC 6698, Section 3, point 3). Your record will then be "_389._tcp.ldap.example.com. IN TLSA ...".
As indicated, this may not yet be done in client / peer implementations.
-Rick
Rick van Rein wrote:
- If you're using TLS there's AFAIK no specification how to implement the TLS
hostname check (see https://tools.ietf.org/html/rfc6125) to prevent MITM attacks.
IMHO, the hostname check is immaterial (and potentially confusing, when hosting multiple dc=,dc= trees)
Not sure I understand "immaterial". One would have to right a spec which maps the "name" (here LDAP URL) used by the client to something stored in the TLS server cert.
Also note that subjectAltName extension can contain an URI.
but DANE can be helpful by checking cert or key, regardless of naming information in the certificate,
https://tools.ietf.org/html/rfc6698
I expected somebody to raise the DANE hype.
Note that DANE requires DNSSEC to be really secure. Also someone would have to write a spec detailing how to map ldap:///dc=example,dc=com to DANE (DNS) name (just like a spec is needed for TLS hostname check).
Ciao, Michael.
Hi Michael et al,
(John, we're sidetracking from your question, as you can probably tell.)
IMHO, the hostname check is immaterial (and potentially confusing, when hosting multiple dc=,dc= trees)
Not sure I understand "immaterial". One would have to right a spec which maps the "name" (here LDAP URL) used by the client to something stored in the TLS server cert.
I meant to say that the name does not have to be checked against the certificate to establish a secure connection. A direct result can be obtained by simply validating through key material:
0. have a dc=,dc= name 1. form a DNS name out of it [RFC 3088] 2. if possible, map to a server hostname with DNS SRV + DNSSEC 3a. lookup the address for the server with AAAA/A (don't care about DNSSEC) 3b. lookup TLSA record for the server with TLSA + DNSSEC 4. connect to the server and start TLS 5. compare the certificate presented with the TLSA data
* step 2 cannot be insecurely denied * step 3a can be caught out as invalid through TLS * step 3b cannot be insecurely faked * step 4 is not conductive to men in the middle or other fakers * step 5 uses information from validated DNS to validate the LDAP server
From the certificate, we need notBefore / notAfter, plus either the
public key or the entire certificate blob in DER encoding. The path above validates the server without needing to look into specific certificate attributes. This is what I like about DANE -- it can be applied to all uses of TLS. Other things I don't like as much.
I expected somebody to raise the DANE hype.
DANE isn't perfect, agreed. In an automated-keying setting, it can add a lot of value, IMHO. (And since we're working towards one, this has my interest.)
Note that DANE requires DNSSEC to be really secure.
Not sure what you mean by "really", but yes, DNSSEC is the basis of trust on which DANE is built. Although it may be used in-addition-to existing certificate infrastructure, whether this is acceptable is the validating party's choice.
Also someone would have to write a spec detailing how to map ldap:///dc=example,dc=com to DANE (DNS) name
You mean in addition to RFC 3088 in the "duplicated locally" variant? This has an implementation in the slapd-dnssrv backend.
RFC 3088 is experimental, but sufficiently accurate I would say; and according to the RFC Editor,
Experimental RFC + Implementation == Independent Submission.
(just like a spec is needed for TLS hostname check).
That's what I think can be entirely avoided with the aforementioned validation path.
What I'm saying is that AFAIK we have all the tools to formally validate foreign LDAP servers, there is no need for anything to be added.
Cheers,
Rick van Rein OpenFortress
Rick van Rein wrote:
(John, we're sidetracking from your question, as you can probably tell.)
IMHO, the hostname check is immaterial (and potentially confusing, when hosting multiple dc=,dc= trees)
Not sure I understand "immaterial". One would have to right a spec which maps the "name" (here LDAP URL) used by the client to something stored in the TLS server cert.
I meant to say that the name does not have to be checked against the certificate to establish a secure connection. A direct result can be obtained by simply validating through key material:
- have a dc=,dc= name
- form a DNS name out of it [RFC 3088]
- if possible, map to a server hostname with DNS SRV + DNSSEC
3a. lookup the address for the server with AAAA/A (don't care about DNSSEC) 3b. lookup TLSA record for the server with TLSA + DNSSEC 4. connect to the server and start TLS 5. compare the certificate presented with the TLSA data
The majority of deployments do not have DNSSEC in place. So some name check for TLS certs are strictly required for preventing MITM attack.
IMO DNSSEC/DANE is not of much use for LDAP with TLS.
Ciao, Michael.
Hey,
The majority of deployments do not have DNSSEC in place.
Chicken-egg reasoning is killing for advancing the Internet. However, the situation is not as grim as you say:
Servers increasingly run under DNSSEC-supportive domains.
Clients can easily incorporate DNSSEC-aware resolver libraries such as libunbound or libgetdns.
So some name check for TLS certs are strictly required for preventing MITM attack.
That has merits all on its own, agreed. Anyone working on it yet? Until then, I fear DANE is all we've got.
IMO DNSSEC/DANE is not of much use for LDAP with TLS.
We disagree on that, but there is no reason to make an either/or choice between the approaches.
-Rick
On Mon, 17 Apr 2017, Michael Str?der wrote:
John Lewis wrote:
I am reading in the LDAP spec https://tools.ietf.org/html/rfc4511 about naming contexts and I am looking at my RootDSE.
Since my DIT mirrors DNS https://tools.ietf.org/html/rfc2247, there must be some way to route someone to the correct naming context based on the DNS they were using to access the LDAP server, otherwise I just don't understand the spec.
I'm not following that from the original question. It's plausible that a SRV may route someone to the "correct" server relative to a given DNS label. But since the SRV Target MUST be something that resolves to an address, it's quite a leap to find "the correct naming context."
In other words -- and back to the original question here perhaps -- perhaps you know you want LDAP service for example.com, and perhaps a SRV _ldap._tcp.example.com will illuminate you to (say) ldap.example.com.
But upon connecting to ldap.example.com, when the rootDSE presents with n>1 namingContexts, how do you know "the correct naming context?" I'd argue that you basically can't. It would be like a connection to www.example.com imputing that you want www.example.com/product/lightbulb or a connection to sql.example.com somehow magically determining, solely on the basis of the connection characteristics, that you want a query "FROM creditCardNumbers" table. I don't see that being meaningfully possible.
Note:
- If you're using TLS there's AFAIK no specification how to implement the TLS hostname
check (see https://tools.ietf.org/html/rfc6125) to prevent MITM attacks.
- You still need a-priori configuration how the client should authenticate to the directory.
Ciao, Michael.
Aaron Richton wrote:
On Mon, 17 Apr 2017, Michael Str?der wrote:
John Lewis wrote:
I am reading in the LDAP spec https://tools.ietf.org/html/rfc4511 about naming contexts and I am looking at my RootDSE.
Since my DIT mirrors DNS https://tools.ietf.org/html/rfc2247, there must be some way to route someone to the correct naming context based on the DNS they were using to access the LDAP server, otherwise I just don't understand the spec.
I'm not following that from the original question. It's plausible that a SRV may route someone to the "correct" server relative to a given DNS label. But since the SRV Target MUST be something that resolves to an address, it's quite a leap to find "the correct naming context."
In other words -- and back to the original question here perhaps -- perhaps you know you want LDAP service for example.com, and perhaps a SRV _ldap._tcp.example.com will illuminate you to (say) ldap.example.com.
So the question boils down to how you know in advance about the DNS domain "example.com".
But upon connecting to ldap.example.com, when the rootDSE presents with n>1 namingContexts, how do you know "the correct naming context?" I'd argue that you basically can't.
I understand your doubts because RFC 2782 is just the SRV RR spec. RFC 3088 defines a DN to domain mapping:
https://tools.ietf.org/html/rfc3088#section-2.1
And exactly this mapping is used in MS AD, FreeIPA and various other deployments (including the dc-auto-locate feature in my own web2ldap).
Ciao, Michael.
openldap-technical@openldap.org
-
Aaron Richton -
John Lewis -
Michael Ströder -
Rick van Rein