LDAP external authentication module

[Kris Saxton]

Hi all,

I've written an LDAP module for the new external authentication goodness coming in 0.10.4.

https://github.com/KrisSaxton/salt-ldap (auth/ldap.py)

I've blogged about how it works here:

http://www.automationlogic.com/archives/427

It uses the same approach that I've seen with most LDAP authentication stuff where an initial search for user dn is performed and then an attempt to bind to the LDAP directory as that dn and with the user-supplied password is attempted.

Thanks to Thomas for help debugging some weirdness around token creation.

This *should* work with Active Directory but I've only tested it against openLDAP. If anyone fancies trying it out against AD, I'd love to hear from you.

I deliberately avoided using the existing LDAP salt module as I didn't want anyone to be able to circumvent the module by dropping in a custom ldap salt module (e.g. in _modules or some modules directory specified in the master config) - basic tests showed that this was quite easy to do.

I've never done anything security related, so I'd appreciate a more experienced eye looking this over for holes.

Assuming it's OK, do you want this is salt-contrib or salt proper?

I'll probably do an LDAP master_tops next and this will signal the end of my LDAP fetish : )

Best,

Kris

--
Kris Saxton
e: kr...@automationlogic.com
t: @KrisSaxton

[David Boucha]

This is fantastic, Kris!  Can't wait to check it out.

Dave

[Adam Glenn]

Thanks for this! I don't plan on using it right now but my manager and I have already discussed future plans that may make use of this.

[Thomas S Hatch]

This looks great! Lets get it in Salt proper!

[Kris Saxton]

Great! Pull request here:

https://github.com/saltstack/salt/pull/2322

[Thomas S Hatch]

Accepted! I am very excited about this!

I am also excited to see it come in for 0.10.4!

[Pierre R]

Hi,

I don't understand the "return False" on line 116:

https://github.com/saltstack/salt/blob/develop/salt/auth/ldap.py#L116

My LDAP (AD) actually returns multiple entries but it does not mean the user does not exist ...

Can we patch this (just remove the line ; so I don't think it worth sending a patch) ?

Thanks

Cheers

[Kris Saxton]

Hi Pierre,

I wrote this to work with our OpenLDAP directory, so it's great to see someone using it against AD : )

In our environment multiple result entries means your search wasn't sufficiently precise, but I guess your case is different?

If your search returns multiple results, how do you pick which dn to use?

If we remove the "return False" line then the first entry in the result set will be used, is this the desired behaviour for you?

Best,

Kris

--
Kris Saxton
e: kr...@automationlogic.com

m: +447932834856
t: @KrisSaxton

> --
> You received this message because you are subscribed to the Google Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Pierre R]

Hi Kris,

Thanks so much for the quick reply.

It made me think a bit further and I have realized the extra entries were from another "OU".  I actually add the "OU" as an extra param in the basedn to fix it.

So far everything works nicely (no change required on my side !)

To my defense, I guess I have been deceived somehow by the warning/no auth behavior.

Thanks again,

Cheers,

- Pierre

[Kris Saxton]

That's great to hear, so we now have AD auth support : ) I understand what you mean about being deceived; it's hard to give good error messages during authentication as you often end up leaking information that could help someone trying to break in.

Let me know if you need any more help.

Best,

Kris

[David Boucha]

Pierre,

I'm really glad to hear the LDAP eauth works with ActiveDirectory.  Did you have to make any changes or anything? I'm curious to hear about your experience.

--

Dave Boucha  |  Sr. Engineer

5272 South College Drive, Suite 301 | Murray, UT 84123
office 801-305-3563
da...@saltstack.com | www.saltstack.com

[Robert Murley]

Kris or David,

I'm trying to setup External Authentication for LDAP with Active Directory and am using the following configuration below in the master config file

external_auth:
   ldap:

      user1:

         - .*

I need some guidance on setting the following LDAP module settings below

auth.ldap.basedn: 'DC=na,DC=company,DC=com'

auth.ldap.binddn: 'CN=BindUser,OU=IT,OU=Org,DC=na,DC=company,DC=com'  

auth.ldap.bindpw: 'BindPassword' 

auth.ldap.filter: user='(&(sAMAccountName=%v)(objectcategory=user))'  

auth.ldap.server: 'ldapbind.domain.com'  

My base DN is like this => DC=na,DC=company,DC=com
My bind DN is like this => CN=BindUser,OU=IT,OU=Org,DC=na,DC=company,DC=com

My user filter is like this => (&(sAMAccountName=%v)(objectcategory=user))

My LDAP server is like this => ldapbind.domain.com (I can't use localhost for this) 
My port is default standard of 389

No TLS is needed
Not sure about scope

I assume these auth.ldap.* settings that are needed reside in the master config file, but I have also read where they are also needed in the minion config file on the LDAP server.  In my situation there will not be any minion running on my Active Directory LDAP servers and will only need to authenticate with LDAP from my Salt master.  Please let me know if this is possible and how I can go about doing this if it is possible.  I have tried using my settings listed above and don't really get an useful debug information on the Salt master shown below

[INFO    ] Clear payload received with command mk_token
[WARNING ] Authentication failure of type "eauth" occurred.
[INFO    ] Clear payload received with command publish
[WARNING ] Authentication failure of type "eauth" occurred.

for something as simple as this command shown below

(saltstack-wsadmin)wsadmin@aixdev71:/apps/Tools/saltstack-wsadmin
$ salt -c ./etc/salt -T -a ldap 'aixdev71' test.echo blah
username: user1 
password:
Failed to authenticate, is this user permitted to execute commands?
(saltstack-wsadmin)wsadmin@aixdev71:/apps/Tools/saltstack-wsadmin
$

but without using LDAP for authentication the same command works without any problems shown below

(saltstack-wsadmin)wsadmin@aixdev71:/apps/Tools/saltstack-wsadmin
$ salt -c ./etc/salt -T 'aixdev71' test.echo blah
aixdev71:
    blah
(saltstack-wsadmin)wsadmin@aixdev71:/apps/Tools/saltstack-wsadmin 
$ 

Is there some some setting for additional logging to validate the bind is successful before actually validating the user does exist in LDAP that will be using a Salt command?  Please advise and let me know how I can get additional information for debugging purposes to make this work if possible.

Best Regards,

Robert Murley

[Kris Saxton]

Hi Robert,

Apologies for the slow reply (been on holiday).

Are you still having trouble with this?  To clarify: The LDAP auth module doesn't use the 'ldapmod' execution module (by design).  All the communication is done from the master, so as long as your master can connect to the AD server it doesn't matter that the AD server doesn't have a minion installed.

If you check out my blog entry on this, you should see that you need to have the special keyword '{{ username }}' somewhere in your 'auth.ldap.filter' config option, rather than the '%v' you seem to be using.  Other than that, your config looks good.

Best,

Kris