httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Date Tue, 16 Sep 2008 20:35:35 GMT
Clayton Hicklin wrote:
> On Tue, Sep 16, 2008 at 3:11 PM, André Warnier <aw@ice-sa.com> wrote:
> 
>> Clayton Hicklin wrote:
>>
>>> On Tue, Sep 16, 2008 at 2:40 PM, Clayton Hicklin <chicklin@gmail.com>
>>> wrote:
>>>
>>>  "So what I believe in this case, is that the LDAP module might, possibly,
>>>> rely on the "REMOTE_USER" header that IE is sometimes sending when the
>>>> user
>>>> is authenticated in the domain.  And that one indeed would probably
>>>> contain
>>>> the domain and user.  If that is the case, then a simple manipulation of
>>>> the
>>>> HTTP headers of the request, using standard Apache modules, might be
>>>> enough
>>>> to get just the user."
>>>>
>>>> I agree, I believe that is exactly what is happening.  I can verify that
>>>> the REMOTE_USER server variable is set to 'domain\user' using PHP (echo
>>>> $_SERVER['REMOTE_USER']).  I didn't realize that you could manipulate
>>>> headers with Apache.  I will definitely look into this as it sounds like
>>>> that is what I need.  Thanks.
>>>>
>>>> Clayton
>>>>
>>>>
>>>> On Tue, Sep 16, 2008 at 2:32 PM, André Warnier <aw@ice-sa.com> wrote:
>>>>
>>>>  Clayton Hicklin wrote:
>>>>>  On Tue, Sep 16, 2008 at 1:28 PM, André Warnier <aw@ice-sa.com>
wrote:
>>>>>>  Clayton Hicklin wrote:
>>>>>> [...]
>>>>>>
>>>>> Clayton,
>>>>> Your first communication was a bit summarised, so I did not know to
>>>>> which
>>>>> extent you knew the underlying tidbits, from there my fist answer.
>>>>>
>>>>> I am currently in the middle of the same kind of problematic. I have
>>>>> created an SSO solution that works at the Tomcat level, in a particular
>>>>> context, and and I am interested in a solution at the Apache level, just
>>>>> like you.
>>>>> In the process of creating the Tomcat-level solution, I have learned
>>>>> quite
>>>>> a bit about how IE (and servers) work in that respect, and my
>>>>> questions/opinions are guided by that.
>>>>>
>>>>>
>>>>>   I didn't mean to imply that the authentication fails "in" IE.  I
>>>>>> realize it
>>>>>> is at the server.  My issue is that I would like a seamless user
>>>>>> experience.  IE is passing 'domain\user' due to "Windows Integrated
>>>>>> Authentication" being turned on and it would be nice if those
>>>>>> credentials
>>>>>> could be used to authenticate without popping up the login dialog.
>>>>>>
>>>>>>  That is what should indeed happen, if the server supports the related
>>>>> authentication, meaning the authentication "type" that IE is trying.
>>>>>
>>>>>  This
>>>>>
>>>>>  works using the mod_auth_sspi module (which uses NTLM) but not with
>>>>>> LDAP
>>>>>> authentication.
>>>>>>
>>>>>>  Which module are you using for this LDAP authentication ?
>>>>>  The reason is that with LDAP authentication, you have to
>>>>>
>>>>>  specify an attribute to search for the username that is passed to
>>>>>> Apache.
>>>>>> In the case of Active Directory, this attribute is sAMAccountName.
>>>>>>  This
>>>>>> attribute stores the username of the Windows user.  The problem is
that
>>>>>> IE
>>>>>> passes 'domain\user' (not just 'user') on it's first attempt at
>>>>>> authentication.
>>>>>>
>>>>>>  That's where I am not so sure.  What makes you sure that this is
>>>>> indeed
>>>>> what is happening ? (I am not saying it is false, I just mean that I
>>>>> have a
>>>>> doubt and would be interested in whether you have really verified this,
>>>>> and
>>>>> how).
>>>>>
>>>>> This obviously fails which causes the login dialog to pop
>>>>>
>>>>>  up.  You can then just type in your username and password and
>>>>>> everything
>>>>>> works fine.
>>>>>>
>>>>>> I think the ultimate solution would be to modify the Apache LDAP
module
>>>>>> to
>>>>>> accept a parameter that would optionally strip out the domain portion
>>>>>> of
>>>>>> the
>>>>>> credentials that IE passes.
>>>>>>
>>>>>>  Yes, that kind of what you need, unless that parameter already exists
>>>>> in
>>>>> the module you are using.  It would be relatively surprising if it
>>>>> didn't.
>>>>> But even if it isn't available, there might be another solution, stay
>>>>> with
>>>>> me.
>>>>>
>>>>>  That way, we could use IE + APACHE + Active
>>>>>
>>>>>  Directory (LDAP) for a seamless SSO solution.  I think this would be
>>>>>> pretty
>>>>>> common in most corporate environments, which is where this is being
>>>>>> implemented.
>>>>>>
>>>>>>
>>>>>>  One nore thing I want to add here, is a brief summary of how web
>>>>> authentication works, just in case there is a part in there that isn't
>>>>> clear
>>>>> to you, and because there is a particular step that may play a role.
>>>>>
>>>>> 0) we imagine that, at the beginning, the browser is just opened, and
>>>>> knows nothing yet of the URL or the server on which it resides.
>>>>>
>>>>> 1) browser sends a request to server for a particular URL.  Because the
>>>>> browser at this stage does not know that this URL requires any
>>>>> authentication, the request is sent without any authentication.
>>>>> 2) the server receives this request.  It consults its configuration,
and
>>>>> sees that this URL requires some form of authentication and/or access
>>>>> control.  It thus verifies if the request contains this kind of
>>>>> authentication. If yes, the request goes through and we're done.
>>>>> 3) The request does not contain an authentication (or not one of the
>>>>> accepted type). So the server sends back to the browser a response "401
>>>>> Authorization required", along with the type of authentication required
>>>>> (NTLM, Basic, Digest are 3 possible, supported by IE), and along (if
>>>>> Basic
>>>>> or Digest) with a "realm" (the protected "area" name on the server).
>>>>> 4) the browser receives the 401 response.  It looks at the
>>>>> "authentication
>>>>> type" required, and, *if it can handle that* (which may depend on its
>>>>> settings, security zone etc..) it proceeds to try that kind of
>>>>> authentication. (If the browser cannot handle that particular type of
>>>>> authentication requested by the server, it may check if it has a
>>>>> "fallback
>>>>> type" that it can try. If it doesn't have such a fall-back, I do not
>>>>> know
>>>>> really what happens, but I guess some kind of error at the browser
>>>>> side.)
>>>>> 5) once the browser has "put in the bag" the required pieces for the
>>>>> authentication (as requested by the server, or its fallback type), it
>>>>> re-sends the same original request to the server, but this time it adds
>>>>> an
>>>>> "Authorization:" header with the appropriate content.
>>>>>
>>>>> Now, depending on the case, a back-and-forth dialog *may* take place
>>>>> between the server and the browser.  For instance, with IE and NTLM
>>>>> authentication, there are 3 such exchanges before the server and browser
>>>>> are
>>>>> satisfied, and the browser has the right content to send in its
>>>>> "Authorization:" header.
>>>>>
>>>>>
>>>>> I am only pointing this all out so that it would be clearer that it is
>>>>> important to know, for instance, *which* kind of authentication the LDAP
>>>>> module is telling IE (in the 401 message) that is required.
>>>>> Unless this LDAP module can handle an NTLM-type 3-step dialog with IE
>>>>> (like the mod_auth_sspi module can), then probably what the module sends
>>>>> is
>>>>> a response which requires a "Basic" authentication.
>>>>> Does IE then automatically send whatever IE thinks the domain\userid
is
>>>>> ,
>>>>> as a "Authorization: Basic xxxxxxxxxxxxxxxxxx" header containing the
>>>>> user-id
>>>>> and user password ?
>>>>> It seems a bit far-fetched that IE would send the user's password over
>>>>> the
>>>>> network, just Base64-encoded.
>>>>>
>>>>> So what I believe in this case, is that the LDAP module might, possibly,
>>>>> rely on the "REMOTE_USER" header that IE is sometimes sending when the
>>>>> user
>>>>> is authenticated in the domain.  And that one indeed would probably
>>>>> contain
>>>>> the domain and user.  If that is the case, then a simple manipulation
of
>>>>> the
>>>>> HTTP headers of the request, using standard Apache modules, might be
>>>>> enough
>>>>> to get just the user.
>>>>>
>>>>> That was a long message, but in the end the answer may be simple.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> The official User-To-User support forum of the Apache HTTP Server
>>>>> Project.
>>>>> See <URL:http://httpd.apache.org/userslist.html> for more info.
>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>>  "   from the digest: users-digest-unsubscribe@httpd.apache.org
>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Clayton Hicklin
>>>> chicklin@gmail.com
>>>>
>>>>
>>> Sorry about top-posting on that last message (stupid Gmail :).
>>>
>>> So, it looks like I need mod_setenvif, right?  Could anybody write a quick
>>> directive that would look at REMOTE_USER to see if there is a backslash
>>> ("\"), and if there is, set the same variable to everything following the
>>> backslash?  I think this would solve my problem.  I would rather use
>>> mod_authnz_ldap that  mod_auth_sspi as it is included with Apache and is
>>> well-supported.
>>>
>>>
>> I would try the following, but it's mod_headers, not mod_setenvif :
>>
>> RequestHeader edit REMOTE_USER ^(?:[^\\]+\\)(.+)$ $1
>>
>> the regexp should mean (if really it's a perl regexp) :
>> - for the first () group, match but do not capture
>> - match (potentially) from the beginning, anything before the backslash and
>> the backslash itself, if any such things.
>> - then match whatever is left, and capture it as $1
>>
>> then replace this all by $1
>>
>> (the fancy maybe-match stuff is just in case you *don't* get a domain
>> sometimes)
>>
>> That's what I'm trying to do anyway, regexpes are painful (but nice).
>>
>> Please let us know if the whole solution works in the end.
>>
>>
>>
>> ---------------------------------------------------------------------
>> The official User-To-User support forum of the Apache HTTP Server Project.
>> See <URL:http://httpd.apache.org/userslist.html> for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>  "   from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
> Andre,
>   The regex does not compile, according to the Apache error log.  The manual
> says Apache uses PCRE, btw.  I will see if I can figure out where the error
> is.
> 
Strange :

#!/usr/bin/perl -w
use strict;

my $RU = "domain\\user";
$RU =~ m/^(?:[^\\]+\\)(.+)$/;
my $user = $1;
print "1) User : $user\n";

$RU = "user";
$RU =~ m/^(?:[^\\]+\\)(.+)$/;
$user = $1;
print "2) User : $user\n";

exit;


output :

1) User : user
2) User : user


Maybe under Apache, it escapes the backslashes automatically by itself ?
Try :

^(?:[^\]+\)(.+)$


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message