[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Pass-through authentication to Active Directory when using saslbind
On 22 October 2013 02:05, Dan White <dwhite@olp.net> wrote:
>
> 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
I have decided to forego with PTA + saslbind and simply do PTA +
simplebind, which works OK so long as I have an administrative LDAP
account on both AD1 and AD2 that can do the initial bind and perform
an LDAP searchRequest to find the LDAP entry for the user being
authenticated.
So:
testsaslauthd --> saslauthd --> OpenLDAP --> simplebind --> AD1 / AD2
Amazing what OpenLDAP does ( Well, amazing to me ) ! Using the
userPrincipalName as the ldap_filter in saslauthd.conf, it binds to
both AD1 and AD2, does a searchRequest on both AD1 and AD2, and
whichever AD responds with a searchResEntry ( e.g. whichever AD found
the LDAP entry of the user to be authenticated ), it then binds to
that AD using the DN from the searchResEntry and the password supplied
on the command line. Of course, all of this with the correct
suffixmassage to make it all work.
Apart from the two uris in slapd.conf for the meta backend / database,
all I need is the rootdn and rootpw for testsaslauthd to bind to
OpenLDAP. Thus, I now have OpenLDAP proxy to both AD1 /AD2.
All I need next is ldaps.