NT/2000 User Rights

The last different between Unix and NT/2000 user identity that we're going to address is the concept of a

"user right." In Unix, the actions a user can take are either constrained by file permissions or by the

superuser/non−superuser distinction. Under NT/2000, the permission scheme is more like superheroes. Users (and groups) can be imbued with special powers that become part of their identity. For instance, one can attach the user right Change the System Time to an ordinary user and that user will be able to effect the setting of the system clock on that machine.

Some people find the user rights concept confusing because they have attempted to use NT 4.0's heinous User Rights dialog in the User Manager or User Manager for Domains application. This dialog presents the information in exactly the opposite manner most people expect to see it. It shows a list of the possible user rights and expects you to add groups or users to a list of entities that already have this right. Figure 3−1 shows a screenshot of this UI example in action.

3.2.4. NT Groups 94

Figure 3.1. The User Rights Policy dialog box from the NT4 User Manager

A more user−centric UI would offer a way to add or remove user rights to and from users, instead of the other way around. This is in fact how we will operate on rights using Perl.

One approach is to call the program ntrights.exe from the Microsoft NT Resource Kit. If you haven't heard of the resource kit, be sure to read the upcoming sidebar about it.

The Microsoft Windows NT/ Windows 2000 Resource Kits

"You must have the NT 4.0 Server and/or Workstation Resource Kit " is the general consensus among serious NT administrators and the media that covers this field. Microsoft Press publishes two large tomes, one for each of the NT/2000 OS versions, full of nitty−gritty operational information. It is not this information that makes these books so desirable; rather, it is the CD−ROMs included with the books that makes them worth their weight in zlotniks. The CD−ROMs contain a grab bag of crucial utilities for NT/2000 administration.

The utilities shipped with the NT/2000 Server editions are a superset of those shipped with the NT

Workstation/Windows 2000 Professional version, so if you have to choose one of the two to buy, you may wish to get the Server edition.

Many of the utilities were contributed by the NT/2000 development group who wrote their own code because they couldn't find the tools they needed anywhere else. For example, there are utilities which add users, change filesystem security information, show installed printer drivers, work with roaming profiles, help with debugging domain and network browser services, and so on.

The tools in the Resource Kit are provided "as is," meaning there is virtually no support available for them.

This no−support policy may sound harsh, but it serves the important purpose of allowing Microsoft to put a variety of useful code in the hands of administrators without having to pay prohibitive support costs. The utilities in the Resource Kits have a few small bugs, but on the whole they work great. Updates that fix bugs in some of these utilities have been posted to Microsoft's web site.

Using ntrights.exe is straightforward; we call the program from Perl like any other (i.e., using backticks or the system( ) function). In this case, we call ntrights.exe with a command line of the form:

C:\>ntrights.exe +r <right name> +u <user or group name> [−m \\machinename]

to give a right to a user or group (on an optional machine named machinename). To take that right away:

C:\>ntrights.exe −r <right name> +u <user or group name> [−m \\machinename]

Unix users will be familiar with the use of the + and − characters (as in chmod ), in this case used with the −r switch, to give and take away privileges. The list of right names like SetSystemtimePrivilege (can set the system time) can be found in the Microsoft NT Resource Kit documentation for the ntrights command.

The Five−Minute RCS Tutorial (Perl for System Administration)

3.2.5. NT/2000 User Rights 95

A second, pure−Perl approach entails using the Win32::Lanman module by Jens Helberg, found at either ftp://ftp.roth.net/pub/ntperl/Others/Lanman/ or at http://jenda.krynicky.cz. Let's start off by looking at the process of retrieving an account's user rights. This is a multiple−step process; let's go over it step by step.

First, we need to load the module:

use Win32::Lanman;

Then, we need to retrieve the actual SID for the account we wish to query or modify. In the following sample, we'll get the Guest account's SID:

unless(Win32::Lanman::LsaLookupNames($server, ['Guest'], \@info) die "Unable to lookup SID: ".Win32::Lanman::GetLastError( )."\n";

@info now contains an array of references to anonymous hashes, one element for each account we query (in this case, it is just a single element for Guest). Each hash contains the following keys: domain,

domainsid, relativeid, sid, and use. We only care about sid for our next step. Now we can query the rights:

unless (Win32::Lanman::LsaEnumerateAccountRights($server, ${$info[0]}{sid}, \@rights);

die "Unable to query rights: ".Win32::Lanman::GetLastError( )."\n";

@rights now contains a set of names describing the rights apportioned to Guest.

Knowing the API (Application Program Interface) name of a user right and what it represents is tricky. The easiest way to learn which names correspond to which rights and what each right offers is to look at the SDK (Software Developement Kit) documentation found on http://msdn.microsoft.com. This documentation is easy to find because Helberg has kept the standard SDK function names for his Perl function names. To find the names of the available rights, we search the MSDN (Microsoft's Developer News) site for

"LsaEnumerateAccountRights" and we'll find pointers to them quickly.

This information also comes in handy for the modification of user rights. For instance, if we want to add a user right to allow our Guest account to shut down the system, we could use:

use Win32::Lanman;

unless (Win32::Lanman::LsaLookupNames($server, ['Guest'], \@info)) die "Unable to lookup SID: ".Win32::Lanman::GetLastError( )."\n";

unless (Win32::Lanman::LsaAddAccountRights($server, ${$info[0]}{sid}, [&SE_SHUTDOWN_NAME])) die "Unable to change rights: ".Win32::Lanman::GetLastError( )."\n"

In this case we found the SE_SHUTDOWN_NAME right in the SDK doc and used &SE_SHUTDOWN_NAME (a subroutine defined by Win32::Lanman), which returns the value for this SDK constant.

Win32::Lanman::LsaRemoveAccountRights( ), a function that takes similar arguments to those we used to add rights, is used to remove user rights.

Before we move on to other topics, it is worth mentioning that Win32::Lanman also provides a function that works just like User Manager 's broken interface described earlier. Instead of matching users to rights, we can match rights to users. If we use

Win32::Lanman::LsaEnumerateAccountsWithUserRight( ) we can retrieve a list of SIDs that has a specific user right. This could be useful in certain select situations.

3.2.5. NT/2000 User Rights 96

3.1. Unix User Identity 3.3. Building an Account System to Manage Users

Copyright © 2001 O'Reilly & Associates. All rights reserved.

Chapter 3: User Accounts