Boswell's Q&A
Keeping Users At Bay
A feature that's been available for decades on NetWare, here's a new Windows utility can be used to limit number of concurrent user logins.
- By Bill Boswell
- 03/29/2005
Readers:
Every week or so, I get an irate letter
from an administrator who wants to limit the number of concurrent logons
available to users. These administrators cite security concerns based
on this argument: If users are logged on at multiple locations, they are
much more likely to leave one of these locations open for compromise.
The administrators also usually point out that NetWare has been able to
do this since the 1980s. They often include an exclamation point or two.
"The 1980's!!"
In the past, I've pointed these admins at a Windows 2000 Resource Kit utility called
Cconnect but warned them that it's a fairly limited solution and urged them
to spend time looking for third-party utilities that can give
them the necessary functionality.
Well, that situation has changed. Microsoft
Product Support Services released a utility called LimitLogin, which you can download by
clicking here
.
I ran across the utility while reading John Howard's excellent Microsoft blog
at
http://blogs.msdn.com/jhoward/archive/2005/03/14/395135.aspx
.
(John's blog is always a great source of news; be sure to add his link
to your RSS subscriptions.)
| Get
Help from Bill |
|
Got a Windows or Exchange question or need troubleshooting
help? Or maybe you want a better explanation than provided
in the manuals? Describe your dilemma in an e-mail
to Bill at mailto:boswell@101com.com;
the best questions get answered in this column.
When you send your questions, please include your
full first and last name, location, certifications (if
any) with your message. (If you prefer to remain anonymous,
specify this in your message but submit the requested
information for verification purposes.)
|
|
|
LimitLogin requires a bit of effort to deploy. For one thing, it performs
a Schema modification. For another, it creates a new partition in Active
Directory. It also requires configuring a Web server with the .NET Framework
and ASP.NET and setting it up to do delegated Kerberos authentication.
Finally, it requires distributing client packages that support communicating
with the Web server via SOAP (a lightweight protocol for exchanging structured
information in a distributed environment).
Whoa. Don't stop reading. It's complicated, but not impossible.
Really.
If you're put off by the need to do a Schema modification, take heart.
Yes, yes...I know you can't remove objects from the Schema once they've
been added, but LimitLogin only adds five objects, which isn't exactly
going to cause the galaxy to shift its orbit. Absolutely no changes
are made to classes or attributes. You'll need Schema Admin permissions
in the root domain of the forest to do the Schema modifications.
Because LimitLogin uses this assortment of fairly advanced technologies,
it will only control interactive (console-based) logins from clients running
the following operating systems:
- Windows 2000 Professional Service Pack 4 and newer
- Windows 2000 Server Service Pack 4 and newer (Including Terminal
Server sessions)
- Windows XP Professional Service Pack 1 and newer
- Windows Server 2003 (Including Terminal Server sessions)
You'll need an Active Directory domain with at least one Windows Server
2003 domain controller. This domain controller must own the Domain Naming
Master FSMO role, because LimitLogin creates an Application naming context
(also called an Application Directory Partition). If you aren't familiar
with this feature, click here to read a Microsoft white paper that explains it.
or http://snipurl.com/9tdf.
You'll also need a Windows Server 2003 server with version 1.1 or newer
of the .NET Framework where you can run IIS with ASP.NET. The security
configuration for the ASP.NET extension needs to be set to Allow (see Figure 1).
 |
| Figure 1. Set security for the ASP.NET extension to Allow from this dialog. (Click image to view larger version.) |
Installing LimitLogin
LimitLogin consists of three MSI packages plus a Help file:
- LimitLoginIISSetup.msi
- LimitLoginADSetup.msi
- LimitLoginClientSetup.msi
- LimitLogin.chm
Start the installation by running the LimitLoginIISSetup package at the
Web server. This adds a new virtual folder to the default Web site and
installs a variety of files (see Figure 2).
 |
| Figure 2. Running LimitLoginIISSetup spawns a new folder on the default Web site, with some files. |
Now run the LimitLoginADSetup package. This package does three things.
First, it extends the Schema to add four new attributes and a new Structural
class called LimitLoginUser (see Figure 3).
 |
| Figure 3. See the new Schema additions with ADSIEdit. (Click image to view larger version.) |
Second, it adds a new naming context to the forest root namespace. The
container for this naming context is called LimitLogin.
Third, it adds an extension to Active Directory Users and Computers (ADUC)
to expose a new property menu item called LimitLogin Tasks. Selecting
this option for a user opens a Properties interface for configuring LimitLogin
settings (see Figure 4).
 |
| Figure 4. Now you can configure LimitLogin. |
During this portion of LimitLogin setup, you'll have to do some hacking.
After all, this is a 1.0 release of a Resource Kit-style utility.
LimitLogin comes with two scripts, one each for logon and logoff,
and a wsdl file for XML formatting. You'll need to create a share to hold
these files and create a Group Policy Object configured to run the
scripts (see Figure 5).
 |
| Figure 5. Logon script that runs the llogin.vbs script. You're just about done with the installation and configuration. |
That pretty much takes care of the initial setup and configuration. When
you use the ADUC extension to limit a user's concurrent logins, the extension
creates a new object in the LimitLogin naming context. Figure 6 shows the Microsoft LDAP Browser, depicting the LimitLogin naming
context after it has been populated with an msLimitLoginUser object that
represents a user in the Domain naming context. Note that this object
is only linked to the User object in the domain via a name. No changes
are made to the Schema that associates the msLimitLoginUser class or its
attributes with the User class.
 |
| Figure 6. What limiting logins looks like from the LDAP Browser. (Click image to view larger version.) |
The final steps involve configuring the clients. You then need to run
LimitLoginClientSetup.msi on any desktop or terminal server where you
want to limit users' concurrent logins. This client installs the required
plumbing so that the logon and logoff scripts can generate the required
SOAP requests when communicating with the Web server. In other words,
the script uses an XML class that isn't present until you install the
client piece.
The client comes in an MSI so you can deploy it using GPOs.
It requires local admin rights, so assign the package to the Software
settings on the Computer side of a GPO that is linked to the OUs that
contain your desktops and terminal servers. You'll need to wait for the
computers to restart to apply this setting and install the package.
With all this in place, here's what happens when a user logs in at a configured
client.
Let's say you configure a user to have a login limit of 1. This value
is written to the msLimitLogin object in Active Directory.
The user reports for work in the morning and logs on at a desktop. The
Login.vbs logon script communicates with the Web server. The Web server
does a lookup in Active Directory to determine if the user has been configured
with a login limit and, if so, has the user already logged in somewhere
else.
In this case, the user has no other concurrent logons, so the Web server
records the identity of the machine where the user has logged on and then
the login process continues as normal. The user has no indication that
the llogin.vbs logon script has executed.
When the user attempts to log in at a second workstation or a terminal server
session, the logon script communicates with the Web server. The Web server
checks Active Directory and discovers that the user is already logged
in somewhere else. It compares the number of current logins with the user's
limit. In this case, the limit is 1 so the Web server informs the client
that the user has met or exceeded the limit and the user is logged off.
In the default configuration, there are no errors messages; the limitlogin
client simply forces a logoff and puts the user back at a logon window.
There is an additional feature in LimitLogin that runs a small executable
to show the user the location of the other logins. This is handy information
and you should include this feature in any production deployment of LimitLogin.
Because LimitLogin uses logon and logoff scripts, it is not effective
in stopping VPN connections or command-line connections. But it's a step
in the right direction. If your organization has been looking for a way
to restrict concurrent logins, then you should certainly download and
test the LimitLogin utility. Like other Resource Kit style utilities,
LimitLogin is not directly supported by Microsoft PSS.
If you try the utility, be sure to write and let me know how you like
it.
Until next week!