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 [EMAIL PROTECTED] (domain in fqd form i.e.
example.com <http://example.com>)?
Regards Michele
On Thu, Dec 11, 2008 at 9:12 AM, Craig McQueen
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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
