An access control entry (ACE) is an entry in an access control list (ACL) that controls access to files and directories by resource identifiers. ACLs give you more control than RMS protections. For example, with RMS, the only way to grant read access to users in different UIC groups is to grant world read access. In contrast, with ACLs, you can provide users from several UIC groups access to a file or directory without granting world access, and you can deny specific users access to specific files.

If you use both RMS protection and ACLs, OpenVMS checks ACEs in the ACLs before it checks the RMS protection.

For more information about RMS protection and ACLs, see the OpenVMS documentation set.

5.3 Additional Resource Protection

You can take advantage of several other methods of protecting servers and network resources, as follows:

• Use logon security --- In a domain where at least one server is running user-level security, the Advanced Server can validate user requests to log on to the network and access network resources through the logon security features implemented through the Netlogon service.
  Logon security authenticates users through the following controls:
  • Maintains a domain-wide security accounts database. You can create and, when necessary, make changes to the database for the entire domain from a single server.
  • Uses logon validation to control network access through individual user passwords.
• Use hidden servers --- Hidden servers are servers you hide to protect them from unauthorized use. When users view the list of servers in the domain, hidden servers do not appear in the list. Users can still access a hidden server and its resources if they know the server's name, but they cannot use the Advanced Server to find out that the server exists. By default, a server is not hidden.
  You can hide a server by setting the SrvHidden server configuration parameter.
• Enable account lockout --- You can enable account lockout after a specified number of failed logon attempts occurs. This protects your network from unauthorized users who attempt to break into the network by using password generation schemes. Once an account is locked out, it is disabled until an administrator reenables it. Lockout information is copied to all the servers in a domain.
• Use Advanced Server external authentication --- This optional feature lets Advanced Server users log in to the OpenVMS operating system with the Advanced Server domain user name and password. With external authentication, you can avoid creating and maintaining dual accounts and passwords for users who need to use both OpenVMS and PCs. For more information on enabling external authentication, see your Server Installation and Configuration Guide.

This section describes how the Advanced Server validates a file access request. Whether the Advanced Server grants or denies access depends on two factors:

• The security model in effect on the server
• How a user's Advanced Server account is mapped to an OpenVMS account

All Advanced Server systems implement user-level security. With user-level security, all Advanced Server users have an Advanced Server user account. File access by each account is determined by the Advanced Server permissions set on the file. Furthermore, each Advanced Server account is also mapped to an OpenVMS account. This mapping integrates Advanced Server security with OpenVMS file access security.

Using the Configuration Manager tool, you can specify the level of integration by setting a server configuration parameter that specifies one of the two Advanced Server security models: Advanced Server security only, or Advanced Server and OpenVMS security.

5.4.1 Advanced Server Security Only Model

Advanced Server security only is the default security model for all installations. Therefore, unless you change the defaults, installing Advanced Server software establishes Advanced Server security only, where Advanced Server security is enforced and OpenVMS access checks are bypassed.

The Advanced Server security only model is suitable for environments where the security features provided by the Advanced Server are sufficient, such as on a dedicated server or on a server with no interactive OpenVMS users who are also network users.

5.4.2 Advanced Server and OpenVMS Security Model

In addition to the default security model, Advanced Server security only, you can choose to use the combined Advanced Server and OpenVMS security model, in which both forms of security are enforced. If a user's access request passes the Advanced Server security check, the Advanced Server checks the OpenVMS security in effect (determined by the OpenVMS account to which the Advanced Server account maps) for the user's request. Access is granted if a user passes both security checks. For information on how Advanced Server accounts map to OpenVMS accounts, see Section 3.6, Mapping OpenVMS Users to Advanced Server Users, of this guide.

5.5 Security Integration Considerations

The level of Advanced Server and OpenVMS security integration that you select can affect how resources are shared among Advanced Server users. If you select the Advanced Server and OpenVMS security model, a resource created by one Advanced Server user may not necessarily be accessible to other Advanced Server users. For example, if Advanced Server security checks allow access, but the user's Advanced Server account maps to an OpenVMS account that is not granted access, the OpenVMS security check will fail and resource access will be denied.

The Advanced Server and OpenVMS security model provides the greatest level of security. However, use of the Advanced Server and OpenVMS security model results in the extra overhead of validating both the Advanced Server and OpenVMS settings. If you do not need this level of file access checking, you can use the Advanced Server security only model, in which OpenVMS file access checks are bypassed completely.

If you want the extra security provided by the Advanced Server and OpenVMS security model, ensure that the accounts of the Advanced Server users map to OpenVMS accounts that provide the access privileges that users require.

The remainder of this chapter describes examples you can use as models to set up network security within domains.

5.6 Single Domain Model

If your network does not have many users and does not need to be segmented for organizational reasons, you can use the simplest domain model, the single domain model. When you use the single domain model, trust relationships are not needed because there is only one domain on the network.

Because permission to administer servers is established at the domain level, having a single domain lets network administrators administer all of the network servers.

Table 5-2 summarizes the advantages and disadvantages of using a single domain model.

Table 5-2 Advantages and Disadvantages of the Single Domain Model

Advantages	Disadvantages
Best model for companies with few users and resources.	Poor performance results if the domain has many users and groups.
Centralized management of user accounts.	No grouping of users by department into separate domains.
No management of trust relationships necessary.	No grouping of resources by function into separate domains.
Local groups need to be defined only once.	Browsing is slow if the domain has many servers.

5.6.1 Single Domain Model: Example of Domain Configuration

Figure 5-1 Single Domain Model

A network can use the single domain model if it has a small enough number of users and groups to ensure good performance. The exact number of users and groups depends on the number of servers in the domain and the server hardware.

If your network has many servers sharing resources or your organization has many departments, the single domain model may not be the best. With multiple domains, a user browsing the network first browses among domains, then chooses a domain and views the resources it contains. If your network has many shared resources, segmenting it into domains may make browsing easier. Performance degrades when users browse a single domain with many servers.

5.6.2 Single Domain Model: Example of Network Security Configuration

A small college with a central MIS department contains one Windows NT Server and several Advanced Server computers that are used by departmental offices.

All user accounts and groups belong to the same domain, so access to resources is limited by permissions, and capabilities are restricted by group.

From any Advanced Server, local or remote, or from the Windows NT Server, the MIS department can monitor and manage the domain, the other servers, and the network resources (directories, files, printers, and so on) available throughout the domain. To make this possible, the MIS department has at least one user in each department's global group that is a member of the Administrator's local group. The MIS users are included in the Domain Admins group to perform domain-wide procedures such as software upgrades, backing up the servers, and providing troubleshooting assistance to departmental users.

Departments can manage the Windows NT Server from their Advanced Server systems, as well as manage, share, and monitor access to resources on their departmental computers. This simplifies user account and local resource management because they are handled at departmental levels. Departmental administrators can add new user accounts and include new users in local groups specific to the department or to types of users. MIS users define new groups across the domain or include users in built-in groups. For these tasks, departmental and MIS users can use the Advanced Server ADMINISTER commands, which provide the ability to display, modify, and delete user accounts and groups. They can also use Windows NT Server administration tools.

5.7 Master Domain Model

The master domain model is a good choice for organizations in which the network needs to be arranged into domains for departmental reasons, but the number of users and groups is small. This model offers both centralized administration and the organizational benefits of multiple domains.

With this model, there is one domain --- the master domain --- in which all the users and global groups are created. All other domains on the network trust this domain and, therefore, can utilize its users and global groups. If your organization has a department that manages your LAN, it would be appropriate to have this department administer the master domain.

View the master domain as an account domain; its main purpose is to manage the network's user accounts. The other domains on the network are resource domains; they do not store or manage user accounts but provide resources such as shared files and printers to the network.

With the master domain model, only the primary and backup domain controllers in the master domain have copies of the network's user accounts. Be sure to have at least one backup domain controller in a master domain. In the event that the primary domain controller fails, the backup domain controller can take over and the network keeps running.

Table 5-3 summarizes the advantages and disadvantages of using a master domain model.

Table 5-3 Advantages and Disadvantages of the Master Domain Model

Advantages	Disadvantages
Best choice for companies that have few users and must share resources among groups.	Poor performance results if the domain has many users and groups.
User accounts can be managed centrally.	Local groups must be defined in every domain in which they will be used.
Resources are grouped logically.
Department domains can have their own administrators, who manage the resources in the department.
Global groups need to be defined only once (in the master domain).

5.7.1 Master Domain Model: Example of Domain Configuration

Figure 5-2 Master Domain Model

5.7.2 Master Domain Model: Example with MIS Master Domain

Figure 5-3 Master Domain Model with MIS as the Master Domain

In this example, if you want to create a universal print operators group that can be used in every domain, you create a PrintOps global group in the MIS domain and then put MIS\PrintOps into a Print Operator local group in the Production and Sales domains. You then add the user accounts of each print operator to the PrintOps global group to manage all print operators as an entity.

5.7.3 Master Domain Model: Example of Network Security Configuration

A company of 3000 users, organized into 15 departments and a centralized MIS group, is setting up an Advanced Server network. The company selects the master domain model as its network security configuration.

The MIS group creates a domain named MIS to serve as the master domain. This domain has three servers running Advanced Server software; this ensures that the network is failover tolerant if one of the servers must go down for servicing.

All user accounts are created in the MIS domain. The MIS group also creates 15 global groups in the MIS domain. The name of each global group corresponds to one of the 15 departments in the company, and the members of each global group are the employees who work in that department. Initially, each employee is a member of only one of these global groups. No directories or printers are shared in the MIS domain; this domain serves only as an "account-management domain."

Each of the 15 departments has its own Advanced Server domain. Most of these department domains contain only one server running Advanced Server software. Directories and printers on the network are shared by the department domains. Every department domain trusts the MIS domain, but the department domains do not need to trust one another.

The Administrators local group of each department domain contains the user account of at least one user working in that department. This administrator can share resources, create local groups in the domain, and perform other necessary tasks. The MIS\Domain Admins group also is a member of the Administrators local group on every domain. This means that the MIS group can perform software upgrades, back up network servers, and help the departmental administrators with problems.

When a new group of users is needed for use only within a domain, the local department administrator can create a local group in the domain. For example, the administrator of the Sales domain can create a new local group in the Sales domain, containing the user accounts MIS\CristalW, MIS\BillO, and MIS\PegE. In this example, CristalW, BillO, and PegE work in the Sales domain, but their accounts, like those of all other company employees, are located centrally in the MIS domain.

Suppose that a new group of users is needed and this group needs permissions in more than one domain. In this case, a local department administrator could send a message to the MIS group, who could create a global group in the MIS domain with the appropriate members. For example, if the MIS group creates a global group named Budget Planners in the MIS domain, a department manager could grant permission to MIS\Budget Planners for the resources that this group needs.

A different option for this company would be to have departmental managers act as Server Operators in their own domains only; they would not be members of the Administrators group. The departmental managers would still share resources, but only the MIS group would create local groups and perform other administrative tasks.

5.8 Multiple Master Domain Model

For larger companies that want centralized administration, the multiple master domain model is a good choice because it is the most scaleable.

With this model, a small number of master domains serve as account domains, and every network user account is created on one of these master domains.

Table 5-4 summarizes the advantages and disadvantages of using a multiple master domain model.

Table 5-4 Advantages and Disadvantages of the Multiple Master Domain Model

Advantages	Disadvantages
Best choice for companies with many users and a centralized MIS department.	Local and global groups may need to be defined multiple times.
Scaleable to networks with any number of users.	There are more trust relationships to manage.
Resources are grouped logically.	User accounts are located in more than one domain.
Department domains can have their own administrators, who manage the resources in the department.

5.8.1 Multiple Master Domain Model: Example of Domain Configuration

Figure 5-4 Multiple Master Domain Model

Every master domain trusts the other master domains. All domains in the company trust all master domains; therefore, every user account potentially can access every domain. The departmental domains, however, do not necessarily trust one another.

Note that the management of global groups is slightly more complicated in this model. If a global group needs to contain users from two or more master domains, you must:

1. Create global groups in each master domain.
2. Add the global groups to a local group in each domain to which users need access.

To minimize this inconvenience, distribute users among your master domains by department within your company rather than alphabetically or otherwise. In this way, the chance that you will need similar global groups from different master domains is reduced. Your company's central MIS department can manage the master domains.

5.8.2 Multiple Master Domain Model: Example of Network Security Configuration

A growing company of several thousand users organized into multiple departments and a centralized MIS department is setting up its Advanced Server network. Because of the high number of users, the company selects the multiple master domain model to ensure that performance in the master domains does not degrade.

The company creates two master domains, MIS1 and MIS2 --- each with multiple servers running Advanced Server software. A high number of servers in each domain provides greater performance in approving logon requests. This is needed because many employees will be logging on at about the same time every morning.

Each user account is created in one of the MIS domains. A user's job determines which master domain contains the user's account.

Each department has its own domain with its own administrator who creates local groups, manages the sharing of the department resources, and keeps the department's servers running smoothly.

The two master domains trust one another and every department's domain trusts both of the master domains. Department domains do not need to trust one another.

If a new global group of users is needed, it must be created by the MIS department. If the global group needs to contain users from both of the network's master domains, the MIS department needs to create two global groups (one in each master domain) containing the users whose accounts are in that domain.

For example, a group containing users from both MIS1 and MIS2 may be needed to operate printers in the departments. In this situation, create PrintOps global groups in both MIS1 and MIS2 and put both MIS1\PrintOps1 and MIS2\PrintOps2 in a Print Operator local group in every domain.

Figure 5-5 illustrates this example of a multiple master domain model.

Figure 5-5 Multiple Master Domain Model with MIS1 and MIS2 as the Master Domains

Maintenance of this model is simple: If a print operator leaves the company or a new one joins, you simply remove the user's account from, or add it to, the Domain PrintOps global group in the domain where the user's account is, or should be, located. If new printers needing administration are added to an existing domain, all your print operators will be able to manage them automatically.

If you need to add a workstation with a printer to administer, add all the Domain PrintOps global groups to the workstation's Power Users local group. And if a new domain is added to your network, add all the Domain PrintOps global groups to the Print Operator local group in that domain.