3    Domain User Accounts and Groups

By default, a user must be authenticated by Windows NT and Tru64 UNIX security policies when they request access to shares. Therefore, users who access shares must have the following:

A domain user account and Tru64 UNIX user account contain information about the user, including name, password, and other information that a security system uses to authenticate a user.

This chapter describes:

See the ASU Installation and Administration Guide for information on creating domain user accounts and groups.

3.1    Domain User Accounts

A domain user account contains information that defines a user in an Advanced Server domain.

Table 3-1 describes the elements of a domain user account.

Table 3-1:  Domain User Account Elements

Account Element Description

User name

The unique name that the user types when logging on.

Full name

The user's full name.

Description

Text describing the user or user account.

Password

The user's password. See Table 3-2 for setting password options.

Logon hours

The hours during which the user can log in to the domain. See Section 3.1.1 for more information about setting Logon Hours.

Whether or not users are forced to log off when their logon hours expire is defined by the Forcibly Disconnect Remote Users From Server When Logon Hours Expire option in the domain's account security policy. See Section 2.5.3.1 for more information about setting domain account security policy.

Logon workstations

The computer names of workstations from which a user can log in to the domain. By default, the user can log in from any workstation.

Expiration date

A future date when the account automatically becomes disabled; it is useful to ensure that accounts for temporary employees or students are not kept active unnecessarily.

Logon script

A batch file or executable file that runs automatically when the user logs on. See Section 3.1.2 for more information.

Home directory

A directory that is private to the user. See Section 3.1.3 for more information.

Profile

The path to a folder containing information that is retained to create the user's desktop environment, such as program groups, network connections, and screen colors. See Section 3.1.4 for more information.

Account type

Account type is either global or local. Most accounts you create will be global accounts.

Table 3-2 describes the options that you can use to control a user's password.

Table 3-2:  Domain User Account Password Options

Option Description

User Must Change Password at Next Logon

Whether or not the user will be forced to change their password the next time they log in to the domain.

This option is defined by the Maximum Password Age option in the domain's account security policy. See Section 2.5.3.1 for more information about setting domain account security policy.

User Cannot Change Password

Whether or not the user can change their password. This restriction is useful for shared accounts. It does not apply to administrators.

Password Never Expires

Whether or not the user's passwords expires. This is used for accounts that represent services such as the Replicator service. It also is useful for accounts for which you never want the password to change, such as guest accounts.

Account Disabled

Whether or not the account is disabled and cannot be used to log on. Although the account is not removed from the directory database, the user cannot log in to the domain until the account is enabled.

A domain user account includes a security identifier (SID), a unique number that identifies the account. Every account on your network is issued a unique SID when the account is created. Internal processes refer to an account's SID rather than the account's user name. If you create an account, delete it, and then create an account with the same name, the new account will not have the rights or permissions that previously were granted to the old account because the accounts have different SID numbers. Renaming a user account retains the SID.

3.1.1    Specifying Logon Hours

By default, users can connect to the ASU server 24 hours a day, seven days a week; however, you can restrict access.

When a user is connected to a controller and the logon hours are exceeded, the user either will be disconnected from all server connections or will be allowed to remain connected but denied any new connections, depending on if you enabled the Forcibly Disconnect Remote Users From Server When Logon Hours Expire option. See Section 2.5.3.1 for more information on setting this option.

You specify the logon hours for a user by using the following:

Note

The logon hours are in the time zone of the PDC, not in the time zone of the workstation or server to which the user is logging on or connecting.

3.1.2    Logon Script

A logon script is an executable or batch file that contains commands that automatically run when a user logs on to a system on which the ASU server is running. Logon scripts are used to automatically configure users' working environments, such as making network connections and starting applications.

The best way to ensure that logon scripts always are available is to use the Replicator service. The Replicator service maintains identical copies of a directory tree on multiple controllers. When you make a change to a file in the master copy of the tree (located on the export server), the Replicator service automatically copies the change to the import controllers.

3.1.2.1    Creating a Logon Script

You create logon scripts by using a text editor, then using the Replicator service to distribute the logon scripts to domain controllers.

When using the Replicator service, the ASU server searches for logon scripts in the /usr/net/servers/lanman/shares/asu/repl/import/scripts directory on import servers and in the /usr/net/servers/lanman/shares/asu/repl/export/scripts directory on export servers. If you do not use the Replicator service, you must make sure that the logon scripts are in the same directory on each controller because any controller can validate the logon request, then execute the logon script. See Section 4.2 for more information on directory replication.

Table 3-3 describes special parameters that you can use when creating logon scripts.

Table 3-3:  Logon Script Parameters

Parameter Description
%HOMEDRIVE% The user's local workstation drive letter connected to the user's home directory
%HOMEPATH% The full path of the user's home directory
%HOMESHARE% The name of the share containing the user's home directory
%OS% The operating system of the user's workstation
%PROCESSOR_ARCHITECTURE% The processor type of the user's workstation
%PROCESSOR_LEVEL% The processor level of the user's workstation
%USERDOMAIN% The domain containing the user's account
%USERNAME% The domain user name

3.1.2.2    Assigning a Logon Script

You assign a logon script to a domain user account by using the following:

3.1.3    Home Directory

A user's home directory is a directory that is accessible to the user and contains files and programs for that user. When a user logs on at a workstation, a connection is made automatically to that user's home directory; this becomes that user's default directory for the File Open and Save As dialog boxes, for the command prompt, and for all applications that do not have a working directory defined. By default, when you create a domain user account, the ASU server creates a home directory for the user in the /usr/users directory using the user's Tru64 UNIX account name.

If you do not specify a home directory, the default home directory is the \USERS\DEFAULT directory on the user's local drive.

Because home directories collect user files in one location, they make it easy for an administrator to back up user files and delete user accounts.

3.1.3.1    Assigning Home Directories

You assign a home directory to a user account by using the following:

If you specify a home directory on a controller and it does not exist, it is created. If you specify a directory on the user's local system and it does not exist, it is not created.

In the Home Directory box, %USERNAME% can be substituted for the last entry in the path. The system later substitutes the user name of the domain user account. This substitution is useful when multiple domain user accounts are selected. For example, you have selected eight domain user accounts. In the Home Directory box, you might select Connect, specify a drive letter of K, select the To box, and type \\SALES\home\%username%. When you choose OK to save the User Environment Profile, the actual user name will be substituted for each %USERNAME% entry.

When a domain user account is copied, the home directory is copied in one of the following two ways:

3.1.4    User Profile

A user profile defines the work environment settings that are set when a user logs into a domain. These settings include all the user-specific settings of a user's Windows environment, such as which options in Control Panel they can use, screen colors, share connections, mouse settings, shortcuts, window size, and position.

Types of user profiles include the following:

User profiles are available on computers running Windows 95; however, a user profile created on Windows 95 is not available to the user on a computer running the ASU server or Windows NT, even if the user profile is stored on these systems.

3.1.4.1    Creating a User Profile

You use the System Policy Editor to create a user profile. The System Policy Editor is a Windows based interface that you can use to view and manage policies that define the environment for specific Windows computers, users, or groups when logged in to a domain.

Using the System Policy Editor you can set the following:

The System Policy Editor saves settings in a policy (.POL) file. When a user logs in, a program called the policy downloader starts. The policy downloader is installed on every Windows client. The policy downloader looks on the network for the policy file, opens the policy file, looks for an entry using the local computer name or user name, and merges the administrator's registry settings as defined in the policy file into the local registry. If the downloader does not find an entry with the local computer name or user name in the policy file, then it looks for the DEFAULT USER or DEFAULT COMPUTER entry and uses those registry settings for the merge. If there are no entries for a specific user or computer and default entries do not exist, then no merge takes place.

See the ASU Installation and Administration Guide for more information about the System Policy Editor.

3.1.4.2    Assigning Profiles

You assign a profile to a domain user account by using the following:

3.1.5    Managing the User Rights Policy

A right authorizes a user to perform certain actions on a computer system, such as backing up files and directories, logging on to a computer interactively, or shutting down a system. Rights exist as capabilities for using either domain controllers at the domain level or workstations or member servers at the local level. Rights can be granted to domain user accounts or groups.

A user who logs on to a domain user account or belongs to a group to which the appropriate rights have been granted to perform actions can carry out the actions. When a user does not have appropriate rights to perform an action, an attempt to carry out that action is blocked by the ASU server.

Rights apply to the system as a whole and are different from permissions, which apply to specific objects. A permission is a rule associated with an object (usually a directory, file, or printer), and it regulates which users can have access to the object and in what manner. Most often the creator or owner of the object sets the permissions for the object. However, because all rights are not associated with a specific object and are applied at the domain (domain controllers) or local (workstation or member server) level, they sometimes can override permissions set on an object. For example, a user logged on to a domain account that is a member of the Backup Operators group has the right to perform backup tasks for all servers of the domain. Doing so requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A right, in this case, the right to perform a backup, takes precedence over all file and directory permissions.

Table 3-4 describes user rights. See Section 4.1 for more information about permissions.

Table 3-4:  User Rights

User Right Allows
Access this computer from network Connecting over the network to a controller. This right cannot be revoked from the Administrator's local group.
Add workstations to domain Adding a workstation to the domain, allowing the workstation to recognize the domain's user accounts and global groups and those of trusted domains.
Back up files and directories Backing up files and directories and reading of all files. This right supersedes file and directory permissions, and also applies to the Registry.
Change the system time Setting the time for the internal clock of a controller.
Force shutdown from a remote system This right is not currently implemented. It is reserved for future use.
Load and unload device drivers Installing and removing device drivers.
Log on locally Logging on locally at the controller.
Manage auditing and security log Specifying what types of share access (such as file access) are to be audited. Viewing and clearing the security log. This right does not allow a user to set system auditing. This ability is held only by the Administrators group.
Restore files and directories Restoring (writing) files and directories. This right supersedes file and directory permissions, and also applies to the Registry.
Shut down the system Shutting down the controller.
Take ownership of files or other objects Taking ownership of files, directories, and other objects on a controller.

3.1.5.1    Assigning User Rights

You assign rights to a domain user account by using the User Manager for Domains and selecting Policies, then User Rights.

When you assign user rights for a domain, the rights apply to all the controllers. When you administer user rights on a workstation or member server, the rights apply only to the workstation or member server.

3.1.6    Built-in Domain User Accounts

Two built-in user accounts are created automatically when you install the ASU software:

3.1.6.1    Built-in Administrator User Account

The built-in Administrator account is allowed to perform domain management tasks on a controller, workstation, or member server that belongs to that domain.

When you install the ASU software you are prompted for a password to the built-in Administrator account. This password should be guarded carefully because if the password is forgotten or the person who knows the password becomes unavailable, the built-in Administrator account is unusable. The password can be changed and it does not expire.

The built-in Administrator account can never be deleted or disabled. This feature distinguishes the Administrator account from other members of the Administrators local group.

Following installation of the ASU software, you should create additional administrative accounts with administrative-level capabilities, while reserving the built-in Administrator account for emergency purposes. When administrative users have separate accounts, their actions can be audited on an individual user account basis rather than trying to audit the built-in Administrator account.

See the ASU Installation and Administration Guide for information about installing the ASU software. See Chapter 6 for information about auditing.

3.1.6.2    Built-in Guest User Account

The built-in Guest account can be used by a user who needs to log in to the domain, but does not have a domain user account in the domain or in a trusted domain. A user whose account is disabled (but not deleted) also can use the Guest account.

The Guest account is disabled by default, does not require a password, and has no predefined rights or permissions in the domain however, you can set a password and rights and permissions for the Guest account like any other domain user account.

There are two types of guest logons as follows:

3.1.6.2.1    Enabling the Guest Account

You enable the Guest account on each controller by using the following:

3.2    Tru64 UNIX User Accounts

By default, the Tru64 UNIX operating system software authenticates a user before they can access a file system or printer that is assocated with a share.

By default, when you create a domain user account, a Tru64 UNIX user account is automatically created in the local /etc/passwd file if an account with the same name does not exist. The Tru64 UNIX operating system software uses this account to authenticate the user. However, you can configure the Tru64 UNIX operating system software to send authentication requests to a network information service (NIS), a Windows 2000 Server, or to a Windows NT Server Version 4.0. The NIS, Windows 2000 Server, or Windows NT Server Version 4.0 uses the information in its user account database to authenticate users on behalf of the Tru64 UNIX operating system software and sends the results back. This is useful if you have a user account database on a NIS, Windows 2000 Server, or on a Windows NT Server Version 4.0 and you do not want to create a user account database on the Tru64 UNIX system.

See the ASU Installation and Administration Guide for more information on configuring user account authentication.

3.2.1    Associating Domain User Accounts to Tru64 UNIX User Accounts

By default, a domain user account is associated with a Tru64 UNIX user account. This association allows your Tru64 UNIX files to be owned by your Tru64 UNIX system user account and to be accessed by the domain user account. Domain user accounts that are not mapped to a specific Tru64 UNIX user account are mapped by default to the lmworld Tru64 UNIX user account.

The Tru64 UNIX user account name that is assigned to the domain user account will be the same as or similar to the domain user account name. Differences can arise in cases of long, duplicate, or special character user account names. If a domain user account user is associated to a non-existent Tru64 UNIX user account, or if the Tru64 UNIX user account for the user is deleted, the user will not have access to any shares.

You use the mapuname command to control the association of domain user accounts to Tru64 UNIX user accounts. The default relationship between domain user accounts and Tru64 UNIX user accounts is controlled by values assigned to user-related registry value entries in the ASU registry.

See the ASU Installation and Administration Guide for more information about the ASU registry.

3.3    Grouping Domain User Accounts

To ease administration, you can group domain user accounts and administer the group as one unit. Domain user accounts added to a group become members of the group and immediately acquire the rights and permissions granted to the group. Changes made to the group affect each member. Group membership provides an easy way to grant common capabilities to sets of users.

There are the following three types of groups:

3.3.1    Local Groups

A local group contains domain user accounts and global groups from the local domain and from domains that it trusts. A local group cannot contain other local groups. Table 3-5 describes the built-in local groups.

Table 3-5:  Local Groups

Group Description

Administrators

Members are automatically granted every built-in right and ability to manage the domain and controllers.

By default, the Domain Admins global group is a member of the Administrators local group.

Users

Members have normal user access to and capabilities for the domain.

By default, the Domain Users global group is a member of the Users local group.

Guests

Members have no rights on controllers. However, they do have certain rights at their individual workstations.

By default, the Domain Guests global group is a member of the Guests local group.

Account Operators

Members can create, modify, and delete most domain user accounts and groups, log on to and shut down domain controllers, and add controllers or member servers to a domain.

Members cannot administer security policies, modify or delete the Domain Admins global group, the Administrators, Account Operators, Backup Operators, Print Operators, or Server Operators local groups, any global groups belonging to these local groups, or accounts of members of any of these groups.

Backup Operators

Members can back up and restore files on a PDC and BDCs.

Print Operators

Members can create, delete, and manage printer shares on the domain's controllers and can shut down these controllers.

Server Operators

Members can create, delete, and manage shares and change the system time.

Replicator

Members can mange the Replicator service of the PDC and the BDCs in the domain. See Chapter 4 for information about directory replication.

Not all built-in local groups exist on ASU servers, Windows NT servers, Windows NT workstations, and member servers. Table 3-6 identifies which built-in local groups exist on ASU servers, Windows NT servers, Windows NT workstations, and member servers.

Table 3-6:  Built-in Local Groups

ASU Servers and Windows NT Servers Windows NT Workstations and Member Servers
Administrators Administrators
Users Users
Guests Guests
Account Operators Backup Operators
Backup Operators Replicator
Print Operators Power Users
Server Operators  
Replicator  

3.3.2    Global Groups

A global group contains domain user accounts from the domain in which it is created. A global group cannot contain local groups, other global groups, or domain user accounts from other domains. You can add a global group to local groups in the same domain, to domains that trust that domain, or to member servers or computers running Windows NT Workstation in the same or a trusting domain. You can grant a global group permissions and rights in its own domain, on workstations or member servers, or in trusting domains. You cannot create a global group on a computer running Windows NT Workstation or on computers running as a member server.

Table 3-7 describes the built-in global groups. These groups cannot be deleted.

Table 3-7:  Global Groups

Group Description

Domain Admins

Members can administer the domain, the controllers and workstations of the domain, and a trusting domain that has added the Domain Admins global group from this domain to the Administrators local group in the trusting domain. Only Administrators can modify the Domain Admins global group.

The built-in Administrator user account is a member of the Domain Admins global group. The Domain Admins global group is a member of the Administrators local group. To provide a domain user account with administrative-level capabilities, add the account to the Domain Admins global group.

Domain Users

Members have normal user access to and capabilities for the domain and the computers in the domain running Windows NT Workstation and Windows NT Server as a member server. Only Administrators and Account Operators can modify the Domain Users global group.

The built-in Administrator user account is a member of the Domain Users global group. By default, all new domain user accounts created in the domain are added to the Domain Users group, unless you specifically remove them.

The Domain Users global group is a member of the Users local group for the domain and of the Users local group for every computer in the domain running Windows NT Workstation or member servers running Windows NT Server.

Domain Guests

Members have no rights on controllers.

The built-in Guest user account is a member of the Domain Guests global group. The Domain Guests global group is a member of the Guests local group.

Add user accounts that are intended to have more limited rights and permissions than typical domain user accounts to the Domain Guests group and remove them from the Domain Users group. Only Administrators and Account Operators can modify the Domain Guests global group.

3.3.3    Special Groups

Table 3-8 describes the other groups that used for special purposes. Because the memberships of these groups cannot be altered, the groups are not listed in User Manager for Domains.

When you administer the ASU server, these special groups sometimes appear in the list. For example, they can appear when assigning permissions to shares and files.

Table 3-8:  Special Groups

Group Description

Everyone

Members include all local and remote users (that is, the Interactive and Network groups combined).

In a domain, members can access the network and connect to disk and printer shares.

Interactive

Members include anyone using the computer locally.

Network

Members include users connected over the network to the computer.

System

Members include the operating system.

Creator Owner

Members include users who create a subdirectory, file, or print job. For a directory, if permissions are granted to the Creator Owner group, the creator of a subdirectory or file will be granted those permissions for that subdirectory or file. For a printer, if permissions are granted to the Creator Owner group, the creator of a print job will be granted those permissions for that print job.

3.3.4    Strategies for Using Groups

Some rights are only provided to users who are members of a specific group. For example, the only way to allow a person to create domain user accounts is to add that person's domain user account to either the Administrators or Account Operators local group on the domain.

You can add a user to more than one built-in group. For example, a user in both the Print Operators and Backup Operators groups has all the rights granted to Print Operators and all the rights granted to Backup Operators.

In a domain, rights are granted and restricted on the domain level; if a group has a right in a domain, its members have that right on all the controllers in the domain. On member servers, rights granted apply only to that computer.

In a multiple-domain setting, you can think of global groups as a means of adding users to the local groups of trusting domains. To extend users' rights and permissions to resources on other domains, add their accounts to a global group in your domain and then add the global group to a local group in a trusting domain.

Even if you maintain a single domain, keep in mind that additional domains may be added in the future. You can use global groups added to local groups for granting all rights and permissions. Later, if another domain is created, the rights and permissions assigned to your local groups can be extended to a new domain's users by creating a trust relationship and adding global groups from the new domain to your local groups. Likewise, if the new domain trusts your domain, your global groups can be added to the new domain local groups.

Domain global groups also can be used for administrative purpose on computers running Windows NT Workstation or on member servers running Windows NT Server. For example, the Domain Admins global group is added by default to the Administrators built-in local group on each workstation or member server that joins the existing domain. Membership in the workstation or member server local Administrators group enables the network administrator to manage the computer remotely by creating program groups, installing software, and troubleshooting computer problems.

Most network administrators have dual roles. They are both administrators and users of the network. A network is more secure if an administrator uses two domain user accounts. One of these accounts should be in the Domain Admins global group and should be used to perform network management tasks and the other account should be in the Domain Users global group and should be used at all other times. While logged on as a regular user, an administrator cannot inadvertently change aspects of the network that only administrators can change. And, if an administrator were to accidentally introduce a virus, the program would not have the rights of an administrator and would not modify the operating system.

Table 3-9 provides some guidelines for using global and local groups:

Table 3-9:  Group Guidelines

Purpose of Group Use Comments
To group users of a domain into a single unit for use in other domains or user workstations Global The global group can be put into local groups or given permissions and rights directly in other domains.
To group users who need permissions and rights only in one domain Local The local group can contain users and global groups from this and other domains.
To group users who need permissions on computers running Windows NT Workstation or on member servers Global A domain's global groups can be given permissions on these computers, but a domain's local groups cannot.
To contain other groups Local The local group can contain global groups and users; however, no group can contain other local groups.
To group users from multiple domains Local The local group can be used in only the domain in which it is created. If you need to be able to grant this local group permissions in multiple domains, you must create the local group in every domain in which you need it.

3.3.5    Managing Groups

A group name must be unique to the domain or to the computer being administered. A global group name can contain up to 20 characters. A local group name can contain up to 256 characters. A group name can contain any uppercase or lowercase alphanumeric characters.

When a group name is displayed and when the distinction is necessary, the ASU server identifies the domain or workstation the group is from by displaying the group name in the form DOMAINNAME\groupname or COMPUTERNAME\groupname. For example, a group named Managers from a domain named Engineering would be displayed as ENGINEERING\Managers.

You can copy a group or create one. By copying, you ensure that the new group has the same members as the original group. However, the permissions and rights of the original group are not copied to the new group.

A group includes a security identifier (SID), a unique number that identifies the group. Every group on your network is issued a unique SID when the account is first created. Internal processes refer to a group SID rather than the group name. If you create a group, delete it, then create a group with the same name, the new group will not have the rights or permissions that previously were granted to the old group because the new group will have a different SID. Renaming a group retains the SID. Groups that you create can be deleted, but the built-in groups cannot. Deleting a group removes only that group; it does not delete the domain user accounts or global groups that are members of the deleted group.