Occasionally I am contacted with specific questions or topics people would like to hear more about. This post is a reply to one of those. Here’s the question:
My question is what are the impact when I change the logon workstation property of a user account in AD. Obviously, that user account cannot log on to the domain from workstations which are not specified in logon workstation property. I want to know if there is any other situation that the user account cannot accessing those workstations by other methods, like WMI, RPC, etc. Which authentication methods are affected by the logon workstation setting in AD?
This was a really good question. First, let me give you all the caveat that I didn’t have time to test this ;) but I believe this is correct anyway after a depth review of how our product works.
Here's a picture of the Logon Workstations page we're talking about.
It looks like the restriction follows someone for any interactive type (which also includes rdp) or network logon to a workstation for certain and probably all others as well. Basically I would expect the user to fail any type 2 or 3 logon which would include remote connection to a file share on that workstation, for example. The restriction acutally seems to hinge on how the user has authenticated but the restriction is in the area of our product on the method they are using to connect, such as how they logged on. What’s a logon type and why would the type of authentication used for that make a difference in this?
Logon types are terms we typically talk about when discussing logon auditing in AD. You’ll recall that as a field when you are auditing logon for success or failure as it shows something like below, which is the logon event from when I logged onto my computer this morning but was remote to any DC (the DC locator code in netlogon service couldn’t locate a domain controller to communicate with…a result of my being at home waiting for icy roads to clear. But I digress.)
Event Type: Success Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 528
Date: 3/7/2008
Time: 7:29:49 AM
User: NORTHAMERICAtspring
Computer: TSPRING6
Description:
Successful Logon:
User Name: tspring
Domain: NORTHAMERICA
Logon ID: (0x0,0x45F1D)
Logon Type: 11
Logon Process: User32
Authentication Package: Negotiate
Workstation Name: TSPRING6
Logon GUID: {00000000-0000-0000-0000-000000000000}
To put this in context there are different kinds of logons in the Windows product suite. A bit more about auditing and logon is here . The idea to keep in mind is that these different logon types, which I’m pasting from that Technet article; note the Logon Type field in the event above, which indicates 11.
|
Logon type |
Logon title |
Description |
|
2 |
Interactive |
A user logged on to this computer. |
|
3 |
Network |
A user or computer logged on to this computer from the network. |
|
4 |
Batch |
Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention. |
|
5 |
Service |
A service was started by the Service Control Manager. |
|
7 |
Unlock |
This workstation was unlocked. |
|
8 |
NetworkCleartext |
A user logged on to this computer from the network. The user's password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext). |
|
9 |
NewCredentials |
A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections. |
|
10 |
RemoteInteractive |
A user logged on to this computer remotely using Terminal Services or Remote Desktop. |
|
11 |
CachedInteractive |
A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials. |
So that answers the question about what these logon types are. But we still have some understanding needed around authentication types. Authentication types, or methods really, are all of the methods the Windows products support to verify a user is a known one and assign them a set of properties which can be used compare to resource access control lists and other security oriented structures and get a resultant authorization idea for that user for that resource or action. Try diagramming that sentence, O Reader! Our common authentication types are Negotiate, Kerberos, NTLM, SSL/TLS, and Digest.
This link talks about these from the context of Server 2008’s new CredSSP support for logon.
Getting back to the original question. I want to know if there is any other situation that the user account cannot accessing those workstations by other methods, like WMI, RPC, etc. Which authentication methods are affected by the logon workstation setting in AD?
I was able to see that NTLM and Kerberos authenticated connections looked like they would hit this restriction. Basically our products contain a check in the authentication types or methods (like Kerberos and NTLM) to see if the user has that restriction set and if they do they will reach an error condition called STATUS_INVALID_WORKSTATION which leads to (typically) STATUS_ACCOUNT_RESTRICTION. What that means is that if a remote connection (such as a remote RPC call, or accessing a share-authenticated SMB- on a remote computer the user has an account restriction set which doesn’t allow them to logon to) is authenticated using one of these methods and the user has a restriction from accessing that target computer then that connection will fail. That behavior should be expected and if I as an administrator saw otherwise that would be the time to delve into the problem of why a user was allowed when they shouldn’t have been.
I’ve had some other good questions which I haven’t had an opportunity to explore but I hope to be getting to them soon. Have a great day folks!