MSLOGON3 and secured computers

[mfo2]

Hi Marscha,

I've got a problem that's causing me a few headaches even if I'm able to find a workaround I'd like to have a technical explanation from you.
In my company we have a rule that enforces heavy securing for laptops. One of this security parameter is to remove any access from the network to the laptops. This setting is applied through local policies:
Computer Configuration->Windows parameters->Security Parameters->Local Policies->User rights assignment->Access this computer through the Network.
Normally, the local Administrators group shows up in this topic, but for security reasons everything is removed from there.

Now for the problem with UltraVNC and MSLOGON3:
On these secured computers, MSLOGON3 doesn't work even if the proper credentials are provided. If I add back the local Administrators group to the "Access this computer through the Network" right, and try to authenticate with either local admin or domain admin, it works.
If I add any AD domain group to "Access this computer through the Network" and if I also put this group in the MSLOGON3 ACL, and try to authenticate with a domain user member of this group, it also works.

Switching to classic MSLOGON with nothing in "Access this computer through the Network" works perfectly so it must be something in the way you authenticate users in v3 that relies on the "Access this computer through the Network" right.

I'm doing my tests with RC19.5 (problem is the same with prior RC19 releases), installed as service, on Win2KSP4 US belonging to a Windows 2003 Active Directory forest.

Here's an extract from winnt\system32\WinVNC-authSSP.log (I added line numbers to later discuss each line):
1:CUPSD2: Access is 0, user administrator is not authenticated, access granted is 0x0
2:CUPSD2: Access is 0, user admin is not authenticated, access granted is 0x0
3:CUPSD2: Access is 0, user toto is not authenticated, access granted is 0x0
4:CUPSD2: Access is 1, user admin is authenticated, access granted is 0x60003
5:CUPSD2: Access is 1, user administrator is authenticated, access granted is 0x60003
6:CUPSD2: Access is 0, user toto is not authenticated, access granted is 0x0

Lines 1 & 2 are login attempts with domain and local admin accounts while there's nothing in "Access this computer through the Network"=>failures but unexpected
Line 3 is a login attempt with a non existent account while there's nothing in "Access this computer through the Network"=>failure (but normal)
Lines 4 and 5 are login attempts with domain and local admin accounts while there's local Administrators group in "Access this computer through the Network"=>successes
Line 6 is a login attempt a non existent account while there's local Administrators group in "Access this computer through the Network"=>failure (but normal)

My present workaround would be to push any help desk AD group to the "Access this computer through the Network" right with a GPO but if I can avoid this it would be great.

That was a lengthy post, I hope that you can do something to modify this behaviour and that it's not a MS feature you are locked with.

Thanks a lot,

Marc

[Marscha]

Marc,

I'm sorry but I think there is no way around this behaviour.

Background: The new MSLogon (MSLOGON3 in your post, we call it now MSLogon II) authenticates with SSPI.
This apparently qualifies as "access from the network".

With MSLogon I (classic MSLOGON) you have the same method along with various others.
If any method succeeds you are authenticated.

The reason MSLogon II only uses SSPI is that I use the result to impersonate and check the access rights (authorization).
That way UltraVNC's access check is as Microsoft-like as possible.
And you get all checking for nested groups for free.

AFAIK the default setting for the "access this computer from the network" is "Everyone".
There is also the opposite option "deny access to this computer from the network".

Martin

[mfo2]

Martin,

Thanks for shedding light on this issue. I guess I'll have to revert to this workaround if I want to use the greatness of MSLogon II !
Nice job anyway.

Take care,

Marc