HP OpenVMS Systems
HP Advanced Server for OpenVMS
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
5.3 Additional Resource Protection
This section describes how the Advanced Server validates a file access request. Whether the Advanced Server grants or denies access depends on two factors:
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.
|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
In the single domain model shown in Figure 5-1, the network has only
one domain and you create all the users and global groups in the domain.
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
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
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.
|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 shows an example of a company that is divided into
several distinct departments and that uses the master domain model.
All accounts are created in an MIS master domain, and there is a
separate domain for each department. Within the master domain is a
global group for each department that includes all user accounts for
that department. Every departmental domain trusts the master domain and
can make use of its global groups. The MIS domain serves as the account
management domain, and a local group of MIS administrators has
privileges limited to the MIS domain.
Figure 5-2 Master Domain Model
5.7.2 Master Domain Model: Example with MIS Master Domain
Figure 5-3 presents a setup using the master domain model with MIS
as the master domain. Because MIS is the only master domain, all user
accounts are located there, and all other domains trust the MIS 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
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.
|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 shows an implementation of the multiple master domain
The company's MIS group monitors the master domains. In addition to the
master domains, many other domains, such as departmental domains,
provide resources. The departmental domains can be managed by people in
their own departments or by a centralized MIS department.
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:
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.