Re: LDAP authentication: non-anonymous bind
Lars Kruse wrote: Hi, the attached patch adds a second option for non-anonymous binds to the authnz_ldap module. Please consider it for adoption. I've applied it to 2.2.14 today and tested on windows (AD). It can't bind if the exact ldap folder is unknown. Let's say we have users not in OU=Users, but in OU=Developers and OU=QA. In order for developer to authenticate http would have to bind to AD with search base OU=Developers,dc=company,dc=com. But in order for QA person, searach base should be different: QA=Developers,dc=company,dc=com. Let's say we do search by sAMAccountName. Then with current approach the search base generate: sAMAccountName=user name,dc=company,dc=com. Such search base does not exist. In order to search in subfolders, search base should be static, meaning set in config file. And user name (variable part) should go into filter. Then it will be possible to search in dc=company,dc=com including subfolders by filter ((objectClass=user)(sAMAccountName=user name) I managed to make it working (dirty hack): I bind with username as is (must be user name@organization.com), and attribute in AuthLdapUrl should be set to userPrincipalName. So I changed the code: - sec-binddn = apr_psprintf(r-pool, %s=%s,%s, sec-attribute, user, sec-basedn); + sec-binddn = apr_psprintf(r-pool, %s, user); The current situation: The authnz_ldap module supports only one kind of non-anonymous bind to the ldap server: by specifying the username (binddn) and password (bindpw) in an apache config file. This is obviously not a very pretty thing, since you need to take good care for file permissions (as an admin) and also users may feel a little bit uncomfortable to put their plaintext login data into an htaccess file. Now, if we are at it, can we discuss encryption? Authnz_ldap will request AD in plain text. Not good. Without AuthLDAPAuthOnBind only single pseudo-user account was compromised with in ON, everybody's account will travel across the network in plain text, even if you connect to https via ssl! I played a little bit with Apache Directory Studio, and I could connect to AD only in 2 cases. No encryption; Simple Authentication (plain text) No encryption; Digest-md5 (SASL) Any chance we can leverage digest-md5 authentication method? Othervise I would allow only ssl-emabled connection to AD. May be with some option enable plain text if you know what you are doing. Vadim.
Re: LDAP authentication: non-anonymous bind
On 26 Jan 2010, at 4:44 AM, Eric Covener wrote: This new behaviour covers the two use cases described above (even though I did not check it in an Active Directory setup). Patch is nice and simple, but it would be great if someone with AD leanings could confirm that this combination of HTTP username, attribute, and basedn is likely to result in something that can bind in a typical AD install. There are three possible scenarios for login: - User provides username, auth_ldap server does a search within the directory to find the DN corresponding to the username, and then attempts to bind as that DN. If it succeeds, you're in. This usually requires a DN of some kind to use to do the initial login to do the original search. (AD works fine in this scenario, on condition you have an account to bind and do the initial search with). - User provides username, auth_ldap applies the username to an admin- provided recipe of some kind to create the DN. This recipe needs to be flexible enough to support various scenarios, such as the base URL for the recipe being something other than the base URL for searches (think group searches, a group might not have the same base DN as the person). - User provides username, auth_ldap tries to bind directly with that username without first converting it to a DN. This is how AD would work. Ideally auth_ldap should support the above three methods, am I correct in understanding that the patch implements the second option above? (I don't have time to review it fully at the moment). Regards, Graham --
Re: LDAP authentication: non-anonymous bind
In addition, the modifications to the binddn are in the 'sec' variable which is an authn_ldap_config_t structure created for the module and not for the _request_. good catch, this is also a defect on one of the handful of patches in bugzilla! -- Eric Covener cove...@gmail.com
Re: LDAP authentication: non-anonymous bind
On Mon, Jan 25, 2010 at 8:44 PM, Eric Covener cove...@gmail.com wrote: On Mon, Jan 25, 2010 at 7:00 AM, Lars Kruse de...@sumpfralle.de wrote: This new behaviour covers the two use cases described above (even though I did not check it in an Active Directory setup). Patch is nice and simple, but it would be great if someone with AD leanings could confirm that this combination of HTTP username, attribute, and basedn is likely to result in something that can bind in a typical AD install. I've been working with LDAP and AD for a while now, and, AFAIK, there are only two ways to bind to a Directory Server: 1. User's BindDN, and 2. User Principle Name I don't believe the proposed method is portable to AD. In addition, the modifications to the binddn are in the 'sec' variable which is an authn_ldap_config_t structure created for the module and not for the _request_. Regards, Ryan
