HP OpenVMS Systems Documentation

Content starts here

Compaq Advanced Server for OpenVMS
Server Administrator's Guide


Previous Contents Index

3.1.17.7 Changing the Default Domain for External Authentication

The local server's domain is the default domain for users when external authentication is established. If you want to change the default domain for users using external authentication, define the Advanced Server logical PWRK$ACME_DEFAULT_DOMAIN on the system as follows:


$ DEFINE/SYS/EXE PWRK$ACME_DEFAULT_DOMAIN domain_name

where domain_name is the name of the new default domain. After defining this logical, if a user does not specify a domain name at login, the system will use the specified default domain for external authentication.

3.1.17.8 Requirement for External Authentication Over DECnet-Plus

To allow users to be externally authenticated over DECnet-Plus for OpenVMS, set the system parameter NET_CALLOUTS to 255. This enables Advanced Server user ID mapping and authentication for network logins.

3.2 Managing Advanced Server Groups

Groups are collections of user accounts and other groups. When you add a user to a group, the user has all the rights and permissions granted to the group. This provides an easy way to grant common capabilities to sets of users. (For additional information about planning Advanced Server groups, refer to the Compaq Advanced Server for OpenVMS Concepts and Planning Guide.)

Note

OpenVMS system groups are unrelated to Advanced Server domain groups.

You use groups to manage access to resources like directories, files, and printers. To do this, assign permissions to the resource, specifying the group names, and add the user accounts to the groups. To change the permissions for a group, add or remove the permissions on the resource for the group, rather than for each user. Or, if you need to give a user access to specific resources (for example, certain directories and files), add the user's account to the appropriate group rather than changing permissions on each individual resource. Maintaining permissions for a group is simpler than maintaining permissions for individual user accounts.

Every group is either a global group or a local group.

  • Global groups can be used both in their own domain and in trusting domains. You can use global groups to grant rights and permissions to global users. By default, new groups are global groups. Global groups can be members of a local group.
  • Local groups can be granted permissions and rights only for the servers in their domain. However, they can contain user accounts and global groups both from their domain and from trusted domains. Local groups let you create sets of users from both inside and outside the domain, to access resources in the domain where the local group is created. The use of local groups in permissions lists for files and shares can also help reduce disk space consumption, as noted in Section 4.1.3.6, Streamlining Security Information Storage and Lookups.

Table 3-2 summarizes how to organize local and global groups.

Table 3-2 Uses of Local and Global Groups
If... Need to access a resource on... You put them in a...
User accounts from this domain The servers and workstations of this domain or of trusting domains Global group
User accounts from trusting domains The servers of this domain Local group
Global groups from this domain The servers of this domain Local group
Global groups from trusting domains The servers of this domain Local group

3.2.1 Built-In Groups

The Advanced Server creates several built-in groups automatically during installation. Each built-in group has a unique set of access rights. To give one such set of access rights to a user account, add the user to the appropriate group. By default, all users belong to the built-in group Domain Users.

Table 3-3 lists the built-in groups, with their group type (global or local), and their default members.

Table 3-3 Built-In Groups
Group Name Group Type Description Default Members
Account Operators Local Members can administer domain user and group accounts. None
Administrators Local Members can fully administer the domain. Administrator, Domain Admins
Backup Operators Local Members can bypass file security to back up files. None
Domain Admins Global Designated administrators of the domain. Administrator
Domain Guests Global All domain guests. Guests
Domain Users Global All domain users. Administrator, user accounts
Guests Local Users granted guest access to the domain. Domain Guests
Print Operators Local Members can administer domain printers. None
Server Operators Local Members can administer domain servers. None
Users Local Ordinary users. Domain Users

3.2.2 Setting Up User Groups

To set up a new user group, use the ADD GROUP command. To create a local group, include the /LOCAL qualifier on the command line. For example, to add the local group MUNCHKINS, enter the following command. Note that the description of the group is enclosed in quotation marks. If you do not specify the group type, the default is to add the group as a global group.


LANDOFOZ\\TINMAN> ADD GROUP MUNCHKINS/DESCRIPTION="Oz local group"/LOCAL
%PWRK-S-GROUPADD, group "MUNCHKINS" added to domain "LANDOFOZ"

LANDOFOZ\\TINMAN> SHOW GROUPS
Groups in domain "LANDOFOZ":
Group Name              Type          Description
---------------------   -----------   -------------------------------------
Account Operators       Local         Members can administer domain user and
                                      group accounts
Administrators          Local         Members can fully administer the domain
Backup Operators        Local         Members can bypass file security to back
                                      up files
DEVAS                   Global
DEVIS                   Global
Domain Admins           Global        Designated administrators of the domain
Domain Guests           Global        All domain guests
Domain Users            Global        All domain users
Guests                  Local         Users granted guest access to the domain
MONKEYS                 Global        Users in the Land of Oz
MUNCHKINS               Local         Oz local group
Print Operators         Local         Members can administer domain printers
Replicator              Local         Supports file replication in a domain
Server Operators        Local         Members can administer domain servers
Users                   Local         Ordinary users

   Total of 15 groups

LANDOFOZ\\TINMAN>

3.2.3 Adding Users to Groups

You can add users to groups in any of the following ways:

  • When you use the ADD GROUP command, include the /MEMBERS qualifier.
  • When you add a new user (using the ADD USER command), include the /MEMBER_OF_GROUPS qualifier. (See Section 3.1.6, Specifying Group Membership, for more information.)

Local groups can include users from domains other than the one currently being administered. To specify a user account from another domain, a trust relationship must be established that allows the domain being administered to trust the domain where the user account is defined.

To specify a user account or global group in a trusted domain, enter a domain-qualified name (domain-name\member-name), such as KANSAS\DOLE, where KANSAS is the name of the trusted domain, and DOLE is the user or group name defined in the trusted domain. If you omit a domain name, the user or group is assumed to be defined in the domain being administered.

3.2.3.1 Adding Members to a New Group

To add members to a new group, include the /MEMBERS qualifier on the ADD GROUP command. For example, to add a new group MUNCHKINS and specify the group members SCARECROW and STRAWMAN, enter the following command:


LANDOFOZ\\TINMAN> ADD GROUP MUNCHKINS/MEMBERS=(SCARECROW,STRAWMAN)
%PWRK-S-GROUPADD, group "MUNCHKINS" added to domain "LANDOFOZ"

LANDOFOZ\\TINMAN>

3.2.4 Copying Groups

To simplify creating a new group, you can use the COPY GROUP command to copy an existing group to the new group, with a new name, keeping the members and description from the previous group. For example, to form a new group called QUADLINGS from an existing group called MUNCHKINS, use the following command:


LANDOFOZ\\TINMAN> COPY GROUP MUNCHKINS QUADLINGS
%PWRK-S-GROUPCOPY, group "MUNCHKINS" copied to "QUADLINGS" in domain "LANDOFOZ"

LANDOFOZ\\TINMAN>

This command copies the description and group members from MUNCHKINS to the new group named QUADLINGS. You can display information about the new group using the SHOW GROUPS/FULL command. For example, the following command displays the type, description, and members of the QUADLINGS group.


LANDOFOZ\\TINMAN> SHOW GROUPS QUADLINGS/FULL

Groups in domain "LANDOFOZ":

Group Name      Type             Description
----------      ------           -----------------------------
QUADLINGS        Local            Oz local group
    Members: [US]LION,[US]SCARECROW

  Total of 1 group

LANDOFOZ\\TINMAN>

3.2.5 Modifying a Group

You can change the membership or description of an existing group.

3.2.5.1 Adding a Member to an Existing Group

To add a member to an existing group, use the MODIFY GROUP command with the /ADD_MEMBERS qualifier. For example, to add the user LION to the group MONKEYS, enter the following command:


LANDOFOZ\\TINMAN> MODIFY GROUP MONKEYS/ADD_MEMBERS=LION
%PWRK-S-GROUPMOD, group "MONKEYS" modified on domain "LANDOFOZ"

LANDOFOZ\\TINMAN> SHOW GROUP MONKEYS

Groups in domain "LANDOFOZ":

Group Name      Full Name       Type     Description
----------      ---------       ------- ------------------------
MONKEYS                         Global   Winged monkeys
    Members: [US]LION

 Total of 1 group)

LANDOFOZ\\TINMAN>

3.2.5.2 Removing a Member From a Group

To remove a member from a group, use the MODIFY GROUP command with the /REMOVE_MEMBERS qualifier. For example, to remove SCARECROW from the group MUNCHKINS, enter the following command:


LANDOFOZ\\TINMAN> MODIFY GROUP MUNCHKINS/REMOVE_MEMBERS=SCARECROW
%PWRK-S-GROUPMOD, group "MUNCHKINS" modified on domain "LANDOFOZ"

LANDOFOZ\\TINMAN>

3.2.5.3 Changing the Description of a Group

To change the group description, use the MODIFY GROUP/DESCRIPTION command, as in the following example:


LANDOFOZ\\TINMAN> MODIFY GROUP MUNCHKINS/DESCRIPTION="First Floor"
%PWRK-S-GROUPMOD, group "MUNCHKINS" modified on domain "LANDOFOZ"

3.2.6 Deleting a Group

Deleting a group removes only that group; it does not delete user accounts or global groups that are members of the deleted group. You cannot recover a deleted group.

Internally, the Advanced Server recognizes every group by its security identifier (SID), which is used when assigning permissions to a resource. If you delete a group and then create another group with the same group name, the new group does not inherit access to any resources available to the old group because the groups have different SIDs. To delete a group, use the REMOVE GROUP command, as in the following example:


LANDOFOZ\\TINMAN> REMOVE GROUP QUADLINGS

Each group is represented by a unique identifier which is independent
of the group name.  Once this group is deleted, even creating an
identically named group in the future will not restore access to
resources which currently name this group in the access control list.
Remove "QUADLINGS" [YES or NO] (YES) : YES
%PWRK-S-GROUPREM, group "QUADLINGS" removed from domain "LANDOFOZ"

LANDOFOZ\\TINMAN>

The command deletes the group QUADLINGS from the LANDOFOZ domain.


Chapter 4
Managing Directory and File Sharing

You use the ADMINISTER command-line interface to set up files and directories for sharing. To do this, you need to become familiar with the concepts and procedures described in this chapter:

4.1 Planning Directory and File Sharing

To serve your users most effectively, you should plan carefully for sharing files and directories. Some projects will require directory sharing, and some groups may need to share only certain files. Use the Shares Worksheet in the Compaq Advanced Server for OpenVMS Concepts and Planning Guide to help you set up your shares.

Sharing a directory makes the directory and the files located in it available to other network users. The Advanced Server integrates two levels of permissions for shared files and directories: share permissions, and file and directory access permissions.

  • Share permissions specify the maximum access possible for a user or group on all files and directories residing on that share. For example, setting share permissions to Read for the group Everyone would allow all users to read a file, and prevent any user from altering the contents of the file. You set share permissions using the ADD SHARE and MODIFY SHARE commands. If you do not specify share permissions when you add the share, the default is to allow all users to access the share.
  • File and directory access permissions specify the access that a group or user is granted to a particular directory or file in a shared directory. You set file and directory access permissions with the SET FILE/PERMISSIONS command, as described in Section 4.3.6, Specifying File and Directory Access Permissions.

Note

When you copy files or directories, security permissions set on them are discarded in addition to ownership and auditing information. The files inherit a new set of permissions from the directory into which they have been copied. If the new directory does not specify permissions for files, only the file's owner (the person who copied the file) will have permission to use the file.

In addition to the two levels of permissions supported by the Advanced Server, the OpenVMS file system imposes a set of protections, which are used if the Advanced Server and OpenVMS security model is enabled. These must be considered when managing shared directories. (For more information, see Section 4.1.2,Advanced Server Security Models.) Shared directories must have the appropriate OpenVMS system protections applied to them if interactive OpenVMS users and other OpenVMS processes need access to them.

4.1.1 Disk Resources

Advanced Server for OpenVMS supports the following OpenVMS file systems:

  • ODS-2, the traditional OpenVMS file system, which is based on the Files-11 disk structure
  • ODS-5, the optional extended file system provided by OpenVMS Version 7.2 and higher, which provides Extended File Specifications and deep directories

For more information about Extended File Specifications, refer to the OpenVMS Guide to Extended File Specifications. For details about managing disk resources on ODS-5 disk volumes, see Section 4.5, Using ODS-5 Disk Volumes in the Advanced Server Environment.

Disk resources include the disk devices on a server, the directories on those devices, and the files in the directories. With Advanced Server you can create a share for a directory, including the root directory for a disk, and specify access permissions for the share. Access permissions define the network users or groups permitted to access the share, and the kinds of operations that each may perform.

You cannot create a share for a file. Users access files through the directory share where the files reside. However, you can set access permissions on shares, directories, and files.

By configuring the server security model, you can enhance access permissions using OpenVMS file protection mechanisms.

4.1.2 Advanced Server Security Models

All Advanced Server users have either a network user account or access to the Guest account. The type of access allowed to each user account is determined by the access permissions set on the resource. Each network user account may be mapped to an OpenVMS user account. This mapping enables the Advanced Server to integrate network security with OpenVMS file access security.

You can define the level of integration by setting the server configuration parameter that specifies one of the following security models:

  • Advanced Server Only (default)
    Only network security is enforced; OpenVMS access checks are bypassed. Advanced Server Only is the default security model when you install the server software. Unless you change the default parameter setting for the security model, Advanced Server Only security is established on your server. Advanced Server Only security is sufficient for most network environments.
  • Advanced Server and OpenVMS
    Both network security and OpenVMS security are enforced. If the user's access request passes the Advanced Server security check, Advanced Server checks the OpenVMS security set on the requested resource, determined by the OpenVMS user account to which the network user account is mapped. Access is granted when the user passes both security checks. For information on how network user accounts are mapped to OpenVMS user accounts, see Section 3.1.16.2, Establishing User Account Host Mapping.
    The Advanced Server and OpenVMS security model is best suited for environments that require the additional control provided by the OpenVMS operating system. For example, this model would benefit systems with legacy OpenVMS data already protected by the elaborate OpenVMS security settings. Rather than having to establish the same security settings at the server level, you could simply give Everyone full control and let OpenVMS security settings determine access. Note that use of the Advanced Server and OpenVMS security model results in the extra overhead of validating both the Advanced Server and OpenVMS settings.

You can change the security model configuration parameter setting, using the Configuration Manager as described in Chapter 7, Managing Server Configuration Parameters.

The following sections describe the security models in more detail. Each security model provides the security checks shown in Table 4-1, Security Checks.

Table 4-1 Security Checks
For this security model: The server checks Advanced Server permissions: And checks OpenVMS protections:
Advanced Server Only Yes No
Advanced Server and OpenVMS Yes Yes

4.1.2.1 Advanced Server Only Security Model

Whether the Advanced Server grants or denies a file access request depends on three factors:

  • The security model in effect on the server
  • Permissions established for the group of which the user is a member
  • Permissions established for the user

To effectively implement the Advanced Server Only security model, keep the following in mind:

  • Network users cannot use a directory or file unless they have been granted permission to do so or belong to a group that has permission to do so.
  • Share permissions are cumulative, except that the No Access permission overrides all other permissions. For example, the MUNCHKINS group has Write permission for a file and the WINKIES group has only Read permission. User SCARECROW is a member of both groups; therefore, SCARECROW is granted Read and Write permission.
    If you change the WINKIES group's permission for the file to No Access, SCARECROW cannot use the file even though he is a member of the MUNCHKINS group, which still has access to it.
  • The user who creates a file or directory is the owner of that file or directory. The owner can always control access to the file or directory by changing the permissions set on it. Network administrators can always take ownership of a file or directory.
    For files and directories that existed on an OpenVMS device before the share was created, the owner of the file or directory is set to be the user who created the share.
  • The easiest way to administer security is by setting permissions for groups, not individual users. Typically, a user needs access to many files. If the user is a member of a group that has access to the files, you can end the user's access by removing the user from the group rather than changing the permissions on each of the files.


Previous Next Contents Index