Organizations deploying OS software often need a feature or tool that lets them define and enforce a limited number of concurrent logon sessions for a particular account. Often this is a must-have feature for highly privileged accounts such as the built-in Administrator account. Most organizations want to block concurrent Administrator logon sessions completely. If a user is logged on using the built-in Administrator account at multiple locations at the same time, he or she is much more likely to leave one of these sessions open—which creates security risks.
Limiting logon sessions for an account is supported natively in OSs such as Novell NetWare, but it's still missing from Windows. However, Microsoft does offer an add-on tool for Windows that you can use to limit concurrent Windows logon sessions. Let's look at how the LimitLogin tool operates and how to install and configure it to limit the number of Administrator logon sessions that are open at a given time.
Requirements and Components
LimitLogin is a revamped version of the Cconnect tool that Microsoft made available as part of the Microsoft Windows 2000 Server Resource Kit. Cconnect provides basic functionality to limit concurrent logon sessions in Windows 2000 and Windows NT 4.0 environments. LimitLogin provides better integration with Active Directory (AD) and AD administration tools. LimitLogin leverages AD for storing the connection-limit data; Cconnect requires a SQL Server database. Like Cconnect, LimitLogin can restrict only interactive and Windows Terminal Services logon sessions. Interactive logon sessions are sessions that users and administrators initiate from the console (by using Ctrl+Alt+Del or the Windows XP Welcome screen).
LimitLogin requires Windows Server 2003 AD and a Microsoft IIS 6.0 Web server that has ASP.NET support enabled. Both servers also must have .NET Framework 1.1 or later loaded.
LimitLogin runs on the following Windows client platforms: Windows 2003, XP Professional Service Pack 1 (SP1) and later, Win2K Professional SP4 and later, and Win2K Server SP4 and later. As is the case for other Windows add-on and resource kit tools, Microsoft Product Support Services (PSS) doesn't provide official support for LimitLogin. When using LimitLogin, you won't be able to trace logons on any workstations that aren't running one of the LimitLogin-supported OSs.
LimitLogin requires configuration changes and special components on the Windows clients, the IIS 6.0 Web server and the AD domain controllers (DCs). Most of these changes and components are created automatically when you install the Limit-Login software. The logon and logoff scripts that LimitLogin uses (llogin.vbs and llogoff.vbs) come with the software but must be copied manually to a share that all Windows clients can access. Also, the user logon/logoff script Group Policy Object (GPO) settings (located in the User Configuration/Windows Settings/Scripts (Logon/Logoff) GPO container) must be changed manually to reference these scripts. The scripts add the overhead of a normal logon script.
The client-side LimitLogin components consist of the Simple Object Access Protocol (SOAP) runtime and a set of LimitLogin-specific DLLs and executables. On the Web server, LimitLogin installs the LimitLogin Web service in the WSLimitLogin virtual directory. By default, WSLimitLogin is created in the Default Web site and the Web service can be accessed on port 80.
Even though the LimitLogin client doesn't submit user credentials to the Web service, Microsoft recommends that organizations with more stringent security requirements manually configure Secure Sockets Layer (SSL) for the WSLimitLogin virtual directory. LimitLogin doesn't automatically provide this SSL protection.
LimitLogin extends the AD schema and builds an application partition to host the LimitLogin configuration data—this is why LimitLogin requires Windows 2003 AD. Figure 1 shows the LimitLogin AD application partition as viewed from the Microsoft Management Console (MMC) ADSI Edit snap-in (which comes with the Windows Server 2003 Support Tools).
The AD application partition is named DC= limitlogin,dc=domainname,dc=domainname. The new object type LimitLogin uses to store a user's logon quota is called msLimitLoginUser. It has the following LimitLogin-specific attributes:
- msLimitLoginDenyLoginOnQuotaExceed—A user is enabled for LimitLogin if this attribute is set to true.
- msLimitLoginQuota—This attribute holds the LimitLogin logon quota.
- msLimitLoginInfo—This attribute holds the logons that are currently registered in AD. The data in this attribute is compared to the quota set in the previous attribute to decide whether a user can get another logon session.
- msLimitLoginUsername—This attribute holds the user's account name.
You configure the AD object and its attributes by using the LimitLogin extensions for the MMC Active Directory Users and Computers snap-in and the LimitLogin command line utilities, which I describe below.
Figure 2 illustrates the LimitLogin components and operation when a user logs on interactively to a LimitLogin-enabled Windows domain. The following events occur:
- The user initiates an interactive logon sequence from a Windows client. The LimitLogin logon script (Llogin) executes.
- The Llogin script sends the user and computer data to the LimitLogin Web service. The data is sent in XML format by using SOAP and includes the username, computername, IP address, session ID, and authenticating DC.
- The LimitLogin Web service checks whether the user has been enabled for LimitLogin and, if enabled, what the user's logon quota is. This data is stored in the LimitLogin AD application partition.
- AD replies with the requested information.
- If the user hasn't been enabled for LimitLogin, the LimitLogin Web service notifies the logon script that it should continue to log the user on normally. If the user has been enabled for Limit-Login and does have a logon quota defined, the LimitLogin Web service counts the number of logons that are currently registered for the user in the LimitLogin application partition. From here there are two possibilities: If the user's logon quota is greater than the number of logons registered in AD, the Web service updates the user's logon information in the LimitLogin application directory partition and notifies the logon script to continue the logon process normally.
If the user's logon quota is less than or equal to the number of logons registered in AD, the Web service notifies the logon script to log off the current session. LimitLogin can optionally be configured to inform the user about his or her other logon locations before it logs the user off.
You can download LimitLogin from http://download.microsoft.com/download/f/d/0/fd05def7-68a1-4f71-8546-25c359cc0842/limitlogin.exe. Installing LimitLogin is relatively straightforward. The tool includes three installation executables: one for installing the Web server components (limitloginiissetup.msi), one for installing the AD DC components (limitloginadsetup.msi), and a third to install the client-side components (limitloginclientsetup.msi). It's important that you run these installation programs in the following order: the Web server installation first, the AD installation second, and the client-side installation third.
The LimitLogin Web server installation allows for the definition of a custom virtual directory name and port for the LimitLogin Web service. The Web server installation requires Administrator rights on the Web server.
As I mentioned earlier, the LimitLogin installation programs don't take care of the LimitLogin SSL configuration. When you configure SSL for the LimitLogin Web service, you must make changes only on the server side. You must install a server-side SSL certificate and link it to the LimitLogin Web service.
You also must edit the limitlogin.wsdl file that's located in the LimitLogin logon share (described below—this share contains the LimitLogin logon and logoff scripts). In limitlogin.wsdl, you must change all URLs that refer to the LimitLogin Web service from HTTP to HTTPs. All the URLs that must be changed are located in the
The LimitLogin AD setup has three parts: preparing the AD forest, preparing the AD domain, and installing the LimitLogin extensions for the Active Directory Users and Computers snap-in. You can run the AD forest installation part from the command line by using LimitLoginADSetup.exe and the /ForestPrep switch. You can run the domain installation part from the command line by using LimitLoginADSetup with the /DomainPrep switch.
To run the first two parts of the LimitLogin-AD setup, your account must have Schema Administrator privileges in the root domain of the forest. Also, you must run the tool on the forest DC that has the Domain Naming Master operations master role. (To determine which DC this is, you can use the Ntdsutil command.)
The last part of the setup (installing the Active Directory Users and Computers LimitLogin extensions) can be run with Domain Administrator privileges on any DC in your forest, or with Administrator privileges on a Windows workstation—in case you're using Administrative Tools to manage AD from a workstation.
The forest preparation extends the AD schema and modifies the AD configuration context. The domain preparation creates the LimitLogin AD application partition and the LimitLogin logon and logoff scripts. During the domain preparation, you can specify the DC on which the LimitLogin application partition should be created.
For high availability or disaster recovery reasons, you might want to create a replica of the LimitLogin application partition on multiple DCs. The "Advanced Configuration Options" section of the LimitLogin Help file describes how to do this.
At the end of the AD setup, you must manually copy the LimitLogin logon and logoff scripts to a share and reference them in your domain GPO settings. The Limit-Login setup program reminds you to do so at the end of the LimitLogin AD installation (as illustrated in Web Figure 1, http://www.windowsitpro.com, InstantDoc ID 50596).
The AD installation portion of LimitLogin creates detailed log files: %systemdrive%\ program files\limitlogin\limitloginadsetup .log and %systemdrive%\windows\system32\ ldif.log.
You can run the LimitLogin client setup program manually or in an automated way. Automated Microsoft-centric installation options include Microsoft Systems Management Server (SMS), GPOs, and logon scripts. To run the client installation from the command line in quiet mode (which requires no user interaction) use limitloginclientsetup .msi with the /qn switch. Because the client setup installs the SOAP client, it requires Administrator rights.
If the LimitLogin Web service isn't running on the DC hosting the LimitLogin application partition, you must make sure that you trust the Web server's computer account for delegation to the LimitLogin DC. The "LimitLogin Active Directory Setup" section of the Limit-Login Help file describes how to do this.
Configuration and Usage
Your best friend when configuring concurrent logon settings on AD user objects is the Active Directory Users and Computers snap-in. The LimitLogin AD installation program adds several LimitLogin configuration options to the snap-in. You can access the LimitLogin Tasks menu option from the context menu of user, computer, and organizational unit (OU) objects.
Figure 3 shows the configuration dialog box that pops up when you select the LimitLogin Tasks option for a user account object—in our example, the Administrator account. This dialog box shows the machines that the selected account is currently logged on to interactively. You can also use this dialog box to log off selected sessions and delete them from the LimitLogin AD application partition, to save the logon overview in a comma-separated value (CSV)- or XML-formatted report, and most importantly to configure a concurrent logon quota.
To configure a quota, you click Configure to open the Configure LimitLogin dialog box (Web Figure 2), which simply lets you specify a quota number or specify that you don't want to set a quota. In our Administrator example, you typically want to allow only one logon session at a time—which means you must give the Administrator account a logon quota of 1.
The LimitLogin software also comes with a VBScript sample that automates concurrent logon setting configuration for all users in a particular OU or domain. The script is called bulk_limituserlogins.vbs and is located in the %systemdrive%\program files\limitlogin folder on DCs that have LimitLogin installed.
When you select the LimitLogin Tasks context menu option on a computer object, you'll see a dialog box that lists all the users that are currently logged on interactively to that particular machine. The dialog box also allows you to delete and optionally log off selected logon sessions—for example, Administrator logon sessions; ping the remote machine; and save the list of interactive logon sessions to a CSV-or XML-formatted report. If you select a logon session, then click Delete/Logoff Selected Sessions, LimitLogin will by default delete the logon session from the AD application partition and log off the remote session without prompting the administrator for confirmation. The LimitLogin delete/logoff behavior can be configured by clicking the Click Here to Set Logoff Options link in the dialog box (as Web Figure 3 shows).
LimitLogin offers the following delete/ logoff behavior options:
- Attempt to Remotely Logoff the selected session(s)—This option is selected by default. If you clear this option, selected sessions will just be removed from the AD LimitLogin application partition and no logoff attempt will be initiated.
- Prompt and confirm every selected session before attempting Remote Logoff—This option is cleared by default. If you select this option, LimitLogin will ask the administrator to confirm the session logoff.
- Logoff all selected sessions without prompting (Yes to All)—This option, selected by default, logs off selected sessions without prompting the administrator.
- Wait for Remote Logoff attempts to complete and report status—This option is selected by default. When this option is enabled, LimitLogin will wait for a status notification to come back from the remote host after a logoff is initiated.
You can also configure the delete/logoff behavior settings in the system registry of the machine on which you're using the Active Directory Users and Computers snap-in that has the LimitLogin extensions installed. Web Table 1 shows the corresponding registry entries, their values, and meaning. They are all located in the HKEY_CURRENT_USER\Software\ Microsoft\LimitLogin registry subkey.
The LimitLogin Tasks option on an OU object context menu can be used to set a concurrent logon quota for all user objects in the selected OU at once.
If you want LimitLogin to inform the administrator about his or her other logon locations (as illustrated in Figure 4) before logging the administrator off, you must make a change in the LimitLogin logon script (Llogin): Simply remove the comment marks from the following lines:
' wshShell.run "lloginsessions " & loginok ' wscript.sleep 1ØØØØØAs mentioned above, you can also use LimitLogin as a logon reporting tool. You can generate XML-or CSV-formatted files from the Active Directory Users and Computers interface. To generate logon reports that cover entire domains, you can use the llogincmd.exe command-line utility with the /report switch.
You can use the same command-line utility, but with the /diag switch, to run a LimitLogin diagnostic (which Web Figure 4 shows). To remove all logon information from the LimitLogin AD partition, use Llogincmd with the /ClearLogins switch. To synchronize user accounts and their naming information in the LimitLogin AD partition with their corresponding AD entries, use Llogincmd with the /Update switch.
LimitLogin is a must-have tool for enterprise-level AD deployments, which need a way to control the number of sessions that user accounts, and particularly Administrator-level users, have open at one time. LimitLogin also has a handy reporting feature, however organizations that need only a logon reporting tool don't necessarily need to deploy LimitLogin. Logon reporting can easily be done using simpler tools: for example, by dumping a machinename.username text file to a hidden shared folder at logon time.
Problem: Limiting concurrent Windows Administrator logon sessions