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@xxxxxxxxxxxxxxxx
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)?
Regards Michele
On Thu, Dec 11, 2008 at 9:12 AM, Craig
McQueen <mcqueen-c@xxxxxxxxxxxxxxxx>
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.
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
|
