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