Impersonation login sometimes takes a long time. Why?-CodePudding

I have an application used internally at my company by several hundred users. It uses impersonated user to securely access a repository of files from a network drive.

Here is my WINAPI declarations:

Private Declare Auto Function LogonUser Lib "advapi32.dll" (ByVal un As String, ByVal domain As String, ByVal pw As String, ByVal LogonType As Integer, ByVal LogonProvider As Integer, ByRef Token As IntPtr) As Boolean

Private Const LOGON32_LOGON_INTERACTIVE As Integer = 2
Private Const LOGON32_LOGON_NETWORK As Integer = 3
Private Const LOGON32_LOGON_BATCH As Integer = 4
Private Const LOGON32_LOGON_SERVICE As Integer = 5
Private Const LOGON32_LOGON_UNLOCK As Integer = 7
Private Const LOGON32_LOGON_NETWORK_CLEARTEXT As Integer = 8
Private Const LOGON32_LOGON_NEW_CREDENTIALS As Integer = 9

Private Const LOGON32_PROVIDER_DEFAULT As Integer = 0
Private Const LOGON32_PROVIDER_WINNT35 As Integer = 1
Private Const LOGON32_PROVIDER_WINNT40 As Integer = 2
Private Const LOGON32 _PROVIDER_WINNT50 As Integer = 3

This is how I use it...

pAccess = LogonUser(sSpecialUser, sDomain, sPW, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, pTokenHandle)

For the vast majority of users, the call to LogonUser takes < .1 seconds. But for some users, the call takes 6 or 20, or 120 seconds. This seems to be dependent on the local network segment the user's computer is connected to.

IT insists that "This is Normal". Performing a login just sometimes takes a long time. I think this is "BS". WHY?

Because if I do this:

pAccess = LogonUser(sCatalogUser, sDomain, sCatalogPW, LOGON32_LOGON_NETWORK_CLEARTEXT , LOGON32_PROVIDER_DEFAULT, pTokenHandle)

It returns with success instantly, from any computer, on any network segment.

Now, using LOGON32_LOGON_NETWORK_CLEARTEXT does not give me the permissions to access network file systems, so it is no good, BUT, it does show that it is not a matter of network topology of the computer WRT to the AD server that is causing this problem.

What factors can cause this sort of delay when performing the impersonated user login?

Thank you for any ideas.

More information:

The network/computers the application are deployed on are NOT connected to the internet.

This has recently started to happen on SOME computers where it was not happening before. Coincidentally perhaps, there were some windows updates applied to these machines the weekend before the slow logons started happening. But other machines have the same patches applied and still do not show the problem.

CodePudding user response：

The answer is: use LOGON32_LOGON_NEW_CREDENTIALS instead of LOGON32_LOGON_INTERACTIVE.

MS documentation:

This logon type allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identifier but uses different credentials for other network connections.

I made an experimental application to check different arguments for LogonUser and when it a got a valid token, checked for the ability to copy files to and from a restricted folder using the impersonated identity. LOGON32_LOGON_NEW_CREDENTIALS worked and was fast.