Does the option 3 work changing the username from the form domain\username into [EMAIL PROTECTED] (domain in fqd form i.e. example.com)? Regards Michele
On Thu, Dec 11, 2008 at 9:12 AM, Craig McQueen <[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. > > 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 > >
