[jcifs] NtlmHttpFilter authentication failure

Klaus Steffan klaus.steffan at wugnet.de
Fri Jul 21 07:19:01 GMT 2006


Hi Mike,

the loadbalancer in our environment sends all requests of a 
client to the same server, i.e. the server where the http-session
was created. So the cluster is probably not the reason for the 
authentication failure.

If the authentication of a user fails with 
"0xC0000022: jcifs.smb.SmbAuthException: Access is denied."
then there is another exception in the logfile which indicates that
the connection to the DC was closed:
R close: NbtSocket[addr=DOMDIBACORP<1C>/XX.XX.XX.XX,port=139,localport=61792]
R Socket closed: DOMAIN<1C>/XX.XX.XX2.XX
R java.net.SocketException: Socket closed
R 	at java.net.SocketInputStream.socketRead0(Native Method)
R 	at java.net.SocketInputStream.read(SocketInputStream.java:129)
R 	at
jcifs.netbios.SessionServicePacket.readPacketType(SessionServicePacket.java:68)
R 	at jcifs.netbios.SocketInputStream.read(SocketInputStream.java:74)
R 	at jcifs.netbios.SocketInputStream.read(SocketInputStream.java:40)
R 	at java.io.FilterInputStream.read(FilterInputStream.java:66)
R 	at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
R 	at jcifs.smb.SmbTransport.run(SmbTransport.java:388)
R 	at java.lang.Thread.run(Thread.java:534) 

When the same user then immediatly reloads the page with F5, the
authenication succeeds. In the logfile you can see that there is
an additional DC request which is not done in the failure case:

SystemErr     R interrogate: dc=DOMAIN<1C>/XX.XX.XX.XX
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
SystemErr     R
SmbComNegotiate[command=SMB_COM_NEGOTIATE,received=false,errorCode=0,flags=0x001
8,flags2=0xC003,signSeq=0,tid=0,pid=24336,uid=0,mid=11,wordCount=0,byteCount=12,
wordCount=0,dialects=NT LM 0.12]
SystemErr     R 00000: FF 53 4D 42 72 00 00 00 00 18 03 C0 00 00 00 00 
|ÿSMBr......À....|
SystemErr     R 
SystemErr     R New data read: Transport1[DOMAIN<1C>/XX.XX.XX.XX:0]
SystemErr     R 00000: FF 53 4D 42 72 00 00 00 00 98 03 C0 00 00 00 00 
|ÿSMBr......À....|
00010: 00 00 00 00 00 00 00 00 00 00 10 5F 00 00 0B 00  |..........._....|
SystemErr     R 
SystemErr     R byteCount=54 but readBytesWireFormat returned 30
SystemErr     R
SmbComNegotiateResponse[command=SMB_COM_NEGOTIATE,received=false,errorCode=0,fla
gs=0x0098,flags2=0xC003,signSeq=0,tid=0,pid=24336,uid=0,mid=11,wordCount=17,byte
Count=54,wordCount=17,dialectIndex=0,securityMode=0xF,security=user,encryptedPas
swords=true,maxMpxCount=50,maxNumberVcs=1,maxBufferSize=16644,maxRawSize=65536,s
essionKey=0x00000000,capabilities=0x0001F3FD,serverTime=Tue Apr 25 09:05:38
CEST
2006,serverTimeZone=65416,encryptionKeyLength=8,byteCount=54,encryptionKey=0x752
43E5D473D92A0,oemDomainName=DOMAIN]
SystemErr     R 00000: FF 53 4D 42 72 00 00 00 00 98 03 C0 00 00 00 00 
|ÿSMBr......À....|
00010: 00 00 00 00 00 00 00 00 00 00 10 5F 00 00 0B 00  |..........._....|
00020: 11 00 00 0F 32 00 01 00 04 41 00 00 00 00 01     |....2....A..... |
SystemErr     R 
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Klaus

> The NTLM HTTP Filter doesn't work in a cluster environment because the
> NTLM protocol is a multi step handshake so if the first step goes to
> one server and a subsequent step goes to a differnet one the handshake
> will fail.
> 
> The only way to resolve the problem is to somehow direct clients to go
> back to the server with which they first communicated with.
> 
> There have been other discussions about how to remedy this problem such
> as directing clients to one server just to log in.
> 
> Mike
> 
> On Thu, 20 Jul 2006 08:25:51 +0200
> Klaus Steffan <klaus.steffan at wugnet.de> wrote:
> 
> > Hello,
> > 
> > I am using the NtlmHttpFilter (jcifs 1.1.8), the intranet web-application
>  is
> > running on a WebSphere Application Server cluster on Solaris, the Domain
> > Controllers (jcifs.http.loadBalance=true) are Windows 2003 Server. Sess
> ion
> > tracking is done with cookies, requests from the same client go to the sa
> me
> > server.
> > 
> > The problem is that the authentication randomly fails for any user. A user
> > can authentication one time, and the next time the authentication fails w
> ith
> >      NtlmHttpFilter: DOMAIN\12345678: 0xC0000022: jcifs.smb.SmbAuthExcept
> ion:
> > Access is denied.
> > 
> > In the test environment everything works fine (usually) and the authentic
> ation
> > succeeds. The authentication in the live system (same application, users,
> > server OS, domain controller) regularly fails with "Access is denied" for
> > almost all users for the first time. When the users then reloads the page
>  (F5)
> > the authentication is usually successful.
> > 
> > When we use the current jcifs version (1.2.9), the password dialog pops u
> p in
> > the failure case (401: Unauthorized); the authentication then always fail
> s,
> > even the user enters the correct credentials. The only solution is to clo
> se 
> > and restart the browser.
> > 
> > We can´t see any error info in the domain controller server.
> > The authentication problem occured the first time after installing a 
> > Microsoft patch on the domain controllers.
> > 
> > We use the following filter params:
> >  <filter>
> >     <filter-name>ntlm</filter-name>
> >     <filter-class>jcifs.http.NtlmHttpFilter</filter-class>
> >     <init-param>
> >     	<param-name>jcifs.smb.client.domain</param-name>
> >         <param-value>DOMAIN</param-value>
> >     </init-param>
> >     <init-param>
> > 	<param-name>jcifs.netbios.wins</param-name>
> >         <param-value>swdc01,swdc02,swdc03,swdc04</param-value>
> >     </init-param>
> >     <init-param>
> > 	<param-name>jcifs.http.loadBalance</param-name>
> >         <param-value>true</param-value>
> >     </init-param>
> >     <init-param>
> >         <param-name>jcifs.smb.client.ssnLimit</param-name>
> >         <param-value>1000</param-value>
> >     </init-param>
> >     <init-param>
> >         <param-name>jcifs.util.loglevel</param-name>
> >   	<param-value>2</param-value>
> >     </init-param>
> >   </filter>
> > 
> > 
> > I´ve read the postings and tried the following tips to resolve the prob
> lem, 
> > but none helped: 
> > 
> > 1. Upgrading to JCIFS 1.2.9: same behaviour.
> > 2. Preauthentication: define a username and password didn´t have any
> > affect. 
> > 3. Setting ssnLimit to 1: all (!) authentication attempts failed with
> > "Access is denied". 
> > 
> > Attached you´ll find logfiles for both a successful and
> > a failed authentication.
> > 
> > Btw: Another web-application which also uses the same jcifs filter with 
> > dentical params (and identical environment: Domain Controller...) doesn
> =B4t 
> > have any problems. 
> > 
> > Does anyone have an idea whats wrong ? 
> > Any help would be appreciated.
> > 
> > Klaus
> > 
> > -- 
> > 
> 
> 
> -- 
> Michael B Allen
> PHP Extension for SSO w/ Windows Group Authorization
> http://www.ioplex.com/
> 



More information about the jcifs mailing list