|
»
»
NTLM usrname/password failure after each 5 mins
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
NTLM usrname/password failure after each 5 mins
by Alexandr Podoplelov
::
Rate this Message:
Dear JCIFS experts!
Maybe somebody met already the problem which I face now. Please, share any ideas you may have! I configured JCIFS with Tomcat 5.5 and it works perfectly except one thing. After each 5 minutes while stress test (10 logins/sec) I get an error about bad username/password (AD authorization failure) . It is strange since names and passwords are transferred by Internet Explorer while handshaking with JCIFS. I cannot imagine that after every approx. 5 minutes IE sends wrong passwords. The filter configuration is this one: <filter> <filter-name>ntlm</filter-name> <filter-class>jcifs.http.NtlmHttpFilter</filter-class> <init-param> <param-name>jcifs.http.domainController</param-name> <param-value>bee.vimpelcom.ru</param-value> </init-param> <init-param> <param-name>jcifs.smb.client.domain</param-name> <param-value>Domain</param-value> </init-param> <init-param> <param-name>jcifs.smb.client.username </param-name> <param-value>UserOne</param-value> </init-param> <init-param> <param-name>jcifs.smb.client.password</param-name> <param-value>ThePassword</param-value> </init-param> <init-param> <param-name>jcifs.smb.lmCompatibility</param-name> <param-value>3</param-value> </init-param> <init-param> <param-name>jcifs.util.loglevel</param-name> <param-value>3</param-value> </init-param> </filter> <filter-mapping> <url-pattern>/*</url-pattern> <filter-name>ntlm</filter-name> </filter-mapping> Please, share any adeas how to fix this problem? Or which way to investigate it. Thank you. //Alexander |
|
|
Re: NTLM usrname/password failure after each 5 mins
by Michael B Allen-4
::
Rate this Message:
Is there an exception in the log?
It could be that the connection to the DC is getting closed in the middle of a negotiation. I don't know why it would get closed but because NTLM is a multistep handshake, if client is provided with the server challenge and then the connection closes the challenge will become invalid. When IE submits the password hashes the DC on the new connection will reject them. We could detect when the challenge no longer matches the transport (actually I think we do that already) and resend the WWW-Authenticate: NTLM but that will cause the network password dialog to come up so same difference. So if that's really what's happening theres no way to fix the problem. You might try to investigate *why* the connection is being closed and try to stop it. Mike On Tue, 18 Jul 2006 20:31:02 +0400 "Alexandr Podoplelov" <alepod@...> wrote: > Dear JCIFS experts! > > Maybe somebody met already the problem which I face now. Please, share any > ideas you may have! > > I configured JCIFS with Tomcat 5.5 and it works perfectly except one thing. > After each 5 minutes while stress test (10 logins/sec) I get an error about > bad username/password (AD authorization failure) . It is strange since names > and passwords are transferred by Internet Explorer while handshaking with > JCIFS. I cannot imagine that after every approx. 5 minutes IE sends wrong > passwords. > The filter configuration is this one: > > <filter> > <filter-name>ntlm</filter-name> > <filter-class>jcifs.http.NtlmHttpFilter</filter-class> > > <init-param> > <param-name>jcifs.http.domainController</param-name> > <param-value>bee.vimpelcom.ru</param-value> > </init-param> > > <init-param> > <param-name>jcifs.smb.client.domain</param-name> > <param-value>Domain</param-value> > </init-param> > > <init-param> > <param-name>jcifs.smb.client.username</param-name> > <param-value>UserOne</param-value> > </init-param> > > <init-param> > <param-name>jcifs.smb.client.password</param-name> > <param-value>ThePassword</param-value> > </init-param> > > <init-param> > <param-name>jcifs.smb.lmCompatibility</param-name> > <param-value>3</param-value> > </init-param> > > <init-param> > <param-name>jcifs.util.loglevel</param-name> > <param-value>3</param-value> > </init-param> > </filter> > > <filter-mapping> > <url-pattern>/*</url-pattern> > <filter-name>ntlm</filter-name> > </filter-mapping> > > > Please, share any adeas how to fix this problem? Or which way to investigate > it. Thank you. > //Alexander > -- Michael B Allen PHP Extension for SSO w/ Windows Group Authorization http://www.ioplex.com/ |
|
|
RE: NTLM usrname/password failure after each 5 mins
by Tapperson Kevin
::
Rate this Message:
We have experienced issues with transports being closed in the middle of
the multi-step handshake process. We implemented some basic reference counting in the SmbSession and SmbTransport classes to alleviate this. Following is the diff of the changes we made to support this. Sorry I don't have a more up-to-date diff; we are still using 1.1.11. I'm not sure how applicable this diff is to the current version of jcifs, but the implementation should be similar. C:\jcifs>diff jcifs_1.1.11_modified\src\jcifs\smb\SmbSession.java jcifs_1.1.11\src\jcifs\smb\SmbSession.java 84d83 < trans.incrementReferenceCount(); 138d136 < trans.incrementReferenceCount(); 160,169c158,163 < try { < if( LOGON_SHARE == null ) { < tree.treeConnect( null, null ); < } else { < Trans2FindFirst2 req = new Trans2FindFirst2( "\\", "*", SmbFile.ATTR_DIRECTORY ); < Trans2FindFirst2Response resp = new Trans2FindFirst2Response(); < tree.sendTransaction( req, resp ); < } < } finally { < tree.session.transport.decrementReferenceCount(); --- > if( LOGON_SHARE == null ) { > tree.treeConnect( null, null ); > } else { > Trans2FindFirst2 req = new Trans2FindFirst2( "\\", "*", SmbFile.ATTR_DIRECTORY ); > Trans2FindFirst2Response resp = new Trans2FindFirst2Response(); > tree.sendTransaction( req, resp ); C:\jcifs>diff jcifs_1.1.11_modified\src\jcifs\smb\SmbTransport.java jcifs_1.1.11\src\jcifs\smb\SmbTransport.java 125,126d124 < private int refCount = 0; < 508,513c506 < if( refCount == 0 ) { < tryClose( false ); < } else if( log.level > 1 ) { < log.println( "soTimeout has occured but there are " + < refCount + " references to this transport socket" ); < } --- > tryClose( false ); 531,538d523 < synchronized void incrementReferenceCount() { < refCount++; < } < < synchronized void decrementReferenceCount() { < refCount--; < } < -----Original Message----- From: jcifs-bounces+kevin.tapperson=hcahealthcare.com@... [mailto:jcifs-bounces+kevin.tapperson=hcahealthcare.com@...] On Behalf Of Michael B Allen Sent: Tuesday, July 18, 2006 1:56 PM To: Alexandr Podoplelov Cc: jcifs@... Subject: Re: [jcifs] NTLM usrname/password failure after each 5 mins Is there an exception in the log? It could be that the connection to the DC is getting closed in the middle of a negotiation. I don't know why it would get closed but because NTLM is a multistep handshake, if client is provided with the server challenge and then the connection closes the challenge will become invalid. When IE submits the password hashes the DC on the new connection will reject them. We could detect when the challenge no longer matches the transport (actually I think we do that already) and resend the WWW-Authenticate: NTLM but that will cause the network password dialog to come up so same difference. So if that's really what's happening theres no way to fix the problem. You might try to investigate *why* the connection is being closed and try to stop it. Mike On Tue, 18 Jul 2006 20:31:02 +0400 "Alexandr Podoplelov" <alepod@...> wrote: > Dear JCIFS experts! > > Maybe somebody met already the problem which I face now. Please, share > any ideas you may have! > > I configured JCIFS with Tomcat 5.5 and it works perfectly except one thing. > After each 5 minutes while stress test (10 logins/sec) I get an error > about bad username/password (AD authorization failure) . It is strange > since names and passwords are transferred by Internet Explorer while > handshaking with JCIFS. I cannot imagine that after every approx. 5 > minutes IE sends wrong passwords. > The filter configuration is this one: > > <filter> > <filter-name>ntlm</filter-name> > <filter-class>jcifs.http.NtlmHttpFilter</filter-class> > > <init-param> > <param-name>jcifs.http.domainController</param-name> > <param-value>bee.vimpelcom.ru</param-value> > </init-param> > > <init-param> > <param-name>jcifs.smb.client.domain</param-name> > <param-value>Domain</param-value> > </init-param> > > <init-param> > <param-name>jcifs.smb.client.username</param-name> > <param-value>UserOne</param-value> > </init-param> > > <init-param> > <param-name>jcifs.smb.client.password</param-name> > <param-value>ThePassword</param-value> > </init-param> > > <init-param> > <param-name>jcifs.smb.lmCompatibility</param-name> > <param-value>3</param-value> > </init-param> > > <init-param> > <param-name>jcifs.util.loglevel</param-name> > <param-value>3</param-value> > </init-param> > </filter> > > <filter-mapping> > <url-pattern>/*</url-pattern> > <filter-name>ntlm</filter-name> > </filter-mapping> > > > Please, share any adeas how to fix this problem? Or which way to > investigate it. Thank you. > //Alexander > -- Michael B Allen PHP Extension for SSO w/ Windows Group Authorization http://www.ioplex.com/ |
|
|
Re: NTLM usrname/password failure after each 5 mins
by Michael B Allen-4
::
Rate this Message:
Refcounting basically just forces the transport to stay open in which
case you might as well just make the soTimeout some huge value like 10 hours. As long as a new session was created every 10 hours causing communication with DC it will never close (unless the DC closes it). I doubt Alepods problem is the jcifs.smb.client.soTimeout value though because the test script would have to use the cache cred in the HTTP session for the DC transport to be idle long enough and timeout. But if that were true he wouldn't get the error in the first place because the cached cred would bypass any further authentications. If the container is expiring sessions every 5 minutes that might change the diagnosis so hard to tell ... Mike On Tue, 18 Jul 2006 16:35:07 -0500 "Tapperson Kevin" <Kevin.Tapperson@...> wrote: > We have experienced issues with transports being closed in the middle of > the multi-step handshake process. We implemented some basic reference > counting in the SmbSession and SmbTransport classes to alleviate this. -- Michael B Allen PHP Extension for SSO w/ Windows Group Authorization http://www.ioplex.com/ |
|
|
Re: NTLM usrname/password failure after each 5 mins
by Alexandr Podoplelov
::
Rate this Message:
Hi Michael,
Here the log fragment comes: NtlmHttpFilter: VIMPELCOM_MAIN\KASS08_User_MS successfully authenticated against bee.vimpelcom.ru/172.26.200.160 NtlmHttpFilter: VIMPELCOM_MAIN\KASS08_User_MS successfully authenticated against bee.vimpelcom.ru/172.26.200.160 NtlmHttpFilter: VIMPELCOM_MAIN\KASS05_User_MS successfully authenticated against bee.vimpelcom.ru/172.26.200.160 NtlmHttpFilter: VIMPELCOM_MAIN\KASS05_User_MS successfully authenticated against bee.vimpelcom.ru/172.26.200.160 treeConnect: unc=\\bee.vimpelcom.ru\IPC$,service=IPC sessionSetup: accountName=KASS01_User_MS,primaryDomain=VIMPELCOM_MAIN update: 0 0:16 00000: CF E5 5D 07 F3 A3 F7 A5 ED 03 D5 11 99 84 81 05 |??].?????.?.....| update: 1 4:258 00000: FF 53 4D 42 73 00 00 00 00 18 07 C0 00 00 60 00 |?SMBs......?..`.| 00010: 00 00 00 00 00 00 00 00 00 00 CC 29 00 00 4B 00 |..........?)..K.| 00020: 0D 75 00 C2 00 04 41 0A 00 01 00 00 00 00 00 18 |.u.?..A.........| 00030: 00 18 00 00 00 00 00 54 10 00 00 85 00 17 A9 99 |.......T......?.| 00040: 96 8F 77 41 DF 74 7D EA 13 0B 5A 40 1D 2B 27 66 |..wA?t}?..Z@.+'f| 00050: BE C4 78 2A 74 98 B6 73 9E 62 D7 7A 05 C4 C0 2C |??x*t.?s.b?z.??,| 00060: 48 4E 12 A0 26 BB BA 12 CD A6 8F 82 8B 00 4B 00 |HN.?&??.??....K.| 00070: 41 00 53 00 53 00 30 00 31 00 5F 00 55 00 73 00 |A.S.S.0.1._.U.s.| 00080: 65 00 72 00 5F 00 4D 00 53 00 00 00 56 00 49 00 |e.r._.M.S...V.I.| 00090: 4D 00 50 00 45 00 4C 00 43 00 4F 00 4D 00 5F 00 |M.P.E.L.C.O.M._.| 000A0: 4D 00 41 00 49 00 4E 00 00 00 53 00 75 00 6E 00 |M.A.I.N...S.u.n.| 000B0: 4F 00 53 00 00 00 6A 00 43 00 49 00 46 00 53 00 |O.S...j.C.I.F.S.| 000C0: 00 00 04 FF 00 00 00 00 00 01 00 35 00 00 5C 00 |...?.......5..\.| 000D0: 5C 00 62 00 65 00 65 00 2E 00 76 00 69 00 6D 00 |\.b.e.e...v.i.m.| 000E0: 70 00 65 00 6C 00 63 00 6F 00 6D 00 2E 00 72 00 |p.e.l.c.o.m...r.| 000F0: 75 00 5C 00 49 00 50 00 43 00 24 00 00 00 49 50 |u.\.I.P.C.$...IP| digest: 00000: BD 62 F2 35 F1 21 D4 48 C3 EA 06 3A 0C 58 CF 0C |?b?5?!?H??.:.X?.| SmbComSessionSetupAndX[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC007,signSeq=96,tid=0,pid=10700,uid=0,mid=75,wordCount=13,byteCount=133,andxCommand=0x75,andxOffset=194,snd_buf_size=16644,maxMpxCount=10,VC_NUMBER=1,sessionKey=0,passwordLength=24,unicodePasswordLength=24,capabilities=4180,accountName=KASS01_User_MS,primaryDomain=VIMPELCOM_MAIN,NATIVE_OS=SunOS,NATIVE_LANMAN=jCIFS] SmbComTreeConnectAndX[command=SMB_COM_TREE_CONNECT_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0x0000,signSeq=0,tid=0,pid=10700,uid=0,mid=0,wordCount=4,byteCount=53,andxCommand=0xFF,andxOffset=0,disconnectTid=false,passwordLength=1,password=,path=\\bee.vimpelcom.ru\IPC$,service=IPC] New data read: Transport1[bee.vimpelcom.ru/172.26.200.160:0] 00000: FF 53 4D 42 73 6D 00 00 C0 98 07 C0 00 00 3A 0B |?SMBsm..?..?..:.| 00010: F6 17 D7 EA 8C 38 00 00 00 00 CC 29 00 00 4B 00 |?.??.8....?)..K.| SmbComSessionSetupAndXResponse[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=Logon failure: unknown user name or bad password.,flags=0x0098,flags2=0xC007,signSeq=97,tid=0,pid=10700,uid=0,mid=75,wordCount=0,byteCount=0,andxCommand=0xFF,andxOffset=0,isLoggedInAsGuest=false,nativeOs=,nativeLanMan=,primaryDomain=] NtlmHttpFilter: VIMPELCOM_MAIN\KASS01_User_MS: 0xC000006D: jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password. NtlmHttpFilter: VIMPELCOM_MAIN\KASS03_User_MS successfully authenticated against bee.vimpelcom.ru/172.26.200.160 NtlmHttpFilter: VIMPELCOM_MAIN\KASS03_User_MS successfully authenticated against bee.vimpelcom.ru/172.26.200.160 NtlmHttpFilter: VIMPELCOM_MAIN\KASS07_User_MS successfully authenticated against bee.vimpelcom.ru/172.26.200.160 I will try Kevin's suggestion to change the code of SmbSession.java (thank you, Kevin), and come back with the results. //Alexander 2006/7/18, Michael B Allen <
mba2000@...>: Is there an exception in the log? |
|
|
Re: NTLM usrname/password failure after each 5 mins
by Michael B Allen-4
::
Rate this Message:
This just shows the reconnect. It doesn't show the disconnect. Is there
anything interesting that happends before this? On Wed, 19 Jul 2006 11:06:10 +0400 "Alexandr Podoplelov" <alepod@...> wrote: > Hi Michael, > Here the log fragment comes: > > NtlmHttpFilter: VIMPELCOM_MAIN\KASS08_User_MS successfully authenticated > against bee.vimpelcom.ru/172.26.200.160 > NtlmHttpFilter: VIMPELCOM_MAIN\KASS08_User_MS successfully authenticated > against bee.vimpelcom.ru/172.26.200.160 > NtlmHttpFilter: VIMPELCOM_MAIN\KASS05_User_MS successfully authenticated > against bee.vimpelcom.ru/172.26.200.160 > NtlmHttpFilter: VIMPELCOM_MAIN\KASS05_User_MS successfully authenticated > against bee.vimpelcom.ru/172.26.200.160 > treeConnect: unc=\\bee.vimpelcom.ru\IPC$,service=IPC > sessionSetup: accountName=KASS01_User_MS,primaryDomain=VIMPELCOM_MAIN > update: 0 0:16 > 00000: CF E5 5D 07 F3 A3 F7 A5 ED 03 D5 11 99 84 81 05 |??].?????.?.....| > > update: 1 4:258 > 00000: FF 53 4D 42 73 00 00 00 00 18 07 C0 00 00 60 00 |?SMBs......?..`.| > 00010: 00 00 00 00 00 00 00 00 00 00 CC 29 00 00 4B 00 |..........?)..K.| |
|
|
|
|
|
Re: NTLM usrname/password failure after each 5 mins
by AsafM
() ::
Rate this Message:
Hi all,
I'm reviving a 2 years old topic, regarding load testing. You can take a look at the entire thread of the discussion here I'll start with a quick summary, and then shed lots of details to make it clearer: After the transport disconnects (due to socket timeout) and connects, the first 10 , or so, attempts to authenticate against the DC fails on bad username/password. After those failures, all attempts succeeds. I've gained some knowledge I'll now share, but I'm still missing some key elements to figuring this out. Load Testing Setup 110 threads, consistently accessing a protected resource on Tomcat, which requires an NTLM authentication. Each thread is using one user. For example: Thread-34 is logging in as user TEST34. The turn of events 1. The first thread accessing the resource, setups the session (SmbSession.sessionSetup()), which blocks all other threads, since each thread (user) requires to setup a session of its own. The session setup runs the Transport.connect(), creates a tree for the default user (to enable SMB signing), and send the SmbComSessionSetupAndX to the DC, for authentication. 2. Once the 1st session setup is done, all other threads follows, each creating its own session, attached to one transport object (Transport-1 thread). 3. On the second iteration of the test threads, there's no need for session setup. The session object is retrieved from the transport (it's cached there). This usage of cache causes the lack of usage in the transport socket. 4. After soTimeout (jcifs constant of 5 min), the loop() method of Transport receives a SocketTimeoutException, and calls Transport.disconnect() which in turn calls SmbTransport.doDisconnect(). 5. The doDisconnect() logs off all sessions attached to the transport object, closes down the socket and finally resets the digest property, which is used to sign each request sent to the DC (this is set in the first sessionSetup in SmbSession). ** First Problem** While disconnects logs-off sessions, other threads were using them, and acting as-if the transport is connected. I've bypassed this issue, by: a) Setting the Transport.state to 0 in the Transport.disconnect() function. This causes the Transport.connect() to actually connect. b) Adding a synchronize (this) block on both disconnect() and connect() methods, which prevents running connect() while disconnect() is commencing. 6. While disconnect() was running, all other threads were waiting in queue, to run transport.connect(), in the SmbTree.treeConnect() method. Once the disconnect finished, each thread in its turn, ran the connect and cotinued for creating a session by running SmbSession.sessionSetup(). Since that function is syncrhonized on transport(), sessions were created once at a time, for each thread. 7. The first session to run the setup, identified that the transport.digest was empty (due to SmbTransport.doDisconnect()), thus ran treeConnect on the default username, used for SMB signing. Once that was finished successfully, it sent the SmbComSessionSetupAndX for the user it was trying to authenticate. It failed in the DC. SmbComSessionSetupAndXResponse returned with an error code: Logon failure: unknown user name or bad password 8. Allot of threads after the first thread inline, failed also on the exact spot in the sessionSetup(). 9. From some magical reason, which I'm yet to figure out, after 10 or so failures, the DC started returning success in the SmbComSessionSetupAndXResponse. Log File Here's the log file. Please ignore some lines that are not related jCIFS. They are part of our tested web application. This is after the socket timeout occurs: 2008-06-12 16:00:37,702 373674 ERROR [STDERR] (Transport1:) SmbComTreeDisconnect[command=SMB_COM_TREE_DISCONNECT,received=false,errorCode=0,flags=0x0018,flags2=0xC007,signSeq=220,tid=2061,pid=2761,uid=2061,mid=0,wordCount=0,byteCount=0] 2008-06-12 16:00:37,717 373689 ERROR [STDERR] (Transport1:) SmbComLogoffAndX[command=SMB_COM_LOGOFF_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC007,signSeq=222,tid=0,pid=2761,uid=2061,mid=0,wordCount=2,byteCount=0,andxCommand=0xFF,andxOffset=0] 2008-06-12 16:00:37,717 373689 ERROR [STDERR] (Transport1:) SmbComTreeDisconnect[command=SMB_COM_TREE_DISCONNECT,received=false,errorCode=0,flags=0x0018,flags2=0xC007,signSeq=224,tid=2062,pid=2761,uid=2062,mid=0,wordCount=0,byteCount=0] 2008-06-12 16:00:38,874 374846 ERROR [STDERR] (Transport1:) SmbComNegotiate[command=SMB_COM_NEGOTIATE,received=false,errorCode=0,flags=0x0018,flags2=0xC003,signSeq=0,tid=0,pid=2761,uid=0,mid=112,wordCount=0,byteCount=12,wordCount=0,dialects=NT LM 0.12] 2008-06-12 16:00:38,874 374846 ERROR [STDERR] (Transport1:) New data read: Transport1[KDC-DEV<00>/192.168.1.200:0] 2008-06-12 16:00:38,874 374846 ERROR [STDERR] (Transport1:) 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 C9 0A 00 00 70 00 |..........É...p.| 2008-06-12 16:00:38,889 374861 ERROR [STDERR] (Transport1:) SmbComNegotiateResponse[command=SMB_COM_NEGOTIATE,received=false,errorCode=0,flags=0x0098,flags2=0xC003,signSeq=0,tid=0,pid=2761,uid=0,mid=112,wordCount=17,byteCount=36,wordCount=17,dialectIndex=0,securityMode=0xF,security=user,encryptedPasswords=true,maxMpxCount=50,maxNumberVcs=1,maxBufferSize=16644,maxRawSize=65536,sessionKey=0x00000000,capabilities=0x0001F3FD,serverTime=Thu Jun 12 16:03:40 IDT 2008,serverTimeZone=240,encryptionKeyLength=8,byteCount=36,encryptionKey=0xC085385D850EA2B7,oemDomainName=ZONE2] 2008-06-12 16:00:38,905 374877 ERROR [STDERR] (http-0.0.0.0-8080-30:) treeConnect: unc=\\KDC-DEV\IPC$,service=IPC 2008-06-12 16:00:38,905 374877 ERROR [STDERR] (http-0.0.0.0-8080-30:) sessionSetup: accountName=TEST92,primaryDomain=ZONE2, digest = null 2008-06-12 16:00:38,905 374877 INFO [com.srndpt.serving.ServingServlet] (http-0.0.0.0-8080-3:) Feed 'LoadTest' served to user TEST7 in 360 ms. 2008-06-12 16:00:38,920 374892 INFO [com.srndpt.core.authentication.bean.NTLMLoginModule] (http-0.0.0.0-8080-30:) Domain controller refused access to TEST92 2008-06-12 16:00:38,952 374924 INFO [com.srndpt.core.authentication.bean.NTLMLoginModule] (http-0.0.0.0-8080-21:) Starting NTLM login... 2008-06-12 16:00:38,967 374939 INFO [com.srndpt.core.authentication.bean.NTLMLoginModule] (http-0.0.0.0-8080-21:) NTLM credentials obtained 2008-06-12 16:00:38,967 374939 ERROR [STDERR] (http-0.0.0.0-8080-21:) treeConnect: unc=\\KDC-DEV\IPC$,service=IPC 2008-06-12 16:00:38,983 374955 ERROR [STDERR] (http-0.0.0.0-8080-21:) sessionSetup: accountName=TEST55,primaryDomain=ZONE2, digest = null 2008-06-12 16:00:38,983 374955 ERROR [STDERR] (http-0.0.0.0-8080-21:) sessionSetup: Finished created request and response 2008-06-12 16:00:38,983 374955 ERROR [STDERR] (http-0.0.0.0-8080-21:) isSignatureSetupRequired: flags2=true, authFlag=true, passFlag=true, digestNull=true 2008-06-12 16:00:38,999 374971 ERROR [STDERR] (http-0.0.0.0-8080-21:) Signature setup is required for ZONE2\TEST55 and is now performed... 2008-06-12 16:00:38,999 374971 ERROR [STDERR] (http-0.0.0.0-8080-21:) treeConnect: unc=\\KDC-DEV\IPC$,service=IPC 2008-06-12 16:00:38,999 374971 ERROR [STDERR] (http-0.0.0.0-8080-21:) sessionSetup: accountName=worklight,primaryDomain=ZONE2.DEVNET.LOCAL, digest = null 2008-06-12 16:00:38,999 374971 ERROR [STDERR] (http-0.0.0.0-8080-21:) sessionSetup: Finished created request and response 2008-06-12 16:00:38,999 374971 ERROR [STDERR] (http-0.0.0.0-8080-21:) isSignatureSetupRequired: flags2=true, authFlag=true, passFlag=true, digestNull=true 2008-06-12 16:00:38,999 374971 ERROR [STDERR] (http-0.0.0.0-8080-21:) Signature setup is required for ZONE2.DEVNET.LOCAL\worklight, but hash is NOT external 2008-06-12 16:00:39,014 374986 ERROR [STDERR] (http-0.0.0.0-8080-21:) SmbComSessionSetupAndX[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC007,signSeq=0,tid=0,pid=2761,uid=0,mid=113,wordCount=13,byteCount=141,andxCommand=0x75,andxOffset=202,snd_buf_size=16644,maxMpxCount=10,VC_NUMBER=1,sessionKey=0,passwordLength=24,unicodePasswordLength=24,capabilities=4180,accountName=worklight,primaryDomain=ZONE2.DEVNET.LOCAL,NATIVE_OS=Windows XP,NATIVE_LANMAN=jCIFS] 2008-06-12 16:00:39,014 374986 ERROR [STDERR] (http-0.0.0.0-8080-21:) SmbComTreeConnectAndX[command=SMB_COM_TREE_CONNECT_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0x0000,signSeq=0,tid=0,pid=2761,uid=0,mid=0,wordCount=4,byteCount=35,andxCommand=0xFF,andxOffset=0,disconnectTid=false,passwordLength=1,password=,path=\\KDC-DEV\IPC$,service=IPC] 2008-06-12 16:00:39,014 374986 ERROR [STDERR] (Transport1:) New data read: Transport1[KDC-DEV<00>/192.168.1.200:0] 2008-06-12 16:00:39,014 374986 ERROR [STDERR] (Transport1:) 00000: FF 53 4D 42 73 00 00 00 00 98 07 C0 00 00 7B C3 |ÿSMBs......À..{Ã| 00010: 96 9F 9B C8 1C 11 00 00 01 18 C9 0A 03 20 71 00 |...È......É.. q.| 2008-06-12 16:00:39,030 375002 ERROR [STDERR] (Transport1:) SmbComSessionSetupAndXResponse[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=0,flags=0x0098,flags2=0xC007,signSeq=1,tid=6145,pid=2761,uid=8195,mid=113,wordCount=3,byteCount=152,andxCommand=0x75,andxOffset=193,isLoggedInAsGuest=false,nativeOs=Windows Server 2003 R2 3790 Service Pack 1,nativeLanMan=Windows Server 2003 R2 5.2,primaryDomain=ZONE2] 2008-06-12 16:00:39,030 375002 ERROR [STDERR] (http-0.0.0.0-8080-21:) SmbComSessionSetupAndX[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC007,signSeq=2,tid=0,pid=2761,uid=0,mid=114,wordCount=13,byteCount=85,andxCommand=0x75,andxOffset=146,snd_buf_size=16644,maxMpxCount=10,VC_NUMBER=1,sessionKey=0,passwordLength=24,unicodePasswordLength=0,capabilities=4180,accountName=TEST55,primaryDomain=ZONE2,NATIVE_OS=Windows XP,NATIVE_LANMAN=jCIFS] 2008-06-12 16:00:39,045 375017 ERROR [STDERR] (http-0.0.0.0-8080-21:) SmbComTreeConnectAndX[command=SMB_COM_TREE_CONNECT_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0x0000,signSeq=0,tid=0,pid=2761,uid=0,mid=0,wordCount=4,byteCount=35,andxCommand=0xFF,andxOffset=0,disconnectTid=false,passwordLength=1,password=,path=\\KDC-DEV\IPC$,service=IPC] 2008-06-12 16:00:39,045 375017 INFO [com.srndpt.serving.ServingServlet] (http-0.0.0.0-8080-1:) Feed 'LoadTest' served to user TEST53 in 500 ms. 2008-06-12 16:00:39,092 375064 ERROR [STDERR] (Transport1:) New data read: Transport1[KDC-DEV<00>/192.168.1.200:0] 2008-06-12 16:00:39,108 375080 ERROR [STDERR] (Transport1:) 00000: FF 53 4D 42 73 6D 00 00 C0 98 07 C0 00 00 0A F3 |ÿSMBsm..À..À...ó| 00010: A8 F6 6F 1C C4 EF 00 00 00 00 C9 0A 00 00 72 00 |¨öo.Äï....É...r.| 2008-06-12 16:00:39,108 375080 ERROR [STDERR] (Transport1:) SmbComSessionSetupAndXResponse[command=SMB_COM_SESSION_SETUP_ANDX,received=false,errorCode=Logon failure: unknown user name or bad password.,flags=0x0098,flags2=0xC007,signSeq=3,tid=0,pid=2761,uid=0,mid=114,wordCount=0,byteCount=0,andxCommand=0xFF,andxOffset=0,isLoggedInAsGuest=false,nativeOs=,nativeLanMan=,primaryDomain=] 2008-06-12 16:00:39,108 375080 INFO [com.srndpt.serving.ServingServlet] (http-0.0.0.0-8080-16:) Feed 'LoadTest' served to user TEST108 in 547 ms. 2008-06-12 16:00:39,139 375111 ERROR [com.srndpt.core.authentication.bean.NTLMLoginModule] (http-0.0.0.0-8080-21:) NTLM Authentication error while trying to login jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password. at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:521) at jcifs.smb.SmbTransport.send(SmbTransport.java:633) at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:285) at jcifs.smb.SmbSession.send(SmbSession.java:233) at jcifs.smb.SmbTree.treeConnect(SmbTree.java:154) at jcifs.smb.SmbSession.logon(SmbSession.java:169) at jcifs.smb.SmbSession.logon(SmbSession.java:162) at com.srndpt.core.authentication.bean.NTLMLoginModule.login(NTLMLoginModule.java:162) at sun.reflect.GeneratedMethodAccessor141.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:579) at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:601) at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:535) at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344) at Thanks alot of taking the time to read all of this! Asaf Mesika
|
|
|
Re: NTLM usrname/password failure after each 5 mins
by Michael B Allen
::
Rate this Message:
On 6/15/08, AsafM <asaf.mesika@...> wrote:
> > Hi all, > > I'm reviving a 2 years old topic, regarding load testing. > You can take a look at the entire thread of the discussion > http://www.nabble.com/NTLM-usrname-password-failure-after-each-5-mins-td5381546.html#a5391633 > here > > I'll start with a quick summary, and then shed lots of details to make it > clearer: > After the transport disconnects (due to socket timeout) and connects, the > first 10 , or so, attempts to authenticate against the DC fails on bad > username/password. After those failures, all attempts succeeds. > I've gained some knowledge I'll now share, but I'm still missing some key > elements to figuring this out. > > Load Testing Setup > 110 threads, consistently accessing a protected resource on Tomcat, which > requires an NTLM authentication. > Each thread is using one user. For example: Thread-34 is logging in as user > TEST34. > > The turn of events > 1. The first thread accessing the resource, setups the session > (SmbSession.sessionSetup()), which blocks all other threads, since each > thread (user) requires to setup a session of its own. > The session setup runs the Transport.connect(), creates a tree for the > default user (to enable SMB signing), and send the SmbComSessionSetupAndX to > the DC, for authentication. > > 2. Once the 1st session setup is done, all other threads follows, each > creating its own session, attached to one transport object (Transport-1 > thread). > > 3. On the second iteration of the test threads, there's no need for session > setup. The session object is retrieved from the transport (it's cached > there). > This usage of cache causes the lack of usage in the transport socket. > > 4. After soTimeout (jcifs constant of 5 min), the loop() method of Transport > receives a SocketTimeoutException, and calls Transport.disconnect() which in > turn calls SmbTransport.doDisconnect(). > > 5. The doDisconnect() logs off all sessions attached to the transport > object, closes down the socket and finally resets the digest property, which > is used to sign each request sent to the DC (this is set in the first > sessionSetup in SmbSession). > > ** First Problem** > While disconnects logs-off sessions, other threads were using them, and > acting as-if the transport is connected. It is ok for other threads to reference sessions. If there is no activity on the socket then it should be possible to close the sessions even if there are 100 threads constantly calling SmbSession.logon(). But the "acting as-if they transport is connected" sounds suspicious. When a transport is shutdown it should call logoff() on each session which should call treeDisconnect() on each transport which should set treeConnected = false. Then, if threads regain access to calling SmbSession.logon() they should see treeConnected = false and the first thread should reconnect the tree, re-logon the session and reconnect the transport. Then subsequent threads see treeConnected and you're back in the steady-state. > I've bypassed this issue, by: > a) Setting the Transport.state to 0 in the Transport.disconnect() function. > This causes the Transport.connect() to actually connect. > b) Adding a synchronize (this) block on both disconnect() and connect() > methods, which prevents running connect() while disconnect() is commencing. I don't understand this. The Transport.connect()/disconnect() methods are already synchronized and the transport state is changed to 0 in disconnect(). > 6. While disconnect() was running, all other threads were waiting in queue, > to run transport.connect(), in the SmbTree.treeConnect() method. > Once the disconnect finished, each thread in its turn, ran the connect > and cotinued for creating a session by running SmbSession.sessionSetup(). > Since that function is syncrhonized on transport(), sessions were created > once at a time, for each thread. > > 7. The first session to run the setup, identified that the transport.digest > was empty (due to SmbTransport.doDisconnect()), thus ran treeConnect on the > default username, used for SMB signing. > Once that was finished successfully, it sent the SmbComSessionSetupAndX for > the user it was trying to authenticate. > It failed in the DC. SmbComSessionSetupAndXResponse returned with an error > code: Logon failure: unknown user name or bad password > > 8. Allot of threads after the first thread inline, failed also on the exact > spot in the sessionSetup(). There is a known "hiccup" that occurs whenever the connection is recycled due to the soTimeout. I don't know what the problem is. I assume the challenge is momentarily wrong. > 9. From some magical reason, which I'm yet to figure out, after 10 or so > failures, the DC started returning success in the > SmbComSessionSetupAndXResponse. Is the NTLM challenge old? Log the hexdump of the NTLM challenge and see if it changes with the result of the SmbComSessionSetupAndXResponse. If it does that confirms that the challenge isn't being handled properly. If it does not change and the new challenge is being used correctly, but the DC is returning different results given the same input then that would be very interesting. This is the best analysis of the "hiccup" bug that I've seen. Aside from my comments, everything you say is true and is expected behavior. The interesting parts are the "acting as-if they transport is connected" bit and what the challenge is spanning the authentication failure / success. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ |
|
|
|
|
|
Re: NTLM usrname/password failure after each 5 mins
by AsafM
::
Rate this Message:
I tried that in the first attempt, but it didn't solve the problem.
I'll follow Micahel's leads and try to investigate it some more... On Tue, Jun 17, 2008 at 7:04 AM, Ti Lian Hwang <lian_hwang.ti@...> wrote:
|
|
|
|
