httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clayton Hicklin" <chick...@gmail.com>
Subject Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Date Tue, 16 Sep 2008 20:58:20 GMT
On Tue, Sep 16, 2008 at 3:35 PM, André Warnier <aw@ice-sa.com> wrote:

> 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
>
>
It keeps saying "regex could not compile" even though I can get it to work
in the regex tester.  Weird.

-- 
Clayton Hicklin
chicklin@gmail.com

Mime
View raw message