Correct authentication fails after bad authentication

[bruceceng]

I am testing both the client and server feature along with the setCredentials function to test logins with good and bad credentials. If I have good credentials it works as expected. If I have bad credentials, it fails as expected. But if I put in good credentials after bad credentials I get adding to input a serverContextHandle (not first exchange) right after the NTLM_NEGOTIATE_01 and then it hangs.

It seems to me that it isn't re-initializing properly after submitting bad credentials.

Note: I have set useCookies: false and useGroups: false

[Jean-Louis GUENEGO]

I am going to investigate.

[bruceceng]

Hi Jean-Louis, I did a little more investigation on my own, and it seems like the problem only occurs when I use a valid user (my own login) with an invalid password. If I use an invalid user and invalid password, I didn't experience any problems. Additionally, I tried just patching some of auth.js and if I add a line to release the cookieToken then it seems to work properly. if (serverSecurityContext.SECURITY_STATUS === 'SEC_E_LOGON_DENIED') { console.log('incorrect login/password'); res.statusCode = 401; //api_1.sspi.DeleteSecurityContext(serverSecurityContext); schManager.release(cookieToken); // <-- Adding this seems to help return [2 /*return*/, res.end( "SEC_E_LOGON_DENIED. (incorrect login/password, or account disabled, or locked, etc.). Protocol Message = " + messageType + ".")]; } Of course I don't have great confidence that this is really the proper solution and isn't introducing memory leaks or other issues on the c++ side. Thanks, Bruce

…

On Wed, Aug 12, 2020 at 5:59 AM Jean-Louis GUENEGO ***@***.***> wrote: I am going to investigate. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADK4GUTMHHCMSDSDT64Y6RLSAJYY3ANCNFSM4P3VMQ3A> .

[Jean-Louis GUENEGO]

Yes it is a good one... (I feel a little bit stupid on this one, the resource are not correctly released...).

please test with node-expose-sspi@0.1.37