Thursday, September 30, 2010

"Log On To" Why Doesn't Anybody Use It?

I decided to write an article on the "Log On To" feature in Microsoft's Active Directory because I have yet to find others that use this feature. I am not saying you aren't out there, but I think this is a much overlooked feature. We use this feature along with "Limit Login" (see this post) to restrict the computers our users can log in to and limit simultaneous sessions.

The Log On To feature can be found by going to the properties of the user object and selecting the "Account" tab. There is a button on that tab that says "Log On To...". You can use this button to open a dialog that allows you to specify all of the computers a user is allowed to (Have you guessed yet?) log on to.

Why is this important?

Well, why not? If there are users that only log into one computer every single day, why allow them to log into every single machine on the network.

What does it block (By Design)?

The "Log On To" feature stops the user from logging on the the console of a computer (whether sitting at the machine or through remote control software (Remote Desktop/RDP, PC Anywhere, VNC, etc.)).

What does it block (Undesired results)?

So, the feature is not without problems. If you are using any type of LDAP authentication, you will have to add your LDAP servers to the list of allowed computers. You will also have to add the server that hosts Outlook Web Access if you use Exchange for your mail server. Other stuff that you may have issues with are Radius servers and websites with Integrated Authentication.

What doesn't it block?

You can still use file/printer sharing on servers that are not on the list so you do not need to add your File/Print servers to the list. You do not need to add your Domain Controllers either unless you are using them for LDAP.

Microsoft Limit Login and Login Scripts on x64 Machines

We use Limit Login in our environment and I ran into some issues the other day when we deployed some 64-bit terminal servers at our Beijing, China location. For those unfamiliar with Limit Login, it is a utility provided by Microsoft that allows you to limit the number of simultaneous login attempts within an Active Directory environment. The utility works by extending the the Active Directory schema to store additional information related to logins. Therefore, you do not need to store the information in a separate database as required with past methods. The utility then uses web services and login scripts to update the information in Active Directory. For more information on the utility, please see this article.

We use Limit Login along with the "Log On To" property (see this post) of the Active Directory user object to limit the machines users can log on to and how many simultaneous sessions they are allowed.

Anyway, back to the issues. Once I set up all of the users and configured their user objects to limit the number of simultaneous logins, I performed some tests and noticed it wasn't adding the logins to Active Directory. After some troubleshooting, I noticed that the login scripts were not running correctly. They were getting errors because the objects used to connect to the web services were 32-bit controls. After additional troubleshooting, I found that I needed to run the login script under the 32-bit version of wscript (the object that runs script files like vbscript in windows). Apparently, the x64 version of Windows Server 2003 includes two different objects. The default object is stored in the system32 folder and is actually the 64-bit version (yeah awesome right). The 32-bit version is stored in SysWow64 (again awesome, but I am sure they have their reasons). Anyway, since I needed the script to run under the 32-bit object, I had to create a login script that first determined if the OS was x86 or x64 and then ran the original Limit Login script under the correct version of the wscript object for x64 servers.

Here is an example of the login script that calls the Limit Login script:

On Error Resume Next

Set WshShell = CreateObject("WScript.Shell")

OsType = WshShell.RegRead("HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\PROCESSOR_ARCHITECTURE")
If (OsType = "x86") Then
WSHShell.Run "wscript \\SERVERNAME\LLScripts$\lloginscript.vbs", , True
WSHShell.Run "%windir%\SysWow64\wscript \\SERVERNAME\LLScripts$\lloginscript.vbs", , True
End If