httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [users@httpd] Pass-through LDAP authentication with Internet Explorer and Active Directory
Date Tue, 16 Sep 2008 21:05:14 GMT
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


Mime
View raw message