On Wed, Sep 17, 2008 at 4:56 AM, André Warnier <[EMAIL PROTECTED]> wrote:
> Clayton Hicklin wrote: > >> On Tue, Sep 16, 2008 at 4:21 PM, André Warnier <[EMAIL PROTECTED]> wrote: >> >> I'm beginning to think >>>>> >>>> we're chasing our tails. IE is going to pass the credentials in NTLM >>>> format, I believe. Even if we got the username right, I'm thinking >>>> maybe >>>> the password won't be readable by mod_authn_ldap. I don't know. >>>> >>>> IE can do either of 3 things, as far as I know : >>>> >>> 1) if it is doing Basic authentication, it will pass the user-id and >>> password (as entered by the user in the pop-up login dialog), both merely >>> encoded in a Base64 format. >>> It passes that in a "Authorization:" request header. >>> >>> >> I believe it is basic authorization. The AuthType is set to Basic and the >> AuthBasicProvider (not sure if that's right, I don't have access to it at >> the moment) is set to ldap. So, maybe there is no NTLM involved here. >> The >> user is already authenticated with the domain. My original thought is >> that >> IE sees the site requesting Basic authentication and is supplying the >> domain\user and base64 password. That's why I was hoping to just strip >> out >> the domain\ part. >> >> >> 2) if it is doing Digest authentication, it will pass the user-id and a >>> cryptic "token" based on the user-id and password entered by the user in >>> a >>> pop-up login dialog. The server-side must then somehow verify that this >>> token matches one generated server-side on the base of the user password. >>> It passes that in a "Authorization:" request header. >>> That is anyway not what you want here. >>> >>> >> Nope, not doing digest. >> >> >> 3) if it is doing NTLM authentication, then it will also pass the user-id >>> and a token, but as a result of a multi-step negociation with an >>> appropriate >>> NTLM module on the server, which itself needs to talk to a Windows Domain >>> Controller etc.. >>> At the end of all that, IE will pass the user-id and token to the server >>> with the request, in, I believe, a WWW-authenticate: header. >>> But that token does not contain the password, and IE at no point gets to >>> know the password. >>> >>> >> Seems like it would only do NTLM if I'm using the mod_auth_sspi module. >> The >> more I think about it, the more it doesn't make any sense that IE would >> try >> and do NTLM when Apache is requesting Basic. >> >> >> But maybe do not give up yet. >>> >>> If you are in a Windows Domain, and it is inside a corporate environment, >>> then presumably this REMOTE_USER that IE is sending, is already the >>> result >>> of some secure Domain authentication which happened before. >>> And if so, you might be able to accept it as secure enough, and use its >>> content as a user-id. >>> The whole point now is to know whether you really need to know the user >>> password, or if the mere fact of verifying that the user indeed exists in >>> the LDAP system is enough (and maybe not even that). >>> It all depends if you want to provide a reall secure login system, or if >>> your purpose is to provide a user-friendly SSO mechanism for Apache >>> applications. >>> >>> >> Well, I need to do group authentication via LDAP, and the LDAP module >> binds >> with the DN it looks up using the username provided by the browser. It >> definitely needs the password. >> >> >> One item just to clear up a lingering doubt : when you show the user-id >>> that auth_ldap is dumping to the logfile, was that the result of a popup >>> login dialog in IE, or was there no such popup dialog involved ? >>> >>> >>> Not the result of the popup, that was IE trying to send the credentials >> automatically. >> >> That is what I really do not understand here : > 1) the first time IE tries to access the URL, it does not send an HTTP > authentication header, because it does not even know that the URL requires > authentication. > 2) then the server sends him back a "401 authentication required", along > with the type of authentication. And let's say it is "Basic". > 3) then it would seem that IE automatically sends the "user\domain", and > the user password, encoded in a "Basic" authorisation header. > I believe this is what's happening, yes. > > That last part #3 seems extremely unlikely to me, for several reasons : > - first, it supposes that IE already knows the user's password. I don't > see how it would. Even if the user has already authenticated to the Windows > Domain : > a) the NTLM authentication never "circulates" the user's password on the > network, only encrypted tokens that depend, in part, on the user password. > b) it would mean that any server that sent a "401, Basic" response to IE, > would receive the user's password in return, in clear. That seems like such > a big security hole that I don't believe it. > (If it is true, then this is going to give some nightmares to a few hundred > thousand network administrators worldwide). > Not exactly. IE will only send the credentials to "trusted" sites, which in the default setup is means servers on the same subnet. Otherwise, a site is considered "untrusted" and IE will not automatically sign on. This is how "Windows Integrated Authentication" works, according to what I've read. IE is clearly passing 'domain\username' but I don't have any idea what password it is sending. Maybe the Base64 encoded password, but who knows. > > So, there *must* be something else going on here. > > (I can still imagine that somehow IE would send the "domain\userid", > although even that I don't really understand). > > On a separate level : > > To get some user information using LDAP, you do not necessarily need that > specific user's password. It should be possible to get information about a > user, by using some special login user-id/password (always the same) to > connect to the LDAP server , and be allowed at least to read the "public" > part of other user's records (not their password e.g., but their group > memberships probably yes). If that was not possible, then an LDAP server > would not be useful as a directory back-end, which is their principal > function. > mod_authnz_ldap requires either the ability to bind anonymously, or you can specify a DN and password to bind with for the initial search phase (i.e. when it looks up the username supplied by the client). Once that user is found, it re-binds to the directory using that user's credentials. At that point, it will check the requirements you've set up (require valid-user, require ldap-group, etc....). > > I am sorry, but my own circumstances are such that I am not working within > a Windows domain, so I can just not test this easily. > When I do such kind of work, I also tend to do it on-site, at the customer > for which it is needed, so that I am sure that I am in exactly the right > context. > > > André > > --------------------------------------------------------------------- > 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] > > After doing some more reading, I really think this isn't going to work how I want. Unless we can somehow modify the 'domain\username' that IE is sending before it is processed by the auth modules, and unless it is sending the password in Base64 format (which we don't really know), it's just not going to work. I have mod_auth_sspi working, but only because I'm running Apache on Windows. The other option is Kerberos authentication with mod_auth_kerb. It is not part of the standard Apache distribution, but I think this is going to be your best bet if you're running on Linux. -- Clayton Hicklin [EMAIL PROTECTED]
