This is a quote from a microsoft waeb site: Windows NT Challenge/Response authentication (often called NTLM authentication) is the most secure form of authenticating a user because the username and password are not sent across the wire. Rather, the Windows Security Provider interface is used to provide an encrypted challenge/response handshake mechanism that is functionally unbreakable. The Windows security provider interface allows IIS to validate and impersonate the user. Unlike Basic authentication, NTLM authentication does not prompt users for their user name and password by default. The current Windows user account on the client machine is used for the NTLM authentication. Then, if this fails, it will prompt the user for the username and password to be used. If NTLM authentication succeeds, the requested application or resource is executed in the context of the specified user.
Because of the one way encryption is used, NTLM authentication validates the user for IIS without providing knowledge of the user's password to IIS. Therefore, a full set of username and password credentials is not available to IIS for doing such tasks as mapping a network drive. If an ISAPI application calls WNetAddConnection2 without specifying a username and password, it will fail under NTLM authentication. This is from another site: The NTLM version of Integrated Windows authentication is similar to Digest authentication in that it is a challenge/response mechanism where the challenge is a nonce provided by the server to the client. A major difference is that it does not require passwords to be stored in reversibly encrypted form in the Active Directory on the Domain Controller. This as a significant server-side security advantage over Digest authentication. This is accomplished because the client, instead of creating a digest directly from the user's password and the nonce, first creates (but does not store) a hash of that password that is identical to the NTLM hash of the password that is stored in Active Directory on the Domain Controller. The client then uses the password hash and the nonce to build the digest response. Thus the server side of the transaction does not need access to the client's original (clear text) password in order to recompute the digest and verify that the client has knowledge of the password. Integrated Windows authentication will also work with much older versions of IE (as old as 3.01). However, unlike Digest authentication, NTLM is not firewall or proxy friendly (a culprit here is need for multiple round trips over an open connection), nor does it support delegation of security credentials, once established, to other servers such as SQL (double-hop impersonations). I guess people think it might not be secure because you could grab the password hash and throw a dictionary attack at it. (no disclaimer) > -----Original Message----- > From: Bernhard Slominski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 26, 2005 6:04 AM > To: 'Tomcat Users List' > Subject: AW: jCIFS Jboss Tomcat IIS NTLM Authentication > > A short follow up question here which is not Tomcat related: > When you use request.getRemoteUser() to do your > authentication it is very unsecure isn't it: > You just can send your "bad" HTTP request which containts the > administrator name as the remote user HTTP header field and > your authenticated as administrator without any password. > Am I right here, does SSL ssolve this problem? > > > -----Ursprungliche Nachricht----- > > Von: Allistair Crossley [mailto:[EMAIL PROTECTED] > > Gesendet: Mittwoch, 26. Oktober 2005 12:42 > > An: Tomcat Users List; tomcat-user@jakarta.apache.org > > Betreff: RE: jCIFS Jboss Tomcat IIS NTLM Authentication > > > > > > if you're using IIS in front of your application you don't > need to use > > jCIFs. All you do is set the directory permissions on your > website to > > Integrated Windows Authentication, then configure your Tomcat AJP > > Connector element with tomcatAuthentication="false". Then > > request.getRemoteUser() will return the Windows username. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
