Pass-through LDAP authentication with Internet Explorer and Active Directory

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

"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 havea
> 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

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 browserare
>> 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 sendsis
>> 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 ofthe
>> 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.

--
Clayton Hicklin
chicklin@gmail.com

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

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

>> 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.

The authentication/authorization modules don't read from the
REMOTE_USER environment variable.

--
Eric Covener
covener@gmail.com

---------------------------------------------------------------------
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

Eric Covener wrote:
>>> 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.
>
> The authentication/authorization modules don't read from the
> REMOTE_USER environment variable.
>
Party pooper !


---------------------------------------------------------------------
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

On Tue, Sep 16, 2008 at 4:11 PM, André Warnier <aw@ice-sa.com> wrote:
> 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

n/a to OP problem, but I think the regex can be shrunk to ([^\\]+)

--
Eric Covener
covener@gmail.com

---------------------------------------------------------------------
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

On Tue, Sep 16, 2008 at 3:37 PM, Eric Covener <covener@gmail.com> wrote:

> >> 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.
>
> The authentication/authorization modules don't read from the
> REMOTE_USER environment variable.
>
> --
> Eric Covener
> covener@gmail.com
>
> ---------------------------------------------------------------------
> 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
>
>
Well, where are they getting their info? This is what I'm getting in the
error log:

[5028] auth_ldap authenticate: user WHQ_NT_DOMAIN\\ch017001 authentication
failed; URI /scpmanager/ [User not found][No Such Object]

Clearly domain\user is getting passed to the authn/authz modules from IE
somehow or another.

--
Clayton Hicklin
chicklin@gmail.com

André Warnier wrote:
> Eric Covener wrote:
>>>> 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.
>>
>> The authentication/authorization modules don't read from the
>> REMOTE_USER environment variable.
>>
> Party pooper !
>
Clayton,
I kind of get a feeling that Eric is right though, because a) he usually
seems to know his stuff, and b) that would not be very secure, to say
the least.
That would mean that we are back to try and figure out what exactly
happens between IE and the server, and it what circumstances exactly IE
sends this domain\user-id thing.

But maybe Eric can help there ?
Eric, what kind of "401" does mod_authnz_ldap send to the browser when
it needs authentication ? Basic ?
Then I can't quite imagine Clayton's scheme working, because IE would
never of its own device send the user's password (I don't even think it
knows it).



---------------------------------------------------------------------
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