tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Shaver" <>
Subject RE: jCIFS Jboss Tomcat IIS NTLM Authentication
Date Wed, 26 Oct 2005 19:01:17 GMT
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
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 [] 
> 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 []
> > Gesendet: Mittwoch, 26. Oktober 2005 12:42
> > An: Tomcat Users List;
> > 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:
For additional commands, e-mail:

View raw message