Section 9.2. Configuring a Samba PDC

9.2. Configuring a Samba PDC

To build a Samba Primary Domain Controller, it is best to begin with a working standalone file server. We assume the following configuration:

 [global]     netbios name = STORK     workgroup = ORA     security = user     encrypt passwords = yes [public]     path = /data/public     read only = no

There are five minimum requirements that must be met by a Samba PDC:

User mode security (security = user)
Support for encrypted passwords (encrypt passwords = yes)
A properly configured [netlogon] file share
Configuration as a Domain Master Browser (domain master = yes)
Configuration as a logon server (domain logons = yes)

Our initial smb.conf meets the first two requisites. The next step is to add a [netlogon] file share that emulates the NETLOGON service on Windows domain controllers. The share itself must be readable by all domain users, so that they can access items such as policy files and login scripts (covered later in this chapter), but should restrict write access solely to administrators. This example specifies the share as read only, but includes the ntadmin group in the write list; ntadmin is our primary group for systems administrators:

 [netlogon]     comment = Net Logon service     path = /data/netlogon     read only = yes     write list = +ntadmin

Enabling the domain master parameter in the global section of smb.conf causes nmbd to register the DOMAIN<0x1b> name (ORA<0x1b> in our example). This name is used by Windows clients to locate the PDC for a domain. When searching for any domain controller, not necessarily just the PDC, a Windows client attempts to resolve the DOMAIN<0x1c> name. You can instruct nmbd to register this name (e.g., ORA<0x1c>) by setting the domain logons option in smb.conf. Our PDC's new global configuration looks like this:

 [global]     netbios name = STORK     workgroup = ORA     security = user     encrypt passwords = yes     ## enable PDC functionality     domain master = yes     domain logons = yes

It is not required that the PDC act as the local master browser, but most are configured to operate in this role as well. To achieve this, add the following browsing-related parameters to the global section. Review the previous chapter if you need a reminder regarding any of these three parameters.

     os level = 33     preferred master = yes     local master = yes

After making these changes, it is best to restart both smbd and nmbd. Wait approximately one minute for nmbd to complete its name registration process. Then use nmblookup to verify that both the 0x1c and 0x1b names have been claimed. It is normal to see more than one IP address when querying for the 0x1c name if you have one or more backup domain controllers configured on your network. In our case, we have only the PDC so far:

 $ nmblookup 'ORA#1b' 'ORA#1c' querying ORA on 192.168.1.255 192.168.1.88 ORA<1b> querying ORA on 192.168.1.255 192.168.1.88 ORA<1c>

You can also verify the name registration in nmbd's logfile. A successful logon server (0x1c) registration generates a log entry like the following.

 become_logon_server_success: Samba is now a logon server     for workgroup ORA on subnet 192.168.1.88

When configured as the DMB, nmbd logs this message:

 Samba server STORK is now a domain master browser for     workgroup ORA on subnet 192.168.1.88

9.2.1. Setting Up Domain Joins

Now that you have a working Samba DC, the next step is to add Windows clients to the domain. Before moving to that topic, however, let's go over some background on computer accounts.

When joining a domain, the client establishes a password known only to itself and the domain controller. This password is called the machine trust account password and is used to prove the identity of the computer each time it contacts the DC (normally upon booting). For security purposes, hosts running Windows 2000 and later require that you provide credentials for an administrative account that can potentially create the new machine account and assign it a random password.

Originally, Windows NT 4.0 allowed an administrator to create the client's machine trust account in advance using the Server Manager application. This new account was then assigned a predefined password based on the machine name. Therefore any user who knew the name could then join a computer to the domain.

The goal, then, is to complete the following tasks:

Create the Domain Admins group for the purpose of managing user rights.
Provide a set of users with administrative rights to join hosts to the domain.
Implement the infrastructure necessary to manage these machine accounts.

9.2.1.1. Domain Admins

Domain Admins is a special group in Windows domains. The group's RID is always 512. When a Windows client joins a domain, it adds this domain group to its local Administrators group. The result is that members of Domain Admins automatically gain administrative privileges on all domain members. Samba honors membership in the Domain Admins group as well, by granting all Domain Admins the ability to manage the user rights assignments necessary to authorize users to join hosts to the domain.^[*]

^[*] Remember to set enable privileges = yes in smb.conf.

Samba 3.0 does not currently support localized versions of the Domain Admins group name, such as the German name Domänen-Administratoren.

In order to create a group mapping entry for this special domain RID, you must first look up the SID of the ORA domain. You must be root for all the command examples in this section. Get the SID as follows:

 # net getlocalsid ORA SID for domain ORA is: S-1-5-21-3489264249-1556752242-1837584028

Now append the Domain Admins RID to the domain SID and create a group mapping entry for it:

 # net groupmap add sid=S-1-5-21-3489264249-1556752242-1837584028-512 \  ntgroup="Domain Admins" unixgroup=ntadmin Successfully added group Domain Admins to the mapping db

Now all members of the ntadmin Unix group will be seen as domain administrators by both Samba and Windows clients.

Depending on your version of Samba and which passdb has been configured, it may be necessary to use net groupmap's modify command instead of add. TRy add first, and then try modify if add fails.

9.2.1.2. Required privileges

Samba uses the SeMachineAccountPrivilege right to authorize a user or group to join a computer to the domain. Now is a good time to review the "User Privilege Management" section in Chapter 5 if you need a refresher on the net rpc rights command. Remember that new privilege assignments, like membership in a new group, are not applied to the user's token until the next session.

The best way to manage user rights is to assign a privilege to a group and then add the appropriate users to that group. In order to grant and revoke privileges, you must connect either as root or a member of the Domain Admins group. Our examples connect using the account cindy, who is a member of Domain Admins.

When a client joins a Samba domain, it performs the network equivalent of running pdbedit -a machinename. Normally, this type of request must be executed as root. But you can create a group mapping entry and assign it the SeMachineAccountPrivilege privilege to make smbd perform the account creation for members of this group as root.

Create the Server Admins Windows group based on the Unix group srvadmin and grant then the powers to manage users. The following commands create the group mapping entry and then (using the cindy account) assign the "Add machines to domain" right to the group:

 # net groupmap add unixgroup=srvadmin ntgroup="Server Admins" Successfully added group Server Admins to the mapping db # net rpc rights grant 'ORA\Server Admins' SeMachineAccountPrivilege \   -S stork -U cindy Password: <enter cindy's password> Successfully granted rights.

All Samba users must possess a matching Unix account. Therefore, Samba lets administrators create a matching Unix account at the time a host is joined to the domain. The add machine script option refers to an external utility that smbd invokes to generate the Unix account when it receives the network request to create a machine account. If the matching Unix account already exists, the script is ignored.

Because the process of creating users varies widely from one Unix platform to another, Samba does not include a default setting for this option. Usually it is possible to use some variant of a tool provided by the operating system.

The following example of a setting for add machine script comes from a Samba PDC running on Linux. The script invokes the useradd command to create the account referenced by the %u variable, assign its primary group membership to the hosts Unix group (which already exists), and set its login shell to /bin/false. Thanks to the login shell setting, the user cannot log in and cause any mischief on the Linux host; all she can do is access Samba files.

 add machine script = /usr/sbin/useradd -g hosts -s /bin/false '%u'

The ldapsam passdb supports a distinct search suffix for machine accounts. The ldap machine suffix works just like the ldap user suffix, but is intended for storing machine accounts. There is no harm in omitting this parameter. If no machine search suffix is defined, smbd falls back to the user search base. However, if you plan to use a separate subtree for storing machine accounts and are integrating the Samba attributes with the posixAccount object class, make sure that the server's LDAP NSS library can find both users and machines. This is commonly achieved by specifying multiple passwd search bases in the library's configuration file.

Table 9-1 gives a summary of the new smb.conf option presented in this section. In the next section we'll test the new configuration.

Table 9-1. The add machine script option
Parameter	Value	Description	Default	Scope
`add machine script`	string	Defines the external command to invoke when smbd must create a Unix user for a machine trust account.	`""`	Global

9.2.1.3. Joining a Windows client

The best way to understand how domain joins and the add machine script work together is to actually join a client to our domain. We'll use a Windows XP Professional client in the following examples. Remember from Chapter 3 that Windows XP Home Edition has been crippled to remove its domain join capabilities.

Begin by navigating to the System Properties dialog box. You can access this in several ways, but the one that works most consistently is to run control.exe sysdm.cpl from a command prompt or from the Run . . . option in the Start Menu. In the properties window, navigate to the Computer Name tab (called Network Identification in Windows 2000) and select Change (Properties in Windows 2000). The dialog boxes should appear similar to Figure 9-1. Here you can change the client's machine name or domain membership.

Figure 9-1. Computer Name Changes dialog on Windows XP

After entering the domain name ORA and clicking OK, you will be presented with a dialog box requesting credentials to join the domain (Figure 9-2). Continue to use the account details for cindy, because she is also a member of the srvadmin Unix group, which was granted the rights necessary to join hosts to the domain.

Figure 9-2. Entering credentials to join the domain

The Windows client then contacts the Samba PDC and uses these credentials to send the request to create the machine account and sets its password. If all of this succeeds, you will be greeted with the success message shown in Figure 9-3: "Welcome to the ORA domain."

Figure 9-3. Welcome message upon successful registration

There are a couple of places where this process can fail. The most common errors are:

Access Denied: The user account does not possess the sufficient privilege to join clients to the domain. Verify the account's assigned rights using net rpc rights.
Logon Failure: Ensure that you entered the user's password correctly.
The username could not be found: The add machine script failed to create the Unix account. Make sure that the script is functioning as expected. Clues to the root cause of the failure can be found in Samba's logfiles. For example, a typo in the primary group name when calling useradd might result in a message such as useradd: Unknown group hoss.

If you find an error not listed here, try increasing the Samba debug log levels to search for more clues and consider some of the techniques described in Chapter 12.

After a successful join and client reboot, you are able to select the domain when logging into the Windows console. Figure 9-4 displays the drop-down list of domains shown on our XP client. The local machine name MINK is present in the list, as is the ORA domain. The BOOKS domain is an Active Directory domain that is trusted by ORA. We examine domain trusts later in this chapter.

Figure 9-4. The Ctrl+Alt+Del logon dialog box showing a drop-down list of domains

9.2.2. Managing Users and Groups

The main purpose of a domain is to centralize authentication services. With this in mind, we turn our attention to users and groups. Traditionally, Windows administrators have used the User Manager for Domains application (sometimes referred to simply as usrmgr.exe ) to create, modify, and remove accounts within NT 4.0 domains. Windows NT 4.0 server administration tools such as usrmgr.exe can be found in the latest Windows NT 4.0 service pack from http://www.microsoft.com.

Neither the Windows 2000/XP local user tools such as lusrmgr.msc or the Active Directory domain tools support managing users and groups in Windows NT 4.0 equivalent domains.

Enabling remote account management support in Samba requires a few additional configuration pieces. Samba divides responsibilities between the list of accounts in its own passdb and those underlying Unix users and groups to which the passdb entries correspond. Samba continues to manage its own account attributes, but smbd requires help to manage these Unix identities just as it did for machine accounts. This is achieved through a collection of scripts defined in the global section of smb.conf that allow Samba to perform the following actions:

Create a new user (add user script)
Remove an existing user (delete user script)
Change the login name associated with a user (rename user script)
Create a new group (add group script)
Remove an existing group (delete group script)
Set a user's primary group (set primary group script)
Assign a secondary group to a user (add user to group script)
Remove a group from a user's list of supplementary groups (delete user from group script)

You'll notice that there is no parameter for renaming groups. The name stored in the group mapping table is handled by Samba independently of the Unix group name. When renaming a group, only the group map entry is updated.

Similar to our earlier discussion regarding machine accounts, creating a user or group is very platform-specific. Therefore, you must find a solution that works for your server. Following is one example of how to set up these scripts on a Linux server. The following list of configuration parameters makes use of the tools in the pwdutils package included with Novell's SuSe Linux. However, such values should be portable across most Linux distributions. The %u and %g variables are expanded to the user and group names sent in the client's request.

 [global]     add user script = /usr/sbin/useradd -m '%u'     delete user script = /usr/sbin/userdel '%u'     rename user script = /usr/sbin/usermod -l '%unew' '%uold'     add group script = /usr/sbin/groupadd '%g'     delete group script = /usr/sbin/groupdel '%g'     add user to group script = /usr/sbin/groupmod -A '%u' '%g'     delete user from group script = /usr/sbin/groupmod -D '%u' '%g'     set primary group script = /usr/sbin/usermod -g '%g' '%u'

These commands are fairly intuitive and do what you would expect. For example, useradd creates the Unix user, and usermod can be used to rename an account. More information on the specifics of useradd and other account management tools can be found in the server operating system's manpages.

The smbldap-tools package included in the /examples/LDAP subdirectory of the Samba source distribution is a set of user management scripts for hosts configured to use the ldapsam passdb backend. They assume a certain namespace and layout within the LDAP DIT. More information can be found at http://samba.idealx.org.

Once this infrastructure is in place, any user possessing the SeAddUsersPrivilege on the server can create and modify accounts directly from a Windows desktop. Don't be confused by the name. This privilege that purports to "Add users and groups to the domain" can also modify existing accounts. The following command allows members of Server Admins to manage users and groups:

 # net rpc rights grant 'ORA\Server Admins' SeAddUsersPrivilege \   -S stork -U cindy Password: <enter cindy's password> Successfully granted rights.

When run on a Windows 2000/XP/2003 host, a bug in User Manager for Domains prevents it from being able to manipulate user rights on a Samba (or Windows NT 4.0) DC. For this reason, it is recommended that you always use net rpc rights to manage privilege assignments on Samba hosts.

Commands that grant privileges are cumulative. You can review the list of privileges assigned to a user or group using the net rpc rights list command. The following command anonymously (through the -U% option) enumerates the rights possessed by the Server Admins group:

 # net rpc rights list accounts 'ORA\Server Admins' -U% -S stork SeMachineAccountPrivilege SeAddUsersPrivilege

Now launch User Manager for Domains. You will be greeted with a list of users and groups and should be able to match the output from pdbedit -L -w to the list of users and the output from net groupmap list to the list of groups. Figure 9-5 shows the users and groups in the ORA domain. The following commands confirm that the list of accounts matches what is reported from Samba's own tools. The output has been trimmed to list solely the user and group names for easier reading. Also notice that the machine accounts (ones ending with a dollar sign) are not listed by User Manager, which filters them from the display.

 # pdbedit -L -w | cut -d: -f 1 KNOT$ DORN$ POLE$ MINK$ jerry BOOKS$ lizard STORK$ cindy # net groupmap list | cut -d \( -f 1 Printer Admins staff Domain Users Server Admins helpdesk Administrators Linux Users Domain Admins Users

Figure 9-5. Users and groups in the ORA domain

You can launch the New User dialog from the the User menu. Figure 9-6 shows the creation of a new account named mark; Figure 9-7 illustrates how to manage mark's group membership.

Figure 9-6. Creating a new user named mark

Figure 9-7. Managing a user's group membership

After adding the new account, verify that it was created by examining /etc/passwd and Samba's passdb. The new Unix account should be present in the system passwd file:

 $ grep mark: /etc/passwd mark:x:10026:1008::/home/mark:/bin/bash

The output from pdbedit also confirms the new Samba account:

 # pdbedit -L -w mark mark:10026:01FC5A6BE7BC6929AAD3B435B51404EE:0CB6948805F797BF2A82807973B89537: [U]:LCT-44D8C4C1:

If you observe any failures in usrmgr.exe , the troubleshooting tips for resolving domain join failures, described in Chapter 10, apply to managing users. Verify that the connected user has been granted the appropriate level of privileges and scan the Samba logfiles for more information regarding the reason for the failure.

After remote account management has been enabled, you can also use the net rpc user and net rpc group commands covered in Chapter 11 to manage your Samba DC.

Table 9-2 provides a brief listing of the account management parameters introduced in this section.

Table 9-2. User and group management options
Parameter	Value	Description	Default	Scope
`add group script`	string	External command to invoke when smbd must create a Unix group.	`""`	Global
`add user script`	string	External command to invoke when smbd must create a Unix user.	`""`	Global
`add user to group script`	string	External command to invoke when smbd must add a group to a user's list of secondary groups.	`""`	Global
`delete group script`	string	External command to invoke when smbd must remove a Unix group.	`""`	Global
`delete user script`	string	External command to invoke when smbd must delete a Unix user.	`""`	Global
`delete user from group script`	string	External command to invoke when smbd must remove a group from a user's list of secondary groups.	`""`	Global
`rename user script`	string	External command to invoke when smbd must rename a Unix user. The old name is expanded from `%uold` and the new name is expanded from `%unew`.	`""`	Global
`set primary group script`	string	External command to invoke when smbd must change a Unix user's primary group membership.	`""`	Global

9.2.3. User Profiles

User roaming profiles, sometimes called roving profiles, provide a way for a domain user to customize elements of his environment such as the desktop wallpaper, application defaults, and desktop shortcuts. Such profiles give users a more "at home" feeling when they move from machine to machine. Figure 9-8 displays the User Environment Profile setting dialog box provided by usrmgr.exe. With the exception of the Terminal Server settings, we'll discuss each one of these fields shortly.

Figure 9-8. The User Environment Profile dialog box in User Manager for Domains

Our focus is on making a Samba DC support Windows user profiles, not on Windows-specific tasks such as editing the registry or updating shortcuts. More information on these topics can be found in the plethora of currently available Windows administration books and online articles. A definitive guide to user profiles can be found in the white paper titled "Implementing Policies and Profiles for Windows NT 4.0," available through a search at http://www.microsoft.com.

First it is important to understand exactly what composes a user profile. Roughly speaking, a profile is a collection of application settings. Some of these settings may be stored in the user's registry hive (NTUSER.DAT), and others may be stored as files on disk. The following is a list of the top-level files and directories composing a Windows XP user profile:

 $ ls -l total 880 drwx-----T+ 5 cindy helpdesk   4096 Aug  8 13:33 Application Data drwx-----T+ 2 cindy helpdesk   4096 May 21 20:52 Cookies drwx-----T+ 2 cindy helpdesk   4096 May 21 15:26 Desktop drwx-----T+ 3 cindy helpdesk   4096 Aug  6 16:32 Favorites drwx-----T+ 4 cindy helpdesk   4096 Aug  6 16:32 My Documents -rwx------  1 cindy helpdesk 786432 Aug  8 14:20 NTUSER.DAT drwx-----T+ 2 cindy helpdesk   4096 May 21 15:26 NetHood drwx-----T+ 2 cindy helpdesk   4096 May 21 15:26 PrintHood drwx-----T+ 2 cindy helpdesk   4096 Aug  8 12:07 Recent drwx-----T+ 2 cindy helpdesk   4096 Aug  6 16:31 SendTo drwx-----T+ 3 cindy helpdesk   4096 May 21 15:26 Start Menu drwx-----T+ 2 cindy helpdesk   4096 May 21 20:42 Templates -rwx------  1 cindy helpdesk   1024 Aug  8 14:20 ntuser.dat.LOG -rwx------  1 cindy helpdesk    328 Aug  8 14:22 ntuser.ini

Storing per-user settings on a central file server can provide several benefits to administrators. For example, new machines can be deployed without worrying about having to transfer the user's customized environment from one host to another. If all of the user's documents and files are stored on a network file share as well, machines can practically be swapped out at will. Additionally, a profile can be updated while the user is offline and have the changes appear at the next logon. Useful examples of this are adding shortcuts to the Start Menu or editing application settings found in the NTUSER.DAT registry hive.

One oddity surrounding Windows and the registry is that clients refuse to load a binary registry file, for example NTUSER.DAT, if the DOS ReadOnly bit is set on the file. The only clue as to the cause of the failure is that Windows reports that the registry file is corrupt, when in fact it is perfectly fine. This applies both to user profiles and system policy files (covered in the next section).

To support roaming profiles, your server needs to dedicate a file share to storing these per user settings, and you must inform the Windows clients of this share so that the user profile can be download at logon time. The following excerpt from smb.conf uses the logon path parameter to specify the location of the user's roaming profile.

The %U variable is used to separate profiles based on username. The %a variable is used to separate the profiles based on client OS. This is important, because a profile created by Windows 2000 may not be 100% compatible with one created by Windows XP. The [profile$] share is a normal file share. The trailing $ is included to prevent the share from being displayed by Windows client when browsing the server. You could have disabled the browseable parameter to achieve the same effect.

 [global]     logon path = \\STORK\profile$\%U\%a [profile$]     comment = User roaming profiles     path = /data/profiles     read only = no     inherit permissions = yes

Each user must be able to write to a subdirectory matching his login name in /data/profiles (i.e., /data/profiles/mark). One way to meet this requirement is to create the top-level directory before the user first logs on. It is also a good idea to prevent other users from accessing a profile other than their own. Run the following commands as root to create the necessary profile directory for the user mark:

 # mkdir -p /data/profiles/mark # chown mark  /data/profiles/mark # chmod 700 /data/profiles/mark

Windows itself will handle creating the directory based on the %a value. Here is the profile directory for a user who has logged on to clients running various operating systems:

 $ ls -l total 16 drwx------  14 cindy helpdesk 4096 Aug  6 21:18 Win2K drwx------  13 cindy helpdesk 4096 Jul 22 10:23 Win2K3 drwx------  15 cindy helpdesk 4096 Aug  6 17:29 WinNT drwx------  13 cindy helpdesk 4096 Aug  8 12:02 WinXP

Roaming profiles can be disabled by setting the logon path to an empty string.

 logon path = ""

In addition to a roaming environment, it is beneficial to provide users with a private network file share in which to store data. Personal files, along with application settings, can then follow a user from machine to machine. Windows connects to the user's home directory automatically if you define the logon home parameter in smb.conf. The driver letter used by in the connection is controlled by the logon drive option. The following example connects the home directory (\\STORK\username) to the H: drive:

 [global]     logon home = \\STORK\%U     logon drive = H: [homes]     comment = Home directory for %U     read only = no     valid users = %S

In spite of the default values, it is recommended that you never store users' profiles in their home directories. It is too easy to lose data when the profile is copied from the Windows client back to the network file share.

You may wish to do more when a user logs on than just connect her to a home directory. The logon script parameter points to a Windows batch file that is run on the client when a user logs on. The script value is the DOS path to the batch file relative to the root of the [netlogon] share. For example, to run a script based on the user's primary group, set the following in smb.conf:

 [global]     logon script = %G.bat

For a user whose primary group is ntadmin, smbd will expand the %G before sending the UNC path \\stork\netlogon\ntadmin.bat to the client. Frequently, the logon script is configured to point to a master batch file that performs certain actions based on the user's group membership. The ifmember.exe tool included in the Windows Server 2003 resource kit allows you to test for membership in a group and perform a specific action if the test succeeds. Other more power-scripting languages such as Perl or Python may be used as well, but these must be invoked from the original batch file.

Batch files should be in DOS text. There are many methods and tools to do this. The simplest is to find an editor that supports DOS text. Other methods of converting Unix text files to a DOS format are covered in Chapter 11.

Table 9-3 summarizes the user profile parameters discussed in this section.

Table 9-3. User profile options
Parameter	Value	Description	Default	Scope
`logon drive`	string	The drive letter that a Windows client should use when connecting to the user's home directory.	`""`	Global
`login home`	string	The UNC path to the user's home directory.	`\\%N\%U`	Global
`login path`	string	The UNC path to the user's roaming profile.	`\\%N\%U\profile`	Global
`login script`	string	The DOS path (relative to the root of the `[netlogon]` share) to a batch file that will be executed on the client when a user logs on.	`""`	Global

9.2.4. System Policies

A Windows NT 4.0 system policy file, usually named ntconfig.pol and stored in the [netlogon] share, is a collection of registry settings used to enforce specific settings on client machines and users or groups. NT 4.0 system policies are very different from AD Group Policy Objects. The latter is a feature of Active Directory and not supported by Samba's current domain controlling capabilities.

Figure 9-9 displays the Windows NT 4.0 Policy Editor (included in the latest Windows NT 4.0 Service Pack). The dialog box shows specific policy objects for the Server Admins group, the user mark, and the computer mink. If a user or host does not match any of the specific policies, the default user or default computer policy will be applied.

Figure 9-9. The User Environment Profile dialog box in User Manager for Domains

System policies are retrieved by the client as part of the user logon process. By default, the client searches the [netlogon] share for a file named ntconfig.pol and then attempts to merge this file with either the HKEY_LOCAL_MACHINE or the HKEY_CURRENT_USER registry hive, depending on the type of policy object.

You can accomplish a lot with system policies. Figure 9-10 illustrates a few user settings that can be managed via policy settings. This example highlights settings such as restricting screen locks and excluding certain directories from being synchronized as part of the user's roaming profile.

Figure 9-10. User system policy settings

The Microsoft white paper "Implementing Policies and Profiles for Windows NT 4.0," mentioned in the context of roaming user profiles, is also an excellent source of information for system policies. It might also be helpful to read MS Knowledge Base article 225087, "Writing Custom ADM Files for System Policy Editor."