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