httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Date Tue, 16 Sep 2008 19:32:17 GMT
Clayton Hicklin wrote:
> On Tue, Sep 16, 2008 at 1:28 PM, André Warnier <> wrote:
>> Clayton Hicklin wrote:

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.

> 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:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message