The complete trust model is ideal if you want the management of users and domains to be distributed among different departments rather than to be centralized.

With the complete trust model, every domain on the network trusts every other domain. In this way, every department can manage its own domain and define its own users and global groups, and these users and global groups can be used on all of the domains in the network.

Table 5-5 summarizes the advantages and disadvantages of using a complete trust model.

Table 5-5 Advantages and Disadvantages of the Complete Trust Model

Advantages	Disadvantages
Best for companies with no central MIS group.	Does not provide for central management of users.
Scaleable to networks with any number of users.	Large number of trust relationships to manage.
Each department has full control over its user accounts and resources.	Each department must be confident that other departments will not add unauthorized users to global groups.
Both resources and user accounts are grouped into departmental units.	Difficult to add domains.

5.9.1 Complete Trust Model: Example of Domain Configuration

However, this model may be the most suitable for companies that do not have centralized MIS departments. (See Chapter 2, Domains and Trusts, in this guide.)

Figure 5-6 Complete Trust Model

With the complete trust model, the term "trust" applies totally. Before you create a trust relationship with another domain, be sure that you have confidence in the administrator of that domain, especially if you will be giving permissions to global groups from that domain. After you give permission to a global group from another domain (or place that global group in a local group in your domain), you are trusting the administrator of the other domain not to add unauthorized users to that global group.

5.9.2 Complete Trust Model: Example of Network Security Configuration

A company of 1000 users with no centralized MIS group is setting up its Advanced Server network. Because there is no centralized computer management, each department needs to administer its own server. This makes the complete trust model the best choice.

Every department sets up its own domain and has its own domain administrator who is entirely responsible for both user accounts and shared resources in the domain. Each domain administrator creates user accounts for all employees who work in the department corresponding to that domain.

Each department administrator is also responsible for creating global groups and local groups in the domain. When the department administrator creates a group containing only users from that department's domain, he or she can create a global group. When a group containing users from other domains is needed, a local group is necessary.

Each department administrator can establish two-way trust relationships with other Advanced Server domains. Then users and global groups from one domain can be given rights and permissions or can be placed in local groups in the other domains.

In this case, department administrators must ensure that only authorized users are added to global groups. For example, if the Shipping department trusts the Sales department, the Shipping administrator can give permissions to the Accountants global group from the Sales domain. If the Sales administrator subsequently adds more users to the Accountants global group, these new users will have the permissions granted to Accountants in the Shipping domain. Therefore, the Shipping administrator must be careful to grant permissions only to appropriate global groups from domains with trusted administrators, and the Sales administrator has the responsibility to add only appropriate users to global groups.

One of the most important functions of network servers is to share files and directories with network users. When a directory is shared, users can make connections to the directory from their workstations and access the files in the directory. The shared directory also serves as storage that is available to the network user.

The Advanced Server provides excellent performance, reliability, and security for file sharing. You can set file permissions on files and directories to grant access only to authorized users. With the Advanced Server, you can specify which groups and users can access each file and directory and the level of access that each group or user is permitted.

In addition, the Advanced Server provides audit capabilities for monitoring the access of files and directories on the server. When the Advanced Server audits a file or directory, an entry is written to the server security log when a user accesses the file. You can define the types of access for each file or directory that will cause audit entries to be written.

This chapter explains how the OpenVMS system supports the concept of file and directory ownership. The Advanced Server lets network clients view and change the ownership of files and directories, and it integrates standard OpenVMS system file and directory ownership into the enterprise-wide, network security model. This chapter also explains some features and concepts regarding file storage and file name conventions that help ensure greater compatibility with clients and legacy applications.

6.1 Sharing Files with Network Users

When a directory is shared on a server, a user potentially can gain access to that directory and to all of its subdirectories and files. Every point on the directory tree that is under the shared directory can be made available to network users.

You can block access to some of the directories in a shared directory tree and allow access to others by setting permissions on them.

When you share a directory, you assign it a share name. Network users use a share name to refer to the shared directory. Windows users see the share name when using File Manager or Windows Explorer to browse the network.

A share name can be (but is not required to be) the same as the actual directory name. A shared directory often is referred to simply as a share.

You can share multiple directories on the same directory tree. In this case, one shared directory might be accessible to users in different ways --- as a directory that actually is shared and as a subdirectory of another shared directory.

6.1.1 Autoshares

The Advanced Server supports access to disk devices by offering disk devices as shares at server startup time. These special shares are referred to as autoshares (automatic shares) and are accessible only to users with Administrator rights.

Autoshares are hidden. They are visible only to members of the Administrators group, and only members of this group can connect to them. When connected to an autoshare, you are located at the top-level (root) directory of the device and have access to any subdirectory or file in the directory tree.

For more information on creating autoshares, see your Server Administrator's Guide.

6.1.2 Connecting to Shared Resources

Network users generally make connections to shared directories by assigning a drive letter on their workstation to the shared directory. Then they use the assigned drive letter to refer to the directory to which they have made the connection.

For example, if a user makes a connection to the APPLICATIONS directory and assigns the drive letter F: to the directory, the user sees the contents of the APPLICATIONS directory on the server as the contents of his or her own F: drive. The subdirectory TOOLS appears as F:\TOOLS to the user.

In Figure 6-1, a workstation user assigns the drive letter F: to a directory when making a connection to it. Then, to the user, the contents of the shared directory are the contents of the user's drive letter.

Figure 6-1 Connecting to Shared Resources

After a Windows user has made a connection to a directory, the drive letter assigned to that directory and an icon appear in the Folders pane of Windows Explorer on Windows 95, Windows 98, Windows 2000, and Windows NT systems or in the drive bar of the File Manager window.

MS-DOS and OS/2 users with LAN Manager networking software (but without Windows) can use the NET USE command to make network connections. OS/2 users can use File Manager to view the connected drive. OS/2 users can use the NET USE command at the DOS prompt.

MS-DOS users (both with and without Windows 3.1 or Windows for Workgroups) have restrictions on how they access and view shared directories. These restrictions are described in Section 6.1.3, Considerations for MS-DOS Users .

6.1.3 Considerations for MS-DOS Users

In general, share names can include up to 12 characters. When assigning share names to shared directories, determine whether the directory will be accessed by users of MS-DOS, Windows 3.1, or Windows for Workgroups. If so, assign a share name that follows the MS-DOS 8.3 naming convention, where the share name can have up to eight characters, optionally followed by a period and up to three additional characters. MS-DOS users cannot access shares with share names that do not follow this convention. If a share will be accessed only by Windows NT, Windows 95, Windows 98, or Windows 2000 users, the share name can be up to 12 characters long.

6.2 Using Permissions

You set permissions on shared directories to ensure that only authorized users can access each file or directory and that those users can access them only in appropriate ways. The Advanced Server lets you set permissions differently for each file and directory.

Both Advanced Server and OpenVMS support the concepts of file and directory ownership. Every file and directory has an owner. The owner controls how permissions are set on the file or directory and can grant permissions to others. File ownership provides a way for users to keep files on the server private.

Administrators create most of the files on network servers, often when they install applications on the server. Therefore, most files on a server will be owned by administrators, except for data files created by users and files in users' home directories.

When an Advanced Server user creates a file or directory, that user automatically becomes the owner of the file or directory. The Advanced Server sets the OpenVMS system owner of a file or directory created by an Advanced Server user to the OpenVMS system identity that has been mapped for that user's Advanced Server account.

For more information about how to set up user host mapping, see your Server Administrator's Guide.

Ownership can be transferred in the following two ways:

• The current owner can grant the Take Ownership permission to other users, in which case those users can take ownership at any time.
• An administrator can take ownership of any file on the computer. This is useful, for example, if an employee leaves the company suddenly and the administrator needs to take control of the employee's files.

Although an administrator can take ownership, the administrator cannot then transfer ownership to others. This prevents an administrator who wrongly takes ownership of a user's files from transferring ownership back to the original owner. When the original owner discovers that he or she is no longer the owner of the files, he or she can check the current ownership of the files and discover who took ownership of them.

6.4 Auditing Directories and Files

By auditing files and directories on a server, you can track their use and identify any attempted security violations. You can identify who took various types of actions with files and directories and hold those users accountable for their actions.

When a file or directory is audited, audit events are generated and written to the Advanced Server security log for all failed and successful attempts to perform the activities you want to audit.

Through the audit policy you set up, you can enable auditing on the server or domain for the types of directory and file access listed in Table 6-1. The audit policy applies domain-wide. If you set the audit policy on a backup domain controller, the change is actually made on the primary domain controller and is then replicated to all the backup domain controllers in the domain. A member server maintains its own audit policy.

Table 6-1 Audit Events for Directory and File Activities

Types of Directory Access	Types of File Access
Displaying contents of the directory	Displaying data in the file
Displaying directory attributes	Displaying file attributes
Changing directory attributes	Displaying the file owner and permissions
Creating subdirectories and files	Changing the file
Going to the directory's subdirectories	Changing file attributes
Displaying the directory owner and permissions	Running the file
Deleting the directory	Deleting the file
Changing directory owner and permissions	Changing the file owner and permissions

6.5 File Sharing Compatibility with Diverse Clients

The Advanced Server software helps ensure compatibility with a wide variety of clients and legacy applications attempting to share server resources. This section describes several of the features that provide this compatibility, including:

• Extended File Specifications
• Unicode or extended character sets
• Legacy applications with more restrictive file naming conventions

With OpenVMS Version 7.2 and higher, you can use the Extended File Specifications feature to offer file system services that are compatible with Windows 95, Windows 98, Windows 2000, and Windows NT file systems. Extended File Specifications provides the following capabilities to OpenVMS Alpha systems. The benefit to the Advanced Server client computers depend on the type of client, as noted.

• Deep directories, similar to Microsoft Windows NT. Previous versions of OpenVMS support a maximum of eight directory levels.
  Deep directories allow network clients to use hierarchical storage of directories and files on the OpenVMS disk similar to the client-based disk. They are also of benefit to applications developers who are porting applications from other environments that have support for deep directories.
• Extended file names (using ODS-5 disk structures). Extended file names functionality is an optional feature originally provided with the OpenVMS V7.2 operating system that extends OpenVMS file name capabilities to more closely match those of Windows 95, Windows 98, Windows 2000, and Windows NT computers. With this functionality, OpenVMS Alpha V7.2 (and higher versions) systems support long file names (up to 243 characters including the version number), and adds ISO Latin-1 characters to the supported character set.

To take advantage of the capabilities of Extended File Specifications, be sure to complete the following steps:

1. Convert disk volumes that are used for storing shared directories and files from the ODS-2 to ODS-5 file system. For instructions, refer to the OpenVMS Guide to Extended File Specifications.
2. Convert existing shared files on those disk volumes. For instructions, refer to the Compaq Advanced Server for OpenVMS Server Installation and Configuration Guide.

To simplify share access, you may want to set up all shared disk volumes as ODS-5 disk volumes.

6.5.2 Unicode Characters in Share Names

Unicode and extended character sets provide an extensive character coding system and standard designed to support written texts of the diverse languages of the modern world. The design of extended character sets is based on the simplicity and consistency of the ASCII encoding, but goes far beyond ASCII's limited ability to encode only the Latin alphabet.

A client computer that supports Unicode, or which is configured to use a code page that is not related to a Western European language, can create files with characters in the file name that are not part of the standard ISO Latin-1 character set. Any Advanced Server product previous to the Advanced Server V7.3 for OpenVMS could not store files using these file names. The latest version of the Advanced Server for OpenVMS file server can now support Unicode characters or extended character sets that are foreign to the Western European languages. The characters that the Advanced Server for OpenVMS can support at any time depend on the current language configured for the server. (You use the PWRK$CONFIG configuration procedure to configure the language.)

This support for alternative languages allows you to configure the Advanced Server to support the local language of the server users. You can select any one language from a list of 43 languages from all over the world. Two of the supported languages support the Euro currency symbol.

Support of the Unicode or extended character set characters makes available a broader set of characters not only for file and share names, but also for other objects manageable by the Advanced Server, such as user names and group names.

The languages and their associated ISO-8859 character sets are a subset of the Unicode (UCS-2) character sets supported on OpenVMS ODS-5 disk structures. On ODS-2 volumes, the Advanced Server stores these characters in an escape-encoded format. If you plan to use one of the alternative languages, and you have an ODS-2 disk device that includes escape-encoded characters in file names, you should convert all file names using the PWCONVERT utility, as explained in the Compaq Advanced Server for OpenVMS Server Installation and Configuration Guide. For more information on on Unicode and extended character sets, see the Compaq Advanced Server for OpenVMS Server Administrator's Guide.

6.5.3 Enhanced Support for Legacy Applications with Restrictive File Naming

Some applications and client applications are more restrictive than the Advanced Server and Windows NT in both the lengths of file names and in the set of valid characters supported for file names. For example, MS-DOS file names are limited to the "8.3" convention: file names can be no longer than eight characters, with a period separating the file name from the file extension, and the file extension can be up to three characters. Obviously, these applications do not take full advantage of the capabilities of the OpenVMS ODS-5 disk volume and longer file names supported on Windows NT, the Advanced Server, and other systems.

To enable compatibility with legacy applications (such as MS-DOS) whose file naming conventions are more restricted than those used by the Advanced Server, Advanced Server for OpenVMS servers, Version 7.3 or later, automatically create MS-DOS-compatible alias file names for files whose names do not comply with the file naming standards of those applications. As a result, client applications that must use, or choose to use, the MS-DOS format for file names, can access these shared files on the server by using the file's associated alias name. Clients (depending on their file systems) can use either the real file name or the alias file name to access the file.

An alias file name is also created for any file whose real name contains any extended character set characters with values of 128 through 255 (hexadecimal 0080 through 00FF). This is done even when the real filename is MS-DOS-compatible (has the 8.3 format and contains no characters that are explicitly invalid in MS-DOS file names). The Advanced Server V7.3 for OpenVMS returns a file's alias name, instead of the real file name, to an MS-DOS client only if the real name is not MS-DOS-compatible, or if any extended character set character in the real name does not map to the client code page. Otherwise, the Advanced Server returns the file's real name to the MS-DOS client.

For more information on the alias file names created by the Advanced Server for OpenVMS, see the Compaq Advanced Server for OpenVMS Server Administrator's Guide.