Re: Pass-through authentication to Active Directory when using saslbind

On 10/19/13 20:46 +1100, Jesus Jr M Salvo wrote:

1. There are 2 Active Directory servers that I need to connect to. Both of

these are NOT under my control. We shall call them AD1 and AD2 here.

2. I can connect to AD1 via testsaslauthd using both simple bind and

saslbind using DIGEST-MD5.

2b) For saslbind using DIGEST-MD5, I have no need for the administrative read-only account, as shown below by my /etc/saslauthd.conf: ( saslauthd was restarted in each case when saslauthd.conf was changed )

################################################################### #/etc/saslauthd.conf ldap_servers: ldap://172.21.128.49:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #########################################################################

$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."

All good so far with simple bind and saslauthd to AD1.

3. I can only connect to AD2, the second active directory server, via

testsaslauthd using only sasl bind.

That is because I do not know of an adminstrative read-only account in AD2 that I can use to perform the initial LDAP bindRequest in order to allow an LDAP searchRequest. Here is the /etc/saslauthd.conf for saslbind to AD2:

################################################################### #/etc/saslauthd.conf # Your AD server adress # NOTE: This will only work IFF there is also a reverse DNS entry for this A record # Otherwise, the digest-uri in the LDAP SASL bind request will only contain the IP address instead of the hostname # which will result in "The digest-uri does not match any LDAP SPN's registered for this server" ldap_servers: ldap://ad2idcdc11.au.ad2.corp:3268 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_start_tls: no ldap_version: 3 ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################

$ testsaslauthd -u anotheruser -p otherpassword 0: OK "Success."

4. I am using SASL because I currently have Subversion 1.8 configured to

use SASL to authenticate users to AD1, but currently using simple bind. I will be changing this later on so that saslauthd will use sasl bind to AD1.

$ cat /etc/sasl2/svn.conf pwcheck_method: saslauthd mech_list: PLAIN

---

Now here is what I am trying to achieve with OpenLDAP:

I am using slapd.conf. I am also using the meta backend, as my instance of OpenLDAP will not really have its own LDAP database as I intended to use OpenLDAP for pass-through authentication.

pass-through authentication will require you to have a specially formated userPassword entry, which you're not going to get from Active Directory. See:

http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authenticat...

You'll need a local database which contains those entries.

If you don't really need pass-through authentication (if you don't need to perform simple binds), then that would simplify things for you.

5. I am able to use OpenLDAP as a proxy to AD1 for pass-through

authentication via the meta backend, but only if OpenLDAP is configured to use simplebind to AD1. That is: testsaslauthd ( simple bind ) -> OpenLDAP ( simple bind ) -> AD1.

Why not have saslauthd communicate directly with AD1, instead of OpenLDAP?

Here is my /etc/ldap/slapd.conf:

######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 #########################################################################

.. and here is my /etc/saslauthd.conf for this specific test: ( The only difference between this and [2a] is the ldap_servers entry, which now points to OpenLDAP, and the ldap_filter, which now has an OR condition )

################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv ldap_bind_pw: readonly ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind ldap_filter: (|(uid=%U)(sAMAccountName=%U)) ldap_password_attr: userPassword ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################

$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."

You can see from the above that:

• The initial administrative simple bind to OpenLDAP was delegated by

OpenLDAP to AD1.

• The searchRequest to OpenLDAp was delegated by OpenLDAP to AD1.
• The second bindRequest ( that is authenticating the user that I specified

with testsaslauthd ) to OpenLDAP was delegated by OpenLDAP to AD1.

That is, on all 3 cases above, OpenLDAP only returned success back to testsaslauthd only if AD1 only returned success. So far so good.

6. I am unable to use ... or rather confused on how to use .. OpenLDAP as a

proxy to AD1 so that OpenLDAP will use sasl bind to AD1.

Use PLAIN sasl binds, and direct saslauthd to connect directly to AD1. Or use GSSAPI.

This is where I am stuck. Here is my /etc/saslauthd.conf for this test: The only difference between this and saslauthd.conf in [2b] is the ldap_servers entry, which is now pointing to OpenLDAP.

################################################################### #/etc/saslauthd.conf # # Your AD server adress ldap_servers: ldap://127.0.0.1:389 ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: yes ldap_mech: DIGEST-MD5 ldap_start_tls: no ldap_version: 3 ldap_timeout: 10 ldap_cache_ttl: 30 ldap_cache_mem: 32768 #EOF #########################################################################

I'm dizzy. It appears you want pass-through authentication to speak with saslauthd, which in turn connects back to your slapd instance using DIGEST-MD5, which then proxies to AD. DIGEST-MD5 is going to fail because it's a shared secret mechanism, and slapd does not have access to the password.

See:

http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/components.php

Here is my /etc/ldap/slapd.conf for this test: ( The only difference between this file and the slapd.conf file in [5] is the addition of the idassert-bind line )

######################################################################### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats modulepath /usr/lib/ldap moduleload back_meta.so moduleload back_ldap.so sizelimit 500 tool-threads 1 backend meta database meta access to * by * read suffix "dc=ad1,dc=priv" uri ldap://172.21.128.49:3268/dc=ad1,dc=priv chase-referrals no lastmod off protocol-version 3 idassert-bind bindmethod=sasl saslmech=DIGEST-MD5 mode=none #########################################################################

$ testsaslauthd -u salvojo -p mypassword 0: NO "authentication failed"

As you can see from the above tshark, OpenLDAP did not even try to communicate at all to AD1 ! What should I have in slapd.conf ? Maybe the problem is that, I am using testsaslauthd, which uses saslauthd to connect to OpenLDAP, but also need OpenLDAP to use saslauthd to AD1 ( e.g. It is using the same saslauthd daemon ) ?

I also read about at ( Section 14.5 ):

http://www.openldap.org/doc/admin24/security.html ... about setting the userPassword attribute to something of the form:

userPassword: {SASL}user@realm ... but:

*) I am using a meta backend, and thus I have no internal users, so I cannot set the userPassword attribute .... or is this saying that I need a "copy" of the DN name of the users from AD1 to my local OpenLDAP ?

Yes, if you require pass-through authentication.

It also says:

"Since OpenLDAP 2.0 slapd has had the ability to delegate password verification to a separate **PROCESS** ( emphasis mine ). This uses the sasl_checkpass(3) function so it can use any back-end server that Cyrus SASL supports for checking passwords."

This is referring to your configured pwcheck_method.

.. but:

*) How was OpenLDAP able to delegate password verification in the simple-bind proxy as I have demonstrated above WITHOUT going through a separate proccess but going straight through a TCP/IP connection ?

If you mean this one:

ldap_servers: ldap://127.0.0.1:389 ldap_default_domain: ad1.priv ldap_search_base: DC=ad1,DC=priv ldap_bind_dn: CN=administrativero,OU=Service_Accounts,DC=ad1,DC=priv

$ testsaslauthd -u salvojo -p mypassword 0: OK "Success."

You are not actually performing a SASL authentication here. You are using the sasl_checkpass(3) call indirectly by calling testsaslauthd. saslauthd is performing a simple bind against AD.

The separate process in this case is saslauthd (prior to speaking with slapd). Think of pass-through authentication and testsaslauthd as performing similar functions in this visual picture (in that they call sasl_checkpass(3)).

*) Is the statement saying that OpenLDAP will use saslauthd to connect to a remote LDAP/AD ? If so, since I am using testsaslauthd and I am already using saslauthd to connect to OpenLDAP, and saslauthd.conf is configured to point to the local OpenLDAP, does this mean I need another instance of saslauthd with its own unix socket and its own saslauthd.conf ? If so, what's the point of having the uri in slapd.conf when the separate instance of saslauthd.conf will have its own entry of the remote ldap / AD1 anyway ?

Anyway, as you can see .. I am confused on how to do item [6] above. All I really need to happen is ( from a tcp capture / wireshark perspective ), something like ( similar to the simple bind PTA ):

7. If I can find out how to do item [6] above with help from this list,

then I will try to do the same for AD2.

8. The end goal therefore is to use OpenLDAP as a dumb proxy that will

authenticate users to either AD1 or AD2.

Using the krb5 backend to saslauthd may be more productive. It will require you to use PLAIN SASL authentication, as DIGEST-MD5 won't work. Or as mentioned above, you can perform GSSAPI SASL authentication and disregard saslauthd/pass-through authentication altogether.

Also take a look at slapo-pbind (5).