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:11:16 GMT
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


Mime
View raw message