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. -- Clayton Hicklin [EMAIL PROTECTED]
