You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Clayton Hicklin <ch...@gmail.com> on 2008/09/16 17:40:35 UTC
[users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
I have LDAP authentication against Active Directory working perfectly in
Firefox, but my problem is with IE. IE automatically passes through the
username and password so once you are logged into the domain, you don't have
to type it in again.
That's great, except it is passed through as <domain>\<user>. To do LDAP
authentication against Active Directory, I am searching the sAMAccountName
attribute of the users. This attribute holds the username for that user,
but does not include the <domain>\ prefix, therefore authentication fails in
IE and it prompts you for the username and password.
As far as I can tell, the <domain>\ prefix is not stored anywhere inside the
user object, so there is no way to authenticate with the credentials that IE
provides.
Has anybody got this working? Is there some sort of workaround or hidden
parameter in the Apache LDAP modules that might fix this? Thanks!
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
This is a "trusted" site, which, according to the Windows Integrated
Authentication docs, means that IE will happily send the authentication
credentials, but I would be more inclined to think that they will just not
be in the right format for mod_authnz_ldap to handle. What's weird is that
it is definitely getting the domain\username part of it.
Maybe it just won't work. I got mod_auth_sspi working with a workaround, so
maybe I'll just go that route.
On Tue, Sep 16, 2008 at 3:51 PM, André Warnier <aw...@ice-sa.com> wrote:
> 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
>
>
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.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
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Clayton Hicklin wrote:
[...]
>
> After doing some more reading, I really think this isn't going to work how I
> want.
There, I think you are basically right.
IE is never going to send the password in clear (or even encoded as
Base64), unless you use Basic authentication, and in my opinion that
implies the ugly IE popup login dialog.
Unless we can somehow modify the 'domain\username' that IE is sending
> before it is processed by the auth modules,
Now that in itself, is NOT a big issue.
Anything a browser sends to Apache can be intercepted, and modified, at
whatever stage you want (e.g. before any authentication module has a
chance to look at it).
The question is "does the browser send it ?".
The other question here is the choice of the tools to do it.
I do this regularly using either some Apache "built-in" C module (like
mod_headers, mod_setenvif, mod_rewrite,..), or an existing mod_perl
module (www.cpan.org) (which implies perl and mod_perl, but is
multi-platform as much as Apache), or using a custom mod_perl module
that I create myself (often by using an existing module as base), or a
combination of all the above.
It sounds ugly, but it is extremely effective, multi-platform, and you
can usually do exactly what you want.
and unless it is sending the
> password in Base64 format (which we don't really know), it's just not going
> to work.
That seems to be the main problem in your case.
Any web authentication mechanism worth it's salt, is not going to give
you access directly to the user's password.
And even if the mechanism allowed you to do that, you have 99%
probability that the sysadmins of the corporate network in which this
would run, would not let you install that. Unless of course you are the
sysadmin...
>
> I have mod_auth_sspi working, but only because I'm running Apache on
> Windows. The other option is Kerberos authentication with mod_auth_kerb.
> It is not part of the standard Apache distribution, but I think this is
> going to be your best bet if you're running on Linux.
>
Well, I have some alternatives left for what I want and need to do,
based on the above. But the main difference in my case is that I do not
need the user's password. I just need to make sure that the user-id I
get is valid and authenticated.
My own next stop is here :
http://cpan.uwinnipeg.ca/htdocs/Apache2-AuthenNTLM/Apache2/AuthenNTLM.html
(Unix/Linux only, but worth a look anyway).
In the worst case (which is probably a station on the Internet needing
an NTLM authentication to access an Intranet application running under
Unix/Linux), it is always possible to set up a separate "authentication
server" where you do what's needed, and have the client go there first
to get a token (via HTTPS for instance).
(A few of my corporate customers do that anyway, because otherwise you
are always dependent on IE and what its settings are).
Which is also pretty much what Kerberos does.
(Kerberos won't give you a user password either by the way, and is quite
heavy to set up).
You may also want to have a look here : http://openid.net/
That's a clever alternative.
And one last thing : for multi-browser, multi-platform,
multi-environment kind of web authentication/SSO needs, cookies are your
best friend. You can store whatever you want in them (preferably
encrypted) once your initial authentication is done, and re-use the
content to speed up subsequent accesses. You can also log a user out,
by resetting his cookie. That is something you don't get with the usual
"built-in" browser authentication mechanisms.
André
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Wed, Sep 17, 2008 at 4:56 AM, André Warnier <aw...@ice-sa.com> wrote:
> Clayton Hicklin wrote:
>
>> On Tue, Sep 16, 2008 at 4:21 PM, André Warnier <aw...@ice-sa.com> wrote:
>>
>> I'm beginning to think
>>>>>
>>>> we're chasing our tails. IE is going to pass the credentials in NTLM
>>>> format, I believe. Even if we got the username right, I'm thinking
>>>> maybe
>>>> the password won't be readable by mod_authn_ldap. I don't know.
>>>>
>>>> IE can do either of 3 things, as far as I know :
>>>>
>>> 1) if it is doing Basic authentication, it will pass the user-id and
>>> password (as entered by the user in the pop-up login dialog), both merely
>>> encoded in a Base64 format.
>>> It passes that in a "Authorization:" request header.
>>>
>>>
>> I believe it is basic authorization. The AuthType is set to Basic and the
>> AuthBasicProvider (not sure if that's right, I don't have access to it at
>> the moment) is set to ldap. So, maybe there is no NTLM involved here.
>> The
>> user is already authenticated with the domain. My original thought is
>> that
>> IE sees the site requesting Basic authentication and is supplying the
>> domain\user and base64 password. That's why I was hoping to just strip
>> out
>> the domain\ part.
>>
>>
>> 2) if it is doing Digest authentication, it will pass the user-id and a
>>> cryptic "token" based on the user-id and password entered by the user in
>>> a
>>> pop-up login dialog. The server-side must then somehow verify that this
>>> token matches one generated server-side on the base of the user password.
>>> It passes that in a "Authorization:" request header.
>>> That is anyway not what you want here.
>>>
>>>
>> Nope, not doing digest.
>>
>>
>> 3) if it is doing NTLM authentication, then it will also pass the user-id
>>> and a token, but as a result of a multi-step negociation with an
>>> appropriate
>>> NTLM module on the server, which itself needs to talk to a Windows Domain
>>> Controller etc..
>>> At the end of all that, IE will pass the user-id and token to the server
>>> with the request, in, I believe, a WWW-authenticate: header.
>>> But that token does not contain the password, and IE at no point gets to
>>> know the password.
>>>
>>>
>> Seems like it would only do NTLM if I'm using the mod_auth_sspi module.
>> The
>> more I think about it, the more it doesn't make any sense that IE would
>> try
>> and do NTLM when Apache is requesting Basic.
>>
>>
>> But maybe do not give up yet.
>>>
>>> If you are in a Windows Domain, and it is inside a corporate environment,
>>> then presumably this REMOTE_USER that IE is sending, is already the
>>> result
>>> of some secure Domain authentication which happened before.
>>> And if so, you might be able to accept it as secure enough, and use its
>>> content as a user-id.
>>> The whole point now is to know whether you really need to know the user
>>> password, or if the mere fact of verifying that the user indeed exists in
>>> the LDAP system is enough (and maybe not even that).
>>> It all depends if you want to provide a reall secure login system, or if
>>> your purpose is to provide a user-friendly SSO mechanism for Apache
>>> applications.
>>>
>>>
>> Well, I need to do group authentication via LDAP, and the LDAP module
>> binds
>> with the DN it looks up using the username provided by the browser. It
>> definitely needs the password.
>>
>>
>> One item just to clear up a lingering doubt : when you show the user-id
>>> that auth_ldap is dumping to the logfile, was that the result of a popup
>>> login dialog in IE, or was there no such popup dialog involved ?
>>>
>>>
>>> Not the result of the popup, that was IE trying to send the credentials
>> automatically.
>>
>> That is what I really do not understand here :
> 1) the first time IE tries to access the URL, it does not send an HTTP
> authentication header, because it does not even know that the URL requires
> authentication.
> 2) then the server sends him back a "401 authentication required", along
> with the type of authentication. And let's say it is "Basic".
> 3) then it would seem that IE automatically sends the "user\domain", and
> the user password, encoded in a "Basic" authorisation header.
>
I believe this is what's happening, yes.
>
> That last part #3 seems extremely unlikely to me, for several reasons :
> - first, it supposes that IE already knows the user's password. I don't
> see how it would. Even if the user has already authenticated to the Windows
> Domain :
> a) the NTLM authentication never "circulates" the user's password on the
> network, only encrypted tokens that depend, in part, on the user password.
> b) it would mean that any server that sent a "401, Basic" response to IE,
> would receive the user's password in return, in clear. That seems like such
> a big security hole that I don't believe it.
> (If it is true, then this is going to give some nightmares to a few hundred
> thousand network administrators worldwide).
>
Not exactly. IE will only send the credentials to "trusted" sites, which in
the default setup is means servers on the same subnet. Otherwise, a site is
considered "untrusted" and IE will not automatically sign on. This is how
"Windows Integrated Authentication" works, according to what I've read. IE
is clearly passing 'domain\username' but I don't have any idea what password
it is sending. Maybe the Base64 encoded password, but who knows.
>
> So, there *must* be something else going on here.
>
> (I can still imagine that somehow IE would send the "domain\userid",
> although even that I don't really understand).
>
> On a separate level :
>
> To get some user information using LDAP, you do not necessarily need that
> specific user's password. It should be possible to get information about a
> user, by using some special login user-id/password (always the same) to
> connect to the LDAP server , and be allowed at least to read the "public"
> part of other user's records (not their password e.g., but their group
> memberships probably yes). If that was not possible, then an LDAP server
> would not be useful as a directory back-end, which is their principal
> function.
>
mod_authnz_ldap requires either the ability to bind anonymously, or you can
specify a DN and password to bind with for the initial search phase (i.e.
when it looks up the username supplied by the client). Once that user is
found, it re-binds to the directory using that user's credentials. At that
point, it will check the requirements you've set up (require valid-user,
require ldap-group, etc....).
>
> I am sorry, but my own circumstances are such that I am not working within
> a Windows domain, so I can just not test this easily.
> When I do such kind of work, I also tend to do it on-site, at the customer
> for which it is needed, so that I am sure that I am in exactly the right
> context.
>
>
> André
>
> ---------------------------------------------------------------------
> 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
>
>
After doing some more reading, I really think this isn't going to work how I
want. Unless we can somehow modify the 'domain\username' that IE is sending
before it is processed by the auth modules, and unless it is sending the
password in Base64 format (which we don't really know), it's just not going
to work.
I have mod_auth_sspi working, but only because I'm running Apache on
Windows. The other option is Kerberos authentication with mod_auth_kerb.
It is not part of the standard Apache distribution, but I think this is
going to be your best bet if you're running on Linux.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Clayton Hicklin wrote:
> On Tue, Sep 16, 2008 at 4:21 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>>>> I'm beginning to think
>>> we're chasing our tails. IE is going to pass the credentials in NTLM
>>> format, I believe. Even if we got the username right, I'm thinking maybe
>>> the password won't be readable by mod_authn_ldap. I don't know.
>>>
>>> IE can do either of 3 things, as far as I know :
>> 1) if it is doing Basic authentication, it will pass the user-id and
>> password (as entered by the user in the pop-up login dialog), both merely
>> encoded in a Base64 format.
>> It passes that in a "Authorization:" request header.
>>
>
> I believe it is basic authorization. The AuthType is set to Basic and the
> AuthBasicProvider (not sure if that's right, I don't have access to it at
> the moment) is set to ldap. So, maybe there is no NTLM involved here. The
> user is already authenticated with the domain. My original thought is that
> IE sees the site requesting Basic authentication and is supplying the
> domain\user and base64 password. That's why I was hoping to just strip out
> the domain\ part.
>
>
>> 2) if it is doing Digest authentication, it will pass the user-id and a
>> cryptic "token" based on the user-id and password entered by the user in a
>> pop-up login dialog. The server-side must then somehow verify that this
>> token matches one generated server-side on the base of the user password.
>> It passes that in a "Authorization:" request header.
>> That is anyway not what you want here.
>>
>
> Nope, not doing digest.
>
>
>> 3) if it is doing NTLM authentication, then it will also pass the user-id
>> and a token, but as a result of a multi-step negociation with an appropriate
>> NTLM module on the server, which itself needs to talk to a Windows Domain
>> Controller etc..
>> At the end of all that, IE will pass the user-id and token to the server
>> with the request, in, I believe, a WWW-authenticate: header.
>> But that token does not contain the password, and IE at no point gets to
>> know the password.
>>
>
> Seems like it would only do NTLM if I'm using the mod_auth_sspi module. The
> more I think about it, the more it doesn't make any sense that IE would try
> and do NTLM when Apache is requesting Basic.
>
>
>> But maybe do not give up yet.
>>
>> If you are in a Windows Domain, and it is inside a corporate environment,
>> then presumably this REMOTE_USER that IE is sending, is already the result
>> of some secure Domain authentication which happened before.
>> And if so, you might be able to accept it as secure enough, and use its
>> content as a user-id.
>> The whole point now is to know whether you really need to know the user
>> password, or if the mere fact of verifying that the user indeed exists in
>> the LDAP system is enough (and maybe not even that).
>> It all depends if you want to provide a reall secure login system, or if
>> your purpose is to provide a user-friendly SSO mechanism for Apache
>> applications.
>>
>
> Well, I need to do group authentication via LDAP, and the LDAP module binds
> with the DN it looks up using the username provided by the browser. It
> definitely needs the password.
>
>
>> One item just to clear up a lingering doubt : when you show the user-id
>> that auth_ldap is dumping to the logfile, was that the result of a popup
>> login dialog in IE, or was there no such popup dialog involved ?
>>
>>
> Not the result of the popup, that was IE trying to send the credentials
> automatically.
>
That is what I really do not understand here :
1) the first time IE tries to access the URL, it does not send an HTTP
authentication header, because it does not even know that the URL
requires authentication.
2) then the server sends him back a "401 authentication required", along
with the type of authentication. And let's say it is "Basic".
3) then it would seem that IE automatically sends the "user\domain", and
the user password, encoded in a "Basic" authorisation header.
That last part #3 seems extremely unlikely to me, for several reasons :
- first, it supposes that IE already knows the user's password. I don't
see how it would. Even if the user has already authenticated to the
Windows Domain :
a) the NTLM authentication never "circulates" the user's password on
the network, only encrypted tokens that depend, in part, on the user
password.
b) it would mean that any server that sent a "401, Basic" response to
IE, would receive the user's password in return, in clear. That seems
like such a big security hole that I don't believe it.
(If it is true, then this is going to give some nightmares to a few
hundred thousand network administrators worldwide).
So, there *must* be something else going on here.
(I can still imagine that somehow IE would send the "domain\userid",
although even that I don't really understand).
On a separate level :
To get some user information using LDAP, you do not necessarily need
that specific user's password. It should be possible to get information
about a user, by using some special login user-id/password (always the
same) to connect to the LDAP server , and be allowed at least to read
the "public" part of other user's records (not their password e.g., but
their group memberships probably yes). If that was not possible, then an
LDAP server would not be useful as a directory back-end, which is their
principal function.
I am sorry, but my own circumstances are such that I am not working
within a Windows domain, so I can just not test this easily.
When I do such kind of work, I also tend to do it on-site, at the
customer for which it is needed, so that I am sure that I am in exactly
the right context.
André
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 4:21 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>>> I'm beginning to think
>
>> we're chasing our tails. IE is going to pass the credentials in NTLM
>> format, I believe. Even if we got the username right, I'm thinking maybe
>> the password won't be readable by mod_authn_ldap. I don't know.
>>
>> IE can do either of 3 things, as far as I know :
>
> 1) if it is doing Basic authentication, it will pass the user-id and
> password (as entered by the user in the pop-up login dialog), both merely
> encoded in a Base64 format.
> It passes that in a "Authorization:" request header.
>
I believe it is basic authorization. The AuthType is set to Basic and the
AuthBasicProvider (not sure if that's right, I don't have access to it at
the moment) is set to ldap. So, maybe there is no NTLM involved here. The
user is already authenticated with the domain. My original thought is that
IE sees the site requesting Basic authentication and is supplying the
domain\user and base64 password. That's why I was hoping to just strip out
the domain\ part.
>
> 2) if it is doing Digest authentication, it will pass the user-id and a
> cryptic "token" based on the user-id and password entered by the user in a
> pop-up login dialog. The server-side must then somehow verify that this
> token matches one generated server-side on the base of the user password.
> It passes that in a "Authorization:" request header.
> That is anyway not what you want here.
>
Nope, not doing digest.
>
> 3) if it is doing NTLM authentication, then it will also pass the user-id
> and a token, but as a result of a multi-step negociation with an appropriate
> NTLM module on the server, which itself needs to talk to a Windows Domain
> Controller etc..
> At the end of all that, IE will pass the user-id and token to the server
> with the request, in, I believe, a WWW-authenticate: header.
> But that token does not contain the password, and IE at no point gets to
> know the password.
>
Seems like it would only do NTLM if I'm using the mod_auth_sspi module. The
more I think about it, the more it doesn't make any sense that IE would try
and do NTLM when Apache is requesting Basic.
>
> But maybe do not give up yet.
>
> If you are in a Windows Domain, and it is inside a corporate environment,
> then presumably this REMOTE_USER that IE is sending, is already the result
> of some secure Domain authentication which happened before.
> And if so, you might be able to accept it as secure enough, and use its
> content as a user-id.
> The whole point now is to know whether you really need to know the user
> password, or if the mere fact of verifying that the user indeed exists in
> the LDAP system is enough (and maybe not even that).
> It all depends if you want to provide a reall secure login system, or if
> your purpose is to provide a user-friendly SSO mechanism for Apache
> applications.
>
Well, I need to do group authentication via LDAP, and the LDAP module binds
with the DN it looks up using the username provided by the browser. It
definitely needs the password.
>
> One item just to clear up a lingering doubt : when you show the user-id
> that auth_ldap is dumping to the logfile, was that the result of a popup
> login dialog in IE, or was there no such popup dialog involved ?
>
>
Not the result of the popup, that was IE trying to send the credentials
automatically.
>
>
> ---------------------------------------------------------------------
> 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
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
>>
I'm beginning to think
> we're chasing our tails. IE is going to pass the credentials in NTLM
> format, I believe. Even if we got the username right, I'm thinking maybe
> the password won't be readable by mod_authn_ldap. I don't know.
>
IE can do either of 3 things, as far as I know :
1) if it is doing Basic authentication, it will pass the user-id and
password (as entered by the user in the pop-up login dialog), both
merely encoded in a Base64 format.
It passes that in a "Authorization:" request header.
2) if it is doing Digest authentication, it will pass the user-id and a
cryptic "token" based on the user-id and password entered by the user in
a pop-up login dialog. The server-side must then somehow verify that
this token matches one generated server-side on the base of the user
password.
It passes that in a "Authorization:" request header.
That is anyway not what you want here.
3) if it is doing NTLM authentication, then it will also pass the
user-id and a token, but as a result of a multi-step negociation with an
appropriate NTLM module on the server, which itself needs to talk to a
Windows Domain Controller etc..
At the end of all that, IE will pass the user-id and token to the server
with the request, in, I believe, a WWW-authenticate: header.
But that token does not contain the password, and IE at no point gets to
know the password.
But maybe do not give up yet.
If you are in a Windows Domain, and it is inside a corporate
environment, then presumably this REMOTE_USER that IE is sending, is
already the result of some secure Domain authentication which happened
before.
And if so, you might be able to accept it as secure enough, and use its
content as a user-id.
The whole point now is to know whether you really need to know the user
password, or if the mere fact of verifying that the user indeed exists
in the LDAP system is enough (and maybe not even that).
It all depends if you want to provide a reall secure login system, or if
your purpose is to provide a user-friendly SSO mechanism for Apache
applications.
One item just to clear up a lingering doubt : when you show the user-id
that auth_ldap is dumping to the logfile, was that the result of a popup
login dialog in IE, or was there no such popup dialog involved ?
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 4:00 PM, André Warnier <aw...@ice-sa.com> wrote:
> Clayton Hicklin wrote:
>
>> On Tue, Sep 16, 2008 at 3:37 PM, Eric Covener <co...@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.
>>
>> This is getting interesting. How indeed ?
> Is there a way to trace the headers being sent back and forth during this
> authentication phase, at the Apache level ? We're talking IE as a browser
> here, so Firefox add-ons don't count.
>
> If not, assuming that server has perl and mod_perl available, I could put
> together a quick access handler that does that.
> (as mentioned before, I have a stake in a solution too).
>
>
> ---------------------------------------------------------------------
> 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
>
>
In this case, Apache is running on Windows. Although it could be loaded,
perl and mod_perl are not available at the moment. I'm beginning to think
we're chasing our tails. IE is going to pass the credentials in NTLM
format, I believe. Even if we got the username right, I'm thinking maybe
the password won't be readable by mod_authn_ldap. I don't know.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Clayton Hicklin wrote:
> On Tue, Sep 16, 2008 at 3:37 PM, Eric Covener <co...@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.
>
This is getting interesting. How indeed ?
Is there a way to trace the headers being sent back and forth during
this authentication phase, at the Apache level ? We're talking IE as a
browser here, so Firefox add-ons don't count.
If not, assuming that server has perl and mod_perl available, I could
put together a quick access handler that does that.
(as mentioned before, I have a stake in a solution too).
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 3:37 PM, Eric Covener <co...@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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Eric Covener <co...@gmail.com>.
>> 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
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Eric Covener wrote:
> 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 ([^\\]+)
>
apparently n/a to OP problem, but no. That would capture the domain, if
there is one. What we want is the user that follows the \, even if by
some accident there is no domain ahead of 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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Eric Covener <co...@gmail.com>.
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 3:25 PM, Clayton Hicklin <ch...@gmail.com> 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 <ch...@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.
>
> --
> Clayton Hicklin
> chicklin@gmail.com
>
Found this online regex tester, by the way. Could be helpful.
http://www.regextester.com/
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 4:25 PM, André Warnier <aw...@ice-sa.com> wrote:
> Clayton Hicklin wrote:
>
>> On Tue, Sep 16, 2008 at 4:05 PM, André Warnier <aw...@ice-sa.com> wrote:
>>
>> Clayton Hicklin wrote:
>>>
>>> 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.
>>>>
>>>> I think it might not like my (?:...) construct. That's probably
>>>> "extended
>>>>
>>> PCRE" stuff.
>>> Let's try another one :
>>>
>>> RequestHeader edit REMOTE_USER ^([^\\]+\\)?(.+)$ $2
>>>
>>> (hoping that $1 gets set even to '' if there is no domain)
>>> (and yes, the "replacement part" is now $2)
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>> Same error. I wonder, does my Apache need access to a PCRE
>> implementation
>> (i.e. PERL) or is that compiled in? Maybe that's the problem.
>>
>> No, it has nothing to do with perl installed, it should be compiled in.
> But the current on-line documentation for mod_headers has this paragraph :
> edit
> If this request header exists, its value is transformed according to a
> regular expression search-and-replace. The value argument is a regular
> expression, and the replacement is a replacement string, which may contain
> backreferences. Available in version 2.2.4 and later.
>
> So, maybe your version does not quite make the cut ?
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
Apache v 2.2.9 on Windows.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Maybe not directly relevant, but just before I forget, this place has a
lot of information about IE HTTP NTLM authentication (apart from
providing a free Tomcat module to do it too) :
http://jcifs.samba.org/src/docs/ntlmhttpauth.html
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Clayton Hicklin wrote:
> On Tue, Sep 16, 2008 at 4:05 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Clayton Hicklin wrote:
>>
>>> 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 <ch...@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.
>>>
>>> I think it might not like my (?:...) construct. That's probably "extended
>> PCRE" stuff.
>> Let's try another one :
>>
>> RequestHeader edit REMOTE_USER ^([^\\]+\\)?(.+)$ $2
>>
>> (hoping that $1 gets set even to '' if there is no domain)
>> (and yes, the "replacement part" is now $2)
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
> Same error. I wonder, does my Apache need access to a PCRE implementation
> (i.e. PERL) or is that compiled in? Maybe that's the problem.
>
No, it has nothing to do with perl installed, it should be compiled in.
But the current on-line documentation for mod_headers has this paragraph :
edit
If this request header exists, its value is transformed according
to a regular expression search-and-replace. The value argument is a
regular expression, and the replacement is a replacement string, which
may contain backreferences. Available in version 2.2.4 and later.
So, maybe your version does not quite make the cut ?
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 4:05 PM, André Warnier <aw...@ice-sa.com> wrote:
> Clayton Hicklin wrote:
>
>> 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 <ch...@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.
>>
>> I think it might not like my (?:...) construct. That's probably "extended
> PCRE" stuff.
> Let's try another one :
>
> RequestHeader edit REMOTE_USER ^([^\\]+\\)?(.+)$ $2
>
> (hoping that $1 gets set even to '' if there is no domain)
> (and yes, the "replacement part" is now $2)
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
Same error. I wonder, does my Apache need access to a PCRE implementation
(i.e. PERL) or is that compiled in? Maybe that's the problem.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Clayton Hicklin wrote:
> 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 <ch...@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.
>
I think it might not like my (?:...) construct. That's probably
"extended PCRE" stuff.
Let's try another one :
RequestHeader edit REMOTE_USER ^([^\\]+\\)?(.+)$ $2
(hoping that $1 gets set even to '' if there is no domain)
(and yes, the "replacement part" is now $2)
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
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 <ch...@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
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
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 <ch...@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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
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 <ch...@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.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Clayton Hicklin wrote:
> On Tue, Sep 16, 2008 at 2:40 PM, Clayton Hicklin <ch...@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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 2:40 PM, Clayton Hicklin <ch...@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.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
"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
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 1:28 PM, André Warnier <aw...@ice-sa.com> wrote:
> Clayton Hicklin wrote:
>
>> I have LDAP authentication against Active Directory working perfectly in
>> Firefox, but my problem is with IE. IE automatically passes through the
>> username and password so once you are logged into the domain, you don't
>> have
>> to type it in again.
>>
>> That's great, except it is passed through as <domain>\<user>. To do LDAP
>> authentication against Active Directory, I am searching the sAMAccountName
>> attribute of the users. This attribute holds the username for that user,
>> but does not include the <domain>\ prefix, therefore authentication fails
>> in
>> IE and it prompts you for the username and password.
>>
>> As far as I can tell, the <domain>\ prefix is not stored anywhere inside
>> the
>> user object, so there is no way to authenticate with the credentials that
>> IE
>> provides.
>>
>> Has anybody got this working? Is there some sort of workaround or hidden
>> parameter in the Apache LDAP modules that might fix this? Thanks!
>>
>> Hi Clayton.
> There are so many things that might be "happening in IE" that you need to
> be a little more specific for someone to be able to help you.
> Can you provide some more precise details about your setup ? like which
> version of Apache, what module are you using, what the parameters are, etc..
> There are not so many things that can be done at the IE side, but maybe the
> authentication module which you are using on the server side has some
> parameters.
> The fact that IE at first passes the domain\user seems to imply that IE
> thinks it is doing "Windows Integrated Authentication", which can be a good
> or a bad thing. But without some more details, one would not know where to
> start looking.
> Contrary to what you seem to think (or at least what you write), it is not
> in IE that authentication fails, it is at the server level. As a result,
> the server sends a "401 Authorization required" to IE, and that is when IE
> pops up the login dialog.
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
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. This
works using the mod_auth_sspi module (which uses NTLM) but not with 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. 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. 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.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by André Warnier <aw...@ice-sa.com>.
Clayton Hicklin wrote:
> I have LDAP authentication against Active Directory working perfectly in
> Firefox, but my problem is with IE. IE automatically passes through the
> username and password so once you are logged into the domain, you don't have
> to type it in again.
>
> That's great, except it is passed through as <domain>\<user>. To do LDAP
> authentication against Active Directory, I am searching the sAMAccountName
> attribute of the users. This attribute holds the username for that user,
> but does not include the <domain>\ prefix, therefore authentication fails in
> IE and it prompts you for the username and password.
>
> As far as I can tell, the <domain>\ prefix is not stored anywhere inside the
> user object, so there is no way to authenticate with the credentials that IE
> provides.
>
> Has anybody got this working? Is there some sort of workaround or hidden
> parameter in the Apache LDAP modules that might fix this? Thanks!
>
Hi Clayton.
There are so many things that might be "happening in IE" that you need
to be a little more specific for someone to be able to help you.
Can you provide some more precise details about your setup ? like which
version of Apache, what module are you using, what the parameters are, etc..
There are not so many things that can be done at the IE side, but maybe
the authentication module which you are using on the server side has
some parameters.
The fact that IE at first passes the domain\user seems to imply that IE
thinks it is doing "Windows Integrated Authentication", which can be a
good or a bad thing. But without some more details, one would not know
where to start looking.
Contrary to what you seem to think (or at least what you write), it is
not in IE that authentication fails, it is at the server level. As a
result, the server sends a "401 Authorization required" to IE, and that
is when IE pops up the login dialog.
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 1:27 PM, Prasanna Ram Venkatachalam <
vpram86@gmail.com> wrote:
> I guess there is SSPIOmitDomain directive which can be turned Off, to
> include the domain as well along with user name.
>
> (in mod_auth_sspi)
> Regards
> Prasanna Ram
>
>
> On Tue, Sep 16, 2008 at 11:53 PM, Clayton Hicklin <ch...@gmail.com>wrote:
>
>> On Tue, Sep 16, 2008 at 1:22 PM, Clayton Hicklin <ch...@gmail.com>wrote:
>>
>>> On Tue, Sep 16, 2008 at 10:58 AM, Davide Bianchi <da...@onlyforfun.net>wrote:
>>>
>>>> Clayton Hicklin wrote:
>>>> > I have LDAP authentication against Active Directory working perfectly
>>>> in
>>>> > Firefox, but my problem is with IE. IE automatically passes through
>>>> the
>>>> > username and password so once you are logged into the domain, you
>>>> don't
>>>> > have to type it in again.
>>>>
>>>> See if this http://www.soft-land.org/articoli/sso
>>>> can help you out.
>>>>
>>>> Davide
>>>>
>>>> --
>>>> How about some patent on "(a+b)^2 == a^2 + 2ab + b^2"? Choose free
>>>> software!
>>>> -- Laurent Szyster
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>> Thanks for the link. I should've mentioned my Apache server is running
>>> on Windows. I don't think modntlm works on Windows. They suggest using
>>> mod_auth_sspi, which is what I started with, and it worked pretty well, but
>>> it has a weird bug that causes Apache not to send all POST data from forms
>>> unless you wait a few seconds to click submit. Strange, but true. So
>>> that's what led me to LDAP. It is really working well except for this
>>> <domain>\ prefix issue.
>>>
>>> --
>>> Clayton Hicklin
>>> chicklin@gmail.com
>>>
>>
>> Found a workaround for mod_auth_sspi. If you are having troubles with not
>> getting POST data with mod_auth_sspi and Internet Explorer, you can turn on
>> the pre-1.0.4 behavior with:
>>
>> SSPIPerRequestAuth On
>>
>>
>> Still don't know how to handle the IE + LDAP domain prefix issue, but this
>> module will work for me.
>> --
>> Clayton Hicklin
>> chicklin@gmail.com
>>
>
>
>
> --
> Prasanna Ram
>
The setup that works for me with mod_auth_sspi is:
AuthName "blah blah blah"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIPerRequestAuth On
SSPIOfferBasic on
Require group DOMAIN\group1
Require group DOMAIN\group2
Require group DOMAIN\group3
This works for both IE (using NTLM) and Firefox (using BASIC
authentication).
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Prasanna Ram Venkatachalam <vp...@gmail.com>.
I guess there is SSPIOmitDomain directive which can be turned Off, to
include the domain as well along with user name.
(in mod_auth_sspi)
Regards
Prasanna Ram
On Tue, Sep 16, 2008 at 11:53 PM, Clayton Hicklin <ch...@gmail.com>wrote:
> On Tue, Sep 16, 2008 at 1:22 PM, Clayton Hicklin <ch...@gmail.com>wrote:
>
>> On Tue, Sep 16, 2008 at 10:58 AM, Davide Bianchi <da...@onlyforfun.net>wrote:
>>
>>> Clayton Hicklin wrote:
>>> > I have LDAP authentication against Active Directory working perfectly
>>> in
>>> > Firefox, but my problem is with IE. IE automatically passes through
>>> the
>>> > username and password so once you are logged into the domain, you don't
>>> > have to type it in again.
>>>
>>> See if this http://www.soft-land.org/articoli/sso
>>> can help you out.
>>>
>>> Davide
>>>
>>> --
>>> How about some patent on "(a+b)^2 == a^2 + 2ab + b^2"? Choose free
>>> software!
>>> -- Laurent Szyster
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>> Thanks for the link. I should've mentioned my Apache server is running on
>> Windows. I don't think modntlm works on Windows. They suggest using
>> mod_auth_sspi, which is what I started with, and it worked pretty well, but
>> it has a weird bug that causes Apache not to send all POST data from forms
>> unless you wait a few seconds to click submit. Strange, but true. So
>> that's what led me to LDAP. It is really working well except for this
>> <domain>\ prefix issue.
>>
>> --
>> Clayton Hicklin
>> chicklin@gmail.com
>>
>
> Found a workaround for mod_auth_sspi. If you are having troubles with not
> getting POST data with mod_auth_sspi and Internet Explorer, you can turn on
> the pre-1.0.4 behavior with:
>
> SSPIPerRequestAuth On
>
>
> Still don't know how to handle the IE + LDAP domain prefix issue, but this
> module will work for me.
> --
> Clayton Hicklin
> chicklin@gmail.com
>
--
Prasanna Ram
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 1:22 PM, Clayton Hicklin <ch...@gmail.com> wrote:
> On Tue, Sep 16, 2008 at 10:58 AM, Davide Bianchi <da...@onlyforfun.net>wrote:
>
>> Clayton Hicklin wrote:
>> > I have LDAP authentication against Active Directory working perfectly in
>> > Firefox, but my problem is with IE. IE automatically passes through the
>> > username and password so once you are logged into the domain, you don't
>> > have to type it in again.
>>
>> See if this http://www.soft-land.org/articoli/sso
>> can help you out.
>>
>> Davide
>>
>> --
>> How about some patent on "(a+b)^2 == a^2 + 2ab + b^2"? Choose free
>> software!
>> -- Laurent Szyster
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
> Thanks for the link. I should've mentioned my Apache server is running on
> Windows. I don't think modntlm works on Windows. They suggest using
> mod_auth_sspi, which is what I started with, and it worked pretty well, but
> it has a weird bug that causes Apache not to send all POST data from forms
> unless you wait a few seconds to click submit. Strange, but true. So
> that's what led me to LDAP. It is really working well except for this
> <domain>\ prefix issue.
>
> --
> Clayton Hicklin
> chicklin@gmail.com
>
Found a workaround for mod_auth_sspi. If you are having troubles with not
getting POST data with mod_auth_sspi and Internet Explorer, you can turn on
the pre-1.0.4 behavior with:
SSPIPerRequestAuth On
Still don't know how to handle the IE + LDAP domain prefix issue, but this
module will work for me.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 10:58 AM, Davide Bianchi <da...@onlyforfun.net>wrote:
> Clayton Hicklin wrote:
> > I have LDAP authentication against Active Directory working perfectly in
> > Firefox, but my problem is with IE. IE automatically passes through the
> > username and password so once you are logged into the domain, you don't
> > have to type it in again.
>
> See if this http://www.soft-land.org/articoli/sso
> can help you out.
>
> Davide
>
> --
> How about some patent on "(a+b)^2 == a^2 + 2ab + b^2"? Choose free
> software!
> -- Laurent Szyster
>
> ---------------------------------------------------------------------
> 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
>
>
Thanks for the link. I should've mentioned my Apache server is running on
Windows. I don't think modntlm works on Windows. They suggest using
mod_auth_sspi, which is what I started with, and it worked pretty well, but
it has a weird bug that causes Apache not to send all POST data from forms
unless you wait a few seconds to click submit. Strange, but true. So
that's what led me to LDAP. It is really working well except for this
<domain>\ prefix issue.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet
Explorer and Active Directory
Posted by Davide Bianchi <da...@onlyforfun.net>.
Clayton Hicklin wrote:
> I have LDAP authentication against Active Directory working perfectly in
> Firefox, but my problem is with IE. IE automatically passes through the
> username and password so once you are logged into the domain, you don't
> have to type it in again.
See if this http://www.soft-land.org/articoli/sso
can help you out.
Davide
--
How about some patent on "(a+b)^2 == a^2 + 2ab + b^2"? Choose free
software!
-- Laurent Szyster
---------------------------------------------------------------------
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
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Clayton Hicklin <ch...@gmail.com>.
On Tue, Sep 16, 2008 at 11:44 AM, Eric Covener <co...@gmail.com> wrote:
> On Tue, Sep 16, 2008 at 11:40 AM, Clayton Hicklin <ch...@gmail.com>
> wrote:
> > As far as I can tell, the <domain>\ prefix is not stored anywhere inside
> the
> > user object, so there is no way to authenticate with the credentials that
> IE
> > provides.
> >
> > Has anybody got this working? Is there some sort of workaround or hidden
> > parameter in the Apache LDAP modules that might fix this? Thanks!
>
>
> Is there any other header set by IE when it does this automatic
> authentication? Is the password really sent along with it?
>
>
> --
> 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
>
>
I think these credentials are only sent to "trusted" sites as defined by
IE's security settings. This is on an intranet, so it would be considered a
"trusted" site by default.
--
Clayton Hicklin
chicklin@gmail.com
Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Posted by Eric Covener <co...@gmail.com>.
On Tue, Sep 16, 2008 at 11:40 AM, Clayton Hicklin <ch...@gmail.com> wrote:
> As far as I can tell, the <domain>\ prefix is not stored anywhere inside the
> user object, so there is no way to authenticate with the credentials that IE
> provides.
>
> Has anybody got this working? Is there some sort of workaround or hidden
> parameter in the Apache LDAP modules that might fix this? Thanks!
Is there any other header set by IE when it does this automatic
authentication? Is the password really sent along with it?
--
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