On Tue, Sep 16, 2008 at 3:25 PM, Clayton Hicklin <[EMAIL PROTECTED]> 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. > > -- > Clayton Hicklin > [EMAIL PROTECTED] > Found this online regex tester, by the way. Could be helpful. http://www.regextester.com/ -- Clayton Hicklin [EMAIL PROTECTED]
