[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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%20authentication
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).
--
Dan White