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]
