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.)

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.

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:

• Section 4.1, Planning Directory and File Sharing, describes how to plan the sharing of directories and files for your users and the access permissions you can set.
• Section 4.2, Administrative Shares, describes the disk administrative resources.
• Section 4.3, Managing Shared Directories and Files, describes how to secure directories and files, share a directory on the OpenVMS system, audit directory and file access, and take ownership of directories and files. It also describes how to manage Advanced Server shares from Windows NT Server computers.
• Section 4.4, Unicode and Extended Character Sets, describes how the Advanced Server can support extended character sets (including certain Unicode characters). The supported extended characters can be used in file and share names, and other objects manageable by the Advanced Server.
• Section 4.5, Using ODS-5 Disk Volumes in the Advanced Server Environment, describes how to manage and use shares stored on ODS-5 disk volumes.
• Section 4.6, File Names for Files Stored on the Advanced Server, describes the conventions for Advanced Server file names and how they are stored on the server.

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.

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.