httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McQueen <mcquee...@edsrd1.yzk.co.jp>
Subject [users@httpd] Re: Multiple authentication sources
Date Tue, 20 Jan 2009 00:12:46 GMT
I tried AuthLDAPRemoteUserIsDN. I can login by just entering a username. 
It set REMOTE_USER to the full distinguished name, LDAP style:
CN=Craig McQueen,OU=Users,OU=MyDepartment,OU=All,DC=mycompany,DC=com,DC=au

That does enable the back-end to distinguish which domain the 
authentication is on. But the length of the string seems quite unwieldy, 
especially for putting entries in the Subversion authorization file (no 
opportunity to parse and simplify, as one would with a programmatic 
back-end). Possible, but unwieldy.

However, I also tried using the option:
AuthLDAPRemoteUserAttribute userPrincipalName
which, if using Windows Active Directory, fills REMOTE_USER with e.g.:
cmcqueen@mycompany.com.au

That seems a lot more manageable. Not quite as "nice" as 
MYDOMAIN\cmcqueen, especially since that's what we currently get with 
SSPI authentication we're currently  using -- but not too bad.

Regards,
Craig McQueen


Craig McQueen wrote:
> Thanks for your reply. Your question prompted me to check the docs 
> again, and I see there is the AuthLDAPRemoteUserIsDN option. I hadn't 
> realised that possibility before. I'll try it. Requiring our users to 
> enter their username in FQD isn't going to work. But if 
> AuthLDAPRemoteUserIsDN works in conjunction with the Subversion 
> authorisation file mechanism, that will work (albeit with some effort 
> to reformat our existing authorisation file and the custom web-based 
> admin tool we have to modify it).
>
> That would make options 3 and 4 feasible. Though option 4 has its own 
> "other problem".
>
> Regards,
> Craig McQueen
>
> Michele Mase' wrote:
>> Does the option 3 work changing the username from the form 
>> domain\username into username@domain (domain in fqd form i.e. 
>> example.com <http://example.com>)?
>> Regards Michele
>>
>> On Thu, Dec 11, 2008 at 9:12 AM, Craig McQueen 
>> <mcqueen-c@edsrd1.yzk.co.jp <mailto:mcqueen-c@edsrd1.yzk.co.jp>> wrote:
>>
>>     My company (in Australia) has a working Apache server on its
>>     Intranet -- incidentally, for serving Subversion. It's on Windows
>>     2003 and it's set up for authentication using the SSPI module.
>>     Currently Apache 2.0 but I want to upgrade to 2.2 to support the
>>     latest Subversion. We are also using a Subversion authorisation
>>     file that checks the username (provided by the authentication
>>     mechanism) against path access controls. The usernames are
>>     currently in the form LOCALDOMAIN\localuser.
>>
>>     It's a global company and we now want to allow remote branches to
>>     access the server. That means we want to extend authentication
>>     somehow. I'm looking at the options but coming across obstacles
>>     for every one. Here's what I've found. Note, I'm only really
>>     interested in options that will work for Apache 2.2, since
>>     version 2.2 is needed for any upgrade of Subversion. I'm testing
>>     on a Windows XP PC running Apache 2.2.10. <http://2.2.10.>
>>
>>     Option 1: Create local-domain usernames for remote people
>>     Not ideal due to security policy concerns.
>>
>>     Option 2: SSPI plus password file
>>     "Just doesn't work". Apache 2.2 changed the way authentication
>>     works. The SSPI module still works by itself in 2.2, but it
>>     doesn't cooperate with other authentication methods (as far as I
>>     can tell). Even though this reference says how it can be done:
>>     http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/help-onepage.html#tsvn-serversetup-apache-6
>>     When I configure it as said, the SSPI authentication continues to
>>     function but the password authentication never succeeds.
>>
>>     Option 3: LDAP plus password file
>>     It works. However, the LDAP module doesn't have a concept of
>>     "domains" so the usernames passed on to the Subversion file-based
>>     authorisation are in plain form, without any "LOCALDOMAIN\"
>>     prepended. This means that the authorisation file would need all
>>     "LOCALDOMAIN\" removed. Note that the password file can have
>>     usernames in the form e.g. REMOTEDOMAIN\remoteuser, so it is
>>     possible to avoid duplicates between the two systems.
>>
>>     Option 4: LDAP lookup of LOCALDOMAIN plus LDAP lookup of
>>     REMOTEDOMAIN (plus LDAP lookup of REMOTEDOMAIN2 etc)
>>     It looks as though it should be possible. However, I can't get
>>     the LDAP lookup of REMOTEDOMAIN to work (even by itself). It
>>     appears to be related to the fact that the REMOTEDOMAIN LDAP
>>     directory has Japanese characters in the "Base DN". I'm pretty
>>     sure the httpd.conf file has the Japanese characters specified in
>>     proper RFC 2255 format. So I think there is a problem in the LDAP
>>     authentication module in properly sending the queries with UTF-8
>>     content in the base DN. The error.log file says
>>     "[ldap_search_ext_s() for user failed][No Such Object]" which
>>     seems to indicate that the LDAP server isn't getting a valid base
>>     DN. Note that as in option 3, there is no concept of "domains".
>>     The authorisation file would not be able to systematically
>>     distinguish between users from LOCALDOMAIN and users from
>>     REMOTEDOMAIN. If we had identical usernames in the two domains,
>>     we wouldn't be able to separate them for authorisation.
>>
>>     So, we're currently stuck on all our options, for a variety of
>>     reasons. Any thoughts on this?
>>
>>     Regards,
>>     Craig McQueen
>>
>>

Mime
View raw message