On Tue, Sep 16, 2008 at 4:25 PM, André Warnier <[EMAIL PROTECTED]> wrote:
> Clayton Hicklin wrote: > >> On Tue, Sep 16, 2008 at 4:05 PM, André Warnier <[EMAIL PROTECTED]> wrote: >> >> Clayton Hicklin wrote: >>> >>> On Tue, Sep 16, 2008 at 3:35 PM, André Warnier <[EMAIL PROTECTED]> wrote: >>>> >>>> Clayton Hicklin wrote: >>>> >>>>> On Tue, Sep 16, 2008 at 3:11 PM, André Warnier <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> Clayton Hicklin wrote: >>>>>> >>>>>> On Tue, Sep 16, 2008 at 2:40 PM, Clayton Hicklin < >>>>>>> [EMAIL PROTECTED]> >>>>>>> >>>>>>> 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 <[EMAIL PROTECTED]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Clayton Hicklin wrote: >>>>>>>>> >>>>>>>>> On Tue, Sep 16, 2008 at 1:28 PM, André Warnier <[EMAIL PROTECTED]> >>>>>>>>> >>>>>>>>>> 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: [EMAIL PROTECTED] >>>>>>>>>> " from the digest: [EMAIL PROTECTED] >>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Clayton Hicklin >>>>>>>>> [EMAIL PROTECTED] >>>>>>>>> >>>>>>>>> >>>>>>>>> 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: [EMAIL PROTECTED] >>>>>>> " from the digest: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>>> 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: [EMAIL PROTECTED] >>>>> " from the digest: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> 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: [EMAIL PROTECTED] >>> " from the digest: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> 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: [EMAIL PROTECTED] > " from the digest: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Apache v 2.2.9 on Windows. -- Clayton Hicklin [EMAIL PROTECTED]
