SASL EXTERNAL TLS question

[Milind Khandekar]

Requirement:

Use OpenLDAP with TLS, with server supplying digital certificate and "demand"ing client certificate. Based on client certificate, bind the client application to an entry.

My progress thus far:

The two way certificate exchange and client authentication works.

Problem:

I can't bind the client to an existing entry.

I understand that I need to use SASL external. I just can't figure out how I use it. I looked around everywhere on OpenLDAP, and I am quite sure that there is a small HOWTO somewhere that will describe exactly what needs to be done. Can any kind soul point me to it?

I am using Connexitor Directory Services (CDS) from www.symas.com so the versions are:
OpenLDAP v2.1.x
OpenSSL v0.9.x
Cyrus SASL 2.x
Heimdal Kerberos v0.4e

Thanks for absolutely ANY help,
-Milind.

[Kent Soper]

Post by Milind Khandekar
I understand that I need to use SASL external. I just can't figure out

how I use it. I looked around

Post by Milind Khandekar
everywhere on OpenLDAP, and I am quite sure that there is a small HOWTO

somewhere that will

Post by Milind Khandekar
describe exactly what needs to be done. Can any kind soul point me to

it?

SASL External HOWTO? Now that's a good one. Not covered in the admin
guide and I couldn't find much info on it. Luckily I found a few bits here
and there and stumbled into success with it.

Command line SASL, EXTERNAL mech setup:
1. Configure client and server certs (I guess you already have).
slapd.conf will contain TLS certificate directives as well as
'TLSVerifyClient demand'.
ldap.conf will contain 'TLS_Req_Cert demand' (default actually).
.ldaprc or ldaprc will contain client side certificate info.

2. Check TLS/SSL connection by calling ldapsearch using simple bind
(either ldaps:// or ldap:// '-ZZ'
check LDAP server output/logs for TLS handshake.

3. Run another client command to verify available SASL mechanisms
ldapsearch -x -s base '(objectclass=*)' -H ldap://<server> -ZZ
supportedSASLMechanisms
(that's what I used)

4. If everything is configured for client auth and TLS/SSL is used, then
EXTERNAL will be listed.
You can't install a piece of software to get it, client auth needs to
be config'd and TLS used.

5. Now you can run clients like this "ldapsearch -Y external -b
dc=myserver,cd=com '(cn=*)' "
It works if the client cert is accepted.
I get asked for a password. Hit return.
You can also use '-I' if you want.

6. Use ACLs to control access to directory.

I tried to get the SASL sample server working first (because that's always
the first step for anything SASL!), but I couldn't.

If you need to use SASL's EXTERNAL mechanism from within an application,
use ldap_sasl_interactive_bind_s() and callback code similar to
<openldap>/libraries/liblutil/sasl.c. That's a whole 'nother set of emails
...

Cheers,
Kent Soper

"You don't stop playing because you grow old ...
you grow old because you stop playing."

Linux Technology Center, Linux Security
phone: [phone]
e-mail: ***@us.ibm.com

[Dieter Kluenter]

Hello,

Post by Milind Khandekar
Use OpenLDAP with TLS, with server supplying digital certificate and
"demand"ing client certificate. Based on client certificate, bind the
client application to an entry.
The two way certificate exchange and client authentication works.
I can't bind the client to an existing entry.
I understand that I need to use SASL external. I just can't figure
out how I use it. I looked around everywhere on OpenLDAP, and I am
quite sure that there is a small HOWTO somewhere that will describe
exactly what needs to be done. Can any kind soul point me to it?

You have to create X.509 certificates for all your users. For this to
work properly, you might need to change openssl.conf to fit into your
directory scheme, that is probabely additional ou's c', o's.

To make use of sasl external mechanism you have to start tls, i.e.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
***@marin:~> ldapwhoami -Y EXTERNAL -ZZ
SASL/EXTERNAL authentication started
SASL username: CN=Dieter Kluenter,OU=partner,O=avci,C=de
SASL SSF: 0
dn:cn=dieter kluenter,ou=partner,o=avci,c=de
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.

SASL username is read from the certificate and than parsed against an
entry, so make sure that the distinguished names are equal.

-Dieter

[Kent Soper]

Post by Dieter Kluenter
Hello,

Post by Milind Khandekar
Use OpenLDAP with TLS, with server supplying digital certificate and
"demand"ing client certificate. Based on client certificate, bind the
client application to an entry.
The two way certificate exchange and client authentication works.
I can't bind the client to an existing entry.
I understand that I need to use SASL external. I just can't figure
out how I use it. I looked around everywhere on OpenLDAP, and I am
quite sure that there is a small HOWTO somewhere that will describe
exactly what needs to be done. Can any kind soul point me to it?

You have to create X.509 certificates for all your users. For this to
work properly, you might need to change openssl.conf to fit into your
directory scheme, that is probabely additional ou's c', o's.
To make use of sasl external mechanism you have to start tls, i.e.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
SASL/EXTERNAL authentication started
SASL username: CN=Dieter Kluenter,OU=partner,O=avci,C=de
SASL SSF: 0
dn:cn=dieter kluenter,ou=partner,o=avci,c=de
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
SASL username is read from the certificate and than parsed against an
entry, so make sure that the distinguished names are equal.
-Dieter

I probably have a simple setup for my slapd, but the DN of the certificate
does not have to parsed to match an entry in my directory. If the client
cert can be verified by the server, client is authenticated. If a bad
client cert is used, client is not authenticated. I didn't even have a
sasl-regexp in my slapd.conf to get it to work. However, Kurt Zeilenga did
suggest to me that I would need to do some mapping of the dn's.

Cheers,
Kent Soper

"You don't stop playing because you grow old ...
you grow old because you stop playing."

Linux Technology Center, Linux Security
phone: [phone]
e-mail: ***@us.ibm.com

[Howard Chu]

-----Original Message-----

Post by Dieter Kluenter
Hello,

Post by Milind Khandekar
Use OpenLDAP with TLS, with server supplying digital

certificate and

Post by Dieter Kluenter

Post by Milind Khandekar
"demand"ing client certificate. Based on client

certificate, bind the

Post by Dieter Kluenter

Post by Milind Khandekar
client application to an entry.
The two way certificate exchange and client authentication works.
I can't bind the client to an existing entry.
I understand that I need to use SASL external. I just can't figure
out how I use it. I looked around everywhere on OpenLDAP, and I am
quite sure that there is a small HOWTO somewhere that will describe
exactly what needs to be done. Can any kind soul point me to it?

You have to create X.509 certificates for all your users.

For this to

Post by Dieter Kluenter
work properly, you might need to change openssl.conf to fit

into your

Post by Dieter Kluenter
directory scheme, that is probabely additional ou's c', o's.
To make use of sasl external mechanism you have to start tls, i.e.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
SASL/EXTERNAL authentication started
SASL username: CN=Dieter Kluenter,OU=partner,O=avci,C=de
SASL SSF: 0
dn:cn=dieter kluenter,ou=partner,o=avci,c=de
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
SASL username is read from the certificate and than parsed

against an

Post by Dieter Kluenter
entry, so make sure that the distinguished names are equal.
-Dieter

I probably have a simple setup for my slapd, but the DN of
the certificate
does not have to parsed to match an entry in my directory.
If the client
cert can be verified by the server, client is authenticated. If a bad
client cert is used, client is not authenticated.

Correct. SASL authentication merely determines whether the server will
believe the user's assertion of the user's identity. Whether or not the
identity exists in LDAP is not a consideration. That's the whole point of
SASL, it's an external authentication system which uses out-of-band means to
validate an identity.

I didn't even have a sasl-regexp in my slapd.conf to get it to work.
However, Kurt Zeilenga did suggest to me that I would need to do some
mapping of the dn's.

Mappin the DNs is merely a convenience. It's of greatest value when you
support multiple different means of authenticating, and you want to
coordinate them all with an existing user entry in the directory. This is
desirable for some purposes like e.g. pam_ldap, which must look up attributes
of a user after authenticating the user. In this case, you really want the
authentication ID to equate to the DN of an entry in the directory so you can
find the attributes of interest. But if all you needed was a boolean result
is/is-not authenticated, then mapping would be irrelevant.

-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support

[Dieter Kluenter]

Hi,

Post by Kent Soper

Post by Dieter Kluenter
Hello,

[...]

Post by Kent Soper

Post by Dieter Kluenter
SASL username is read from the certificate and than parsed against an
entry, so make sure that the distinguished names are equal.
-Dieter

I probably have a simple setup for my slapd, but the DN of the certificate
does not have to parsed to match an entry in my directory. If the client
cert can be verified by the server, client is authenticated. If a bad
client cert is used, client is not authenticated. I didn't even have a
sasl-regexp in my slapd.conf to get it to work. However, Kurt Zeilenga did
suggest to me that I would need to do some mapping of the dn's.

That is in principle correct, you don't need a certificate DN that
matches an entry, but if you have acl's that require a specific DN
like
access to dn.subtree=cn=Monitor
by dn.exact="cn=dieter kluenter,ou=partner,o=avci,c=de" write

sasl has to parse sasl username to DN.

-Dieter

[Milind Khandekar]

Hmm, so let me restate my requirement:
Requirement:

Use OpenLDAP with TLS, with server supplying digital certificate and "demand"ing client certificate. Based on client certificate, bind the client application to an entry.

Like Howard and Kent say, my LDAP client application does get authenticated to the server. And I don't need to involve SASL at all. However, I have the following default access control mechanism:

access to *
by self write
by users read
by anonymous auth

The way I read the above policy is that if I created an entry, I can write to it, others can only read. So, if one client application created, say, three entries of a particular objectClass, only that application can modify it.

Doesn't the client application need to bind itself to the server in order to do just that? Or are you guys saying that just authenticating itself to the server is sufficient enough to fulfill the above access control policy? I am using JNDI to access LDAP. May be JNDI requires me to bind when LDAP doesn't really.

Consider that I have a new objectClass defined, called A, that has a name attribute. If one client app adds three As and another four, I want both of them to have read access to all seven, but first one with write access to first three and the second one with write access to last four.

Both the client apps have a dig cert each that server can verify. Is that good enough to fulfill the access control policy?

Boy, do I have this concept completely wrong?

Thanks,
-Milind

[Howard Chu]

-----Original Message-----
Use OpenLDAP with TLS, with server supplying digital
certificate and "demand"ing client certificate. Based on
client certificate, bind the client application to an entry.
Like Howard and Kent say, my LDAP client application does get
authenticated to the server. And I don't need to involve
SASL at all.

Not true; the SASL library is still involved even though it does (next to)
nothing in this case. You must perform a SASL Bind with the EXTERNAL
mechanism in order to authenticate using the certificates.

However, I have the following default access
access to *
by self write
by users read
by anonymous auth
The way I read the above policy is that if I created an
entry, I can write to it, others can only read. So, if one
client application created, say, three entries of a
particular objectClass, only that application can modify it.

No. "self" means the one entry whose DN matches your authentication DN. It
does *not* mean "all entries I created." It also means, if you want to use
TLS certificates for authentication and to control access to some directory
entries, then the DN in the certificate must correspond to the DN of a
directory entry. Or you must use saslRegexp to map from the certificate DN to
the directory entry DN.

-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support