NTLM Authentication problem

[Ed Baron]

Dear Sirs,
We have been using your software for 1 year. Recently we have been confronted with serious difficulties. We tried to solve these problems by ourselves, but unsuccessfully.

The main idea of the problem is as follow:
Wingate 6.6.3 Enterprise is installed on Microsoft Windows Server 2003 R2 Standard Edition. Operating System user database is used in Wingate. WWW Proxy Service has been started In Wingate (port 8080). In Policies, for cleanliness of the experiment only one user with NTLM authentication only (User must be authenticated).
There is terminal server (Microsoft Windows Server 2003 R2 Standard x64 Edition, version 5.2.3790 Service Pack 2, assemle 3790). Trying to start browser Microsoft Internet Explorer (8.0.6001.18702) from terminal session (it is customised through a proxy with port 8080), authentication window appears (not on any site, but, for example on rbc(dot)ru). After pressing "Cancel" button this window can appear some more time (again I press "Cancel") then the page is shown quite correctly. It is possible to enter the name and password of the domain user instead of "Cancel", the result will be the same. When we want to open a new page or return back to already visited page the authentication window will appear again and again.
The most interesting thing is if the same domain user entering on the usual Windows XP station, instead of on a terninal server session, there is no problem like this.

Below is WWW Proxy Service log:
See WWWLog1.jpg

Such part of log is especially interesting here:
See WWWLog2.jpg

As we can see the package with the same number is identified as coming package, both from user Guest and from user User1234.

We anxiously await your response. Your help will be greatly appreciated.
Your sincerely, Eduard Baron.

[adrien]

Hi Ed

genie's been working through this issue in the lab here for the last day and a half.

from packet captures, it looks like the client is attempting to auth with NTLM using the guest account. Not sure why the server is allowing that auth to succeed. WinGate is only a transport for auth information in the case of NTLM, passing the data received from the client through to the NTLM SSPI, and passing any buffer from the SSPI back to the client until the SSPI says the auth is completed / failed etc.

If disabling the guest account in the OS on the WinGate machine didn't fix the problem, then perhaps there is a permissions issue on that account? Can you check the Local Security Settings, for which users are granted the rights:

Log on locally
Log on as a service
Log on as a batch job

I just checked my machine here (XP pro), and Guest is granted Log on locally rights (seems odd).

Adrien

[adrien]

We did some more testing.

If you disable the Guest account in the control panel, users applet, it doesn't disable it. You need to disable it under Local users and Groups in Computer Management.

If you rename the Guest account, that's the username that then shows up in GateKeeper when this problem shows. This proves that the browser is actually authenticating as guest to the NTLM SSPI underneath WinGate. There's nothing much WinGate can do about this.

So what it means is that you need to either

a) disable the Guest account in Local Users and Groups; or
b) give the Guest account a password; or
c) in WinGate policy don't grant rights to the proxy to the Guest user.

Regards

Adrien

[Ed Baron]

Hi Adrien.
We would like to add some details.
On the Wingate machine russion version OS is installed and by default user Guest calls Gost’ (on cyrilic). This accaunt is disabled in Local Users and Groups and, accordingly in Wingate.
Besides, Wingate mashine is in domain and Wingate uses the user database from AD. There is no user Guest in AD. And with it Wingate user list includes both Guest and Gost’ (on cyrilic).
Have you any ideas?
Best regards.
Ed.

[Ed Baron]

And then some.
Domain Controller also installed on russian version OS and embeded user Gost’ (on cyrillic) is disabled also.

[adrien]

HI Ed

We've found that even if WinGate is set to use accounts from an AD, NTLM SSPI still will allow authentication against the windows user database of the host machine (rather than the AD accounts).

We fixed this in WinGate 7, by a post-auth check, but the SSPI still allows authentication to those accounts.

So did you disable this account as well?

When we try here, it works if we disable the account. If there is no local or AD account called Guest, and WinGate creates an account called Guest, then theoretically it should be impossible to authenticate to that account.

You could try setting a password on those guest accounts?

Regards

Adrien