Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 53927 invoked from network); 29 Jan 2010 06:13:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Jan 2010 06:13:14 -0000 Received: (qmail 84480 invoked by uid 500); 29 Jan 2010 06:13:13 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 84381 invoked by uid 500); 29 Jan 2010 06:13:11 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 84371 invoked by uid 99); 29 Jan 2010 06:13:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Jan 2010 06:13:10 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [68.230.241.41] (HELO fed1rmmtao105.cox.net) (68.230.241.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Jan 2010 06:13:00 +0000 Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao105.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20100129061239.CKWL12229.fed1rmmtao105.cox.net@fed1rmimpo01.cox.net> for ; Fri, 29 Jan 2010 01:12:39 -0500 Received: from [192.168.0.11] ([70.181.128.238]) by fed1rmimpo01.cox.net with bizsmtp id bJCe1d00558l3T203JCe8g; Fri, 29 Jan 2010 01:12:38 -0500 X-VR-Score: -140.00 X-Authority-Analysis: v=1.1 cv=4cmh2gL1a6RJOvq2diO5/mV5P7W7DelkioqUudxRLMU= c=1 sm=1 a=lIx3A_Fa0hsA:10 a=Vyin0MIk3uKX618xqVONYA==:17 a=7SeWhesKAAAA:8 a=oG9fAOG2H4YoF_56cbUA:9 a=7hhnq_YTEtiJz0onx-fhB-b1-6MA:4 a=wwJ5rpPffZkA:10 a=Vyin0MIk3uKX618xqVONYA==:117 X-CM-Score: 0.00 Message-ID: <4B627C56.9020105@cox.net> Date: Thu, 28 Jan 2010 22:12:38 -0800 From: Vadim Chekan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: LDAP authentication: non-anonymous bind References: <20100125130009.5fdbf39c@erker> In-Reply-To: <20100125130009.5fdbf39c@erker> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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=,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=)" I managed to make it working (dirty hack): I bind with username as is (must be @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.