You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Craig McQueen <mc...@edsrd1.yzk.co.jp> on 2008/12/11 09:12:46 UTC
Multiple authentication sources
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
Re: Multiple authentication sources
Posted by Krist van Besien <kr...@gmail.com>.
On Thu, Dec 11, 2008 at 9:12 AM, Craig McQueen
<mc...@edsrd1.yzk.co.jp> wrote:
> 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 had the same issues, also with an apache subversion server.
In the end I settled for making the same subversion repository
available under a different url to the outside world. There I
implemented a different authentication mechanism.
Krist
--
krist.vanbesien@gmail.com
krist@vanbesien.org
Bremgarten b. Bern, Switzerland
--
A: It reverses the normal flow of conversation.
Q: What's wrong with top-posting?
A: Top-posting.
Q: What's the biggest scourge on plain text email discussions?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Multiple authentication sources
Posted by Morgan Gangwere <0....@gmail.com>.
Simple fix: have a job on the server that comes by and takes all the
auth data from one source and consolidates it into its own, then goes to
the next, rinse repeat.
Shoudlnt be hard...
--
Morgan Gangwere
Unknown Software
http://sonof.bandit.name/
Member, INCOSE [ incose.org ] PACA [ paca.org ] and NMUG [ nmug.net ]
[indrora@boxly ~]#_
Find me on FreeNode! irc.freenode.net ~indrora on ##linux
Re: Multiple authentication sources
Posted by André Warnier <aw...@ice-sa.com>.
Hi.
Craig McQueen wrote:
[...]
I believe (only believe, not certain), that the Windows Domain method
would work if your local domain and the global domain were in a "trust
relationship" (Windows Domain term) with eachother. That is, the DC
that you use for SSPI authentication acepts the id's from users in other
trusted domains.
If that is not the case yet, it may be more than you want to chew though.
The question is : apart from this particular service, do these external
corporate users already use other Windows-based services in your
network, for which they also need to authenticate ? If yes, there it
might be worth investigating how that happens.
If the above works, then you may still have an issue removing/mangling
the domain-name part of the id. But that can be solved with another layer.
Note : I am very interested in the matter, because I have a similar case
to resolve. But until now I have done this only at the Tomcat level,
using the JCIFS module from jcifs.samba.org. I have not yet tried out
the SSPI module.
That address jcifs.samba.org is a good one for all kinds of info about
Windows NTLM authentication by the way.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Re: Multiple authentication sources
Posted by Craig McQueen <mc...@edsrd1.yzk.co.jp>.
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 <ma...@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
>>
>>
Re: Multiple authentication sources
Posted by Craig McQueen <mc...@edsrd1.yzk.co.jp>.
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 <ma...@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
>
>
Re: Multiple authentication sources
Posted by Michele Mase' <mi...@gmail.com>.
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
<mc...@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.
>
> 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
>
>