Previous | Contents | Index |
A logon script is an executable or batch file composed of Advanced Server and operating system commands that runs automatically when a user logs on to the network. Logon scripts are used to configure users' work environments, make network connections, and start applications. They also can be used to run programs that scan for computer viruses on local workstations.
Advantages to using logon scripts include:
To assign a user a logon script, specify the path name of the logon script file in the user's account profile. Then, when the user logs on, the logon script downloads and runs. You can assign a different logon script to each user or create logon scripts for use by multiple users. For more information on user profiles, see Chapter 3, User Accounts.
The path name that you specify in the user's account profile is relative to the logon script path of the computer on which the script is stored. For example, if PWRK$LMROOT:[LANMAN.REPL.IMPORT.SCRIPTS] is the computer logon script path and PWRK$LMROOT:[LANMAN.REPL.IMPORT.SCRIPTS]cristalw.bat is the script for CristalW, then you need to specify only cristalw.bat as the logon script path name in CristalW's account profile.
To create a logon script, simply create an MS-DOS batch file. Table 2-1 describes several special parameters that you can use when creating logon scripts.
Parameter | Description |
---|---|
%HOMEDRIVE% | The letter for the local workstation drive connected to the user's home directory |
%HOMEPATH% | The full path name of the user's home directory |
%HOMESHARE% | The share name containing the user's home directory |
%OS% | The operating system of the user's workstation |
%PROCESSOR% | The processor type (such as 80386) of the user's workstation |
%USERDOMAIN% | The name of the domain containing the user's account |
%USERNAME% | The user's user name |
A logon script always downloads from the server that validates the
user's logon request. To ensure that logon scripts always work, be sure
that logon scripts for all user accounts in a domain exist on every
server in the domain that validates logon requests.
2.6.2 Tips for Using Home Directories
Home directories can serve as private storage spaces for users. Users can control access to their home directories and can restrict or grant access to other users.
The home directory can be a local path on the server or a remote path located on another server on the network. If users have home directories on computers other than their own workstations, connections are made automatically to their home directories at every logon from a Windows NT workstation computer.
Whenever a user starts from the command prompt on a Windows NT workstation computer, the user's home directory is set as the default directory. The user's home directory also is set as the working directory for all applications that the user starts, except when those applications have a program item that specifies a different working directory.
For information on file and directory permissions, see Chapter 6, Managing Network Shares,
in this guide.
2.6.3 Windows NT Workstation Computers
Each Windows NT workstation computer on your network can participate in either a domain or a workgroup.
A Windows NT workstation computer participating in a workgroup has its own database of users, processes logon requests by itself, uses only its own users and groups, and is separate from all domains. Computers in a workgroup do not share account information. On this type of workstation, only the user accounts that were created at the workstation can be logged on to or given rights and permissions at the workstation.
Users can log on to an Advanced Server domain from a Windows NT workstation only if that workstation is part of the domain or of a trusted domain. A Windows NT workstation computer that participates in a domain does not get a copy of the domain's user database, but it does receive the benefits of the domain's user and group database. It can use user accounts and global groups from that domain, and the domains it trusts, to provide access to resources on the workstation.
At a Windows NT workstation computer participating in a domain, users can log on to user accounts located in the workstation domain (or in any domain the workstation domain trusts). For example, suppose a workstation is participating in the Sales domain, and Sales trusts the MIS domain. At the workstation, a user can log on to an account located in either the Sales domain or the MIS domain. You can place users and global groups from the domain (and domains trusted by the workstation domain) in local groups on the workstation, and you can assign permissions and rights on the workstation to users and global groups from the domain (and domains trusted by the workstation domain).
Even though a workstation participating in a domain can use accounts located in that domain, user accounts still can be created at the workstation itself. These accounts are local to that workstation and cannot be used on any other computer.
You should not create a local workstation account for a user who has a domain account. Instead, a user with a domain account always should log on to that account.
Even if a Windows NT workstation computer participates in a domain, it cannot use local groups defined in the domain; however, it can use users and global groups defined in the domain. See Chapter 4, Groups, in this guide for more information about using groups. |
Windows for Workgroups computers generally are organized into workgroups. Workgroups are similar to domains in network browsing: When a user uses File Manager to browse the network, the user sees the network divided into domains and workgroups. If the user selects a domain or workgroup, then the user can browse the contents of that domain or workgroup.
Every Windows for Workgroups computer on your network can participate in a domain or in a workgroup. In most cases, you will want Windows for Workgroups computers to participate in a domain so that they can be integrated into the Advanced Server administrative models.
Windows for Workgroups computers can participate in workgroups containing Windows NT workstations. Similarly, on a Windows for Workgroups computer, you can specify the name of an Advanced Server domain as the computer's workgroup and the Windows for Workgroups computer can then function as a computer contained in the domain.
If a Windows for Workgroups user must access a resource in a domain that has no Windows for Workgroups computers, the user must know the name of the computer on which the resource is located. Whenever a Windows for Workgroups computer starts, the user can log on to the network using a user name and password previously specified at the computer. Alternatively, the user can wait to log on to the network until making an initial network access attempt.
If a Windows for Workgroups user has an account in an Advanced Server
domain, you can specify the user name and password of that account to
Windows for Workgroups and set the workgroup name on the computer to be
the name of the domain. Then, users can log on to their domain accounts
automatically when they log on to the network.
2.6.5 Windows 95 and Windows 98 Computers
You can choose whether you want the Windows 95 and Windows 98 computers on your network to participate in a workgroup or in a domain. In most cases, you will want them to participate in a domain, because a user with an account on an Advanced Server domain can log on to that account from a Windows 95 or Windows 98 computer only if that computer is part of the domain.
Windows 95 and Windows 98 computers that participate in a domain do not get a copy of the domain's user database, but they do receive the benefits of the domain's user and group databases.
You can configure a Windows 95 or Windows 98 computer to prevent users from logging on to the local workstation after an unsuccessful attempt to log on to the domain. This prevents users from gaining access to resources local to the Windows 95 or Windows 98 workstation if, for example, their domain user accounts have expired or have been disabled.
A Windows 95 or Windows 98 computer that participates in a workgroup has its own database of users and can process logon requests. However, computers in a workgroup do not share account information. This means that you can assign rights and enable users to log on only to accounts that are created on the Windows 95 or Windows 98 computer.
Windows 95 and Windows 98 computers that participate in a workgroup can
control access to resources by running share-level security. Under
share-level security, each shared resource on a local workstation is
protected by a unique password. Users from remote computers can access
the resource only if they enter the correct password.
2.6.6 Windows, MS-DOS, and OS/2 Computers
Windows V3.x, MS-DOS, and OS/2 computers cannot store user accounts. This makes them unable to participate in domains in the same way as Windows NT, Windows 95, Windows 98, or Windows for Workgroups computers. However, with valid network logon, they can access resources on servers.
Windows, MS-DOS, and OS/2 computers usually have a default domain set for network viewing. If a user has a domain account, the domain into which the user logs on is always viewed. You can add other domains to the viewing list.
The Advanced Server makes account management easy for administrators and network access easy for users, while ensuring network security. The Advanced Server provides user, built-in user, global, and local accounts so that you can provide appropriate network access for users.
This chapter describes the types of user accounts and how to provide
users access to resources they need.
3.1 What is a User Account?
A user account contains information about the user, which includes the name, password, and restrictions on how the user can use the network. Every person who uses the network must have a user account on a domain in the network. A user needs only a single, centrally stored account. This account can provide the user with access to resources anywhere on the network.
Table 3-1 shows the attributes of a user account.
Account Attribute | Comment |
---|---|
User name | The unique name that the user types when logging on. Often a combination of parts of the user's first and last names; for example, EGIBBONS for Evan Gibbons. The user name is unique within the domain. |
Account security identifier (SID) | The unique number that identifies the account (hidden). A SID is generated automatically when an account is entered. |
Account type | The account type is either global or local. Most accounts you create will be global accounts. |
Description | A brief description of the user (optional). |
Domain | Name of the domain where the user logs on. |
Expiration date | A future date when the account automatically becomes disabled; it is useful for ensuring that accounts for temporary employees or students are not kept active unnecessarily (optional). |
Full name | The user's full name, up to 48 characters (optional). |
Group names | Names of local and global groups to which the user belongs. |
Logon hours | The hours during which the user is allowed to log on. The default is all hours. This attribute determines when the user can log on to the network and access servers. Whether users are forced to log off when their logon hours expire is determined by a setting in the domain's security policy. For more information, see the section Section 3.2, Setting Password and Account Policies for the Domain in this guide. |
Logon workstations | The computer names of the workstations from which the user can log on to the domain. By default, the user can use any workstation, but you can restrict logon access to particular workstations (optional). |
Password | The user's password. Generally not displayed as the user enters it. The Advanced Server and OpenVMS have independent user accounts databases, so OpenVMS users can have two passwords --- one for OpenVMS and one for Advanced Server. (Advanced Server passwords are case sensitive; OpenVMS passwords are not.) See the section Section 3.7, Password Synchronization for more information on how to synchronize Advanced Server and OpenVMS account passwords. |
User Profile |
A file containing the user's home directory and logon script.
The home directory is a directory on the server that is private to the user; the user controls access to this directory (optional). The logon script is a batch file or executable file that runs automatically when the user logs on (optional). |
For each user account, several conditions are either true or false, as shown in Table 3-2.
Account Condition | Default | Comments |
---|---|---|
Change Password at Next Logon? | Yes | If yes, users are forced to change the password the next time they log on. Then, after a user changes the password, this value is set to No. |
User Cannot Change Password | No | If yes, users cannot change their own passwords. This is useful for shared accounts. |
Password Never Expires | No | If yes, this user account ignores the password expiration policy set for the domain, and the password never expires. This is used for accounts that represent services, such as the Event Logger service. It is also useful for accounts for which you want the password never to change. |
Account Disabled | No | If yes, this account is disabled and cannot be logged on to. It is not removed from the database, but no one can log on to the account until you again enable it. This is useful for "template accounts." See Section 3.3, Creating User Accounts in this guide for more information. |
3.2 Setting Password and Account Policies for the Domain
For each domain, you can specify every aspect of password policy:
minimum password length (default is 6), minimum and maximum password
age (defaults are 1 day and 90 days, respectively), and password
uniqueness, which prevents a user from changing his or her password to
a password that the user has used recently (the default is not to
enforce password uniqueness). The Advanced Server ADMINISTER commands
allow you to specify password and account policies.
You also can specify whether users are forced to disconnect from the domain's servers when their logon hours expire. If users have not ended their connections by the time their logon hours expire, the servers they are connected to will end the connections. Users are not forced to log off their workstations.
For more information on how to set password and account policies, see
your Server Administrator's Guide.
3.3 Creating User Accounts
Because user accounts contain so much information, it can be time consuming to add individual user accounts manually. To simplify the process, you can create and then disable template accounts that include all of the information needed for typical users. Disabled template accounts cannot be used for logging on, but you can copy the information in them to new user accounts and add individual account information such as user name and password. When you enable new accounts created with a template, all of the account information carries over to the new users with the exception of passwords and permissions.
For more information on copying existing accounts, see the COPY USER entry in the Advanced Server for OpenVMS Commands Reference Manualor the ADMINISTER commands online help.
Every user account contains a unique identifier which is not copied to new accounts. This unique identifier is used for granting permissions to resources. If you delete a user account and then add it again, the new account will not have the same access permissions to resources as those granted to the original account. |
A built-in user account is a user account automatically provided when an Advanced Server domain is created. When an Advanced Server is installed as a primary domain controller, you have two built-in user accounts:
You can create additional user accounts for other users who log on, and you can modify existing accounts.
The remainder of this section further explains the Administrator and
Guest built-in user accounts.
3.4.1 Administrator Account
The built-in Administrator account is a member of the Administrators, Domain Admins, and Domain Users built-in groups, and is granted the rights and permissions of those groups.
The Administrator account is the account used by the person who manages the overall configuration of the domain: the network administrator. The network administrator has more control over the domain and its workstations than does any other user. The network administrator can manage security policy, establish trust relationships, create, modify, or delete user accounts and groups, create and connect to shared directories (including administrative shares), share printers, take ownership of files and other objects, and shut down servers.
The Administrator account is a member of the Domain Admins global group, and the Domain Admins global group is by default a member of the Administrators local group of the domain. Therefore, a user logged on to the Administrator account is able to administer both the local domain and the Windows NT workstation computers in the local domain.
You can rename the built-in Administrator account, but you cannot delete it. Also, you cannot remove it from the built-in Administrators and Domain Admins groups. |
During the configuration of the primary domain controller of a new domain, the person doing the configuration is prompted to enter a password for the built-in Administrator account. This password should be guarded not only for security reasons, but also because if the password is forgotten or the person who knows the password is unavailable, the built-in Administrator account becomes unusable.
Following installation, it is strongly recommended that you create an
additional administrative account for every person who needs
administrative-level abilities and to reserve the built-in
Administrator account for emergency purposes. When all administrative
users have separate accounts, their actions can be audited.
3.4.2 Guest Account
The built-in Guest account is a member of the Domain Guests built-in group and receives the rights and permissions granted to that group. The Guest account allows the occasional or one-time user to log on to the system with limited capabilities. When a user without an account on a domain attempts to use server resources, access is granted to the user based on the guest access permissions.
When you initially install the Advanced Server, the Guest account is disabled by default. You must explicitly enable the Guest account if you want to provide access to domain resources for users who do not have accounts on the domain.
The Guest account is installed with a blank password. If the password is left blank, users from untrusted domains (without accounts in this domain) can connect to this domain remotely using the Guest account.
You can rename the built-in Guest account, but you cannot delete it. |
Previous | Next | Contents | Index |