Document revision date: 15 October 2001

One subtle difference exists in how and when the Advanced Server and Windows NT build security information for a file. By default, both the Advanced Server and Windows NT are designed to write complete security information for a file when the file is created, propagating it from the parent directory as necessary. However, the Advanced Server file server allows you to change this default behavior to make more efficient use of security information and disk space. For more information, see the discussion of the Store_Security_Aces parameter in Section 4.1.3.6, Streamlining Security Information Storage and Lookups.

As a result of making this change, when a file is created in a shared directory, only the owner information is stored with the new file. When a user attempts to access the file, the server uses security information from the parent directory structure to dynamically build a Windows NT security descriptor for the file. The file server does not modify the file or the security information stored with the file in any way.

After the file server has used the dynamically built Windows NT security descriptor to determine whether the user has permission to access the file, the dynamically built Windows NT security descriptor is discarded. The next time a client attempts to access the file, the file server again dynamically builds a Windows NT security descriptor to determine the access permission for the file.

A significant consequence of this behavior, which is unique to the Advanced Server file server, is that the file security information for a file (whose security descriptor is built dynamically) can change when the security information in the directory structure above it changes. For example, assume a directory named ACCOUNT is owned by user JOHNSON and has full access for Everyone. User CARTER creates file CABINET in that directory. On a Windows NT system, the new file's security descriptor will include:

• CARTER as owner (creator gets ownership)
• Full access for Everyone (permissions inherited from the parent directory, ACCOUNT)

By default, the same would be true on an Advanced Server share. But, if the Store_Security_Aces parameter is changed from the default YES to NO, the security descriptor for file CABINET sets CARTER as the owner but does not store any access rights information. Nevertheless, when a client attempts to access the file CABINET, the file server dynamically determines that access to file CABINET is full access for Everyone (determining the access permissions from the parent directory, ACCOUNT).

If the access permissions for the ACCOUNT directory are changed to read access for Everyone, then on a Windows NT system, and by default, on an Advanced Server share, the access for file CABINET remains full access for Everyone (as originally inherited from the parent directory when CABINET was created). But, if the value of the Advanced Server Store_Security_Aces parameter is NO, the access for the shared file CABINET would be READ access for Everyone: the access permissions were not stored with CABINET at file creation, so the server builds the file's security descriptor dynamically, determining the file's access permissions from the parent directory, ACCOUNT.

4.1.3.6 Streamlining Security Information Storage and Lookups

As noted previously, the default propagation of security information to new files in shared directories can require that secondary headers be allocated for these files to store the security ACEs. Over time, this excessive consumption of file headers can cause excessive growth of the volume's index file, reducing the disk space available for creating new files. Techniques for minimizing file header usage are described later on in this section.

If disk space is not a problem, multiple extensions of the index file can still fragment the file across the volume, making access to the file headers less efficient, and eventually making further extension of the index file impossible. The solution is to make the index file contiguous, and make it large enough to help eliminate the need for further extensions in the future. However, be sure not to make the index file too large, or else space will be wasted.

You can make the volume and all of its files (including the index file) contiguous by performing a simple backup and restore of the volume. In addition, before doing the restore, you can initialize the volume with a larger index file, if appropriate. However, there is currently no easy way to determine how much the index file has grown, how many times it has grown (how fragmented it has become), or how many free headers it currently contains. For details on making the index file contiguous and estimating an appropriate size for the index file, see Section 4.1.3.6.1, Managing the Index File on a Volume with Shared Files.

If consumption of disk space is a problem, you can change the LANMAN.INI Store_Security_Aces keyword's value to NO. The default value (YES) causes the file server to write a complete set of Windows NT security information to a new file's ACL. By changing the keyword value to NO, you limit the amount of security information stored with the new file: only the ownership information is represented in the file's ACL, and all the file access permission ACEs are excluded. This keyword is stored in the VMSSERVER section of the LANMAN.INI file.

Note the tradeoffs between using the default (YES) or changing the parameter to NO, described in Table 4-4. In short, setting the parameter to NO saves file header usage but might result in increased file access times. Because the security information is not propagated to the files in a directory, the file server must look up the directory tree to determine missing information.

Table 4-4 Tradeoffs Regarding the STORE_SECURITY_ACES Parameter Settings

	If using the default (store all security information)	If setting to NO (store owner information only)
Server Behaves as Windows NT does?	Yes	No
Performance	Faster	Slower
File Header Usage	Higher	Lower
How Security Settings Are Determined	Direct from files	Dynamically, using the file's directory tree

If security problems arise because of inappropriate ACEs on files, or if you want to minimize consumption of disk space by index blocks required for storage of ACEs, use the Advanced Server utility SYS$SYSTEM:PWRK$FIXACE.EXE. This utility optimizes disk storage by compressing ACEs, removing unnecessary ACEs, and preventing ACEs from being propagated to files created in shares.

Invoke this utility as follows:

$ MCR PWRK$FIXACE

In addition, you can clean up unwanted ACEs by using the PWRK$DELETEACE utility, as documented in Section 4.1.3.7, Removing PATHWORKS ACEs. This utility will help you reclaim disk space.

4.1.3.6.1 Managing the Index File on a Volume with Shared Files

This section provides examples of the image backup and restore operations that make the index file (and all other files) on a volume contiguous.

To make the index file on a volume contiguous, follow these steps. For details, refer to the OpenVMS System Manager's Manual.

1. Perform an image backup of the volume, using the OpenVMS DCL BACKUP/IMAGE command.
2. If a larger index file is indicated, manually reinitialize the volume, using the /HEADERS qualifier to specify an appropriate value for the number of headers to allocate. For more information about how to determine the appropriate value, see Section 4.1.3.6.2, Determining the Number of Index File Headers to Allocate.

   $ INITIALIZE/HEADERS=n disk_volume:

3. Restore the backup using the OpenVMS DCL BACKUP/IMAGE command. If the disk was manually initialized in step 2, then the /NOINITIALIZE qualifier is also necessary to preserve the new index file size.

This section explains how to determine whether a larger index file is indicated, and if so, how many file headers to specify with the INITIALIZE/HEADERS command. As stated previously, there is no easy way to determine how much the index file has grown, how fragmented it has become, or how many free headers it currently contains.

You can estimate whether the index file should be made larger by monitoring the size of the index file and the total count of all shared files on the volume. Suppose you observe that an index file is growing rapidly, most likely because of an increase in the number of shared files on the volume. If you can estimate how much the number of shared files might grow in the future, you can calculate how much larger the index file might become as well. From this value, you can approximate the total number of headers to specify.

If you suspect that the index file is fragmented, but have no data to support any estimates, you may still perform the image backup and restore without changing the index file size, and then start monitoring the volume as described above.

For example, assume earlier monitoring revealed these results:

$ DIRECTORY/SIZE DKB0:[000000]INDEXF.SYS Directory DKB0:[000000] INDEXF.SYS;1 24426 Total of 1 file, 24426 blocks. $ DIRECTORY/GRAND_TOTAL DKB0:[SHARE_DIRECTORIES...] Grand total of 56 directories, 13512 files.

Assume current monitoring reveals the following results:

$ DIRECTORY/SIZE DKB0:[000000]INDEXF.SYS Directory DKB0:[000000] INDEXF.SYS;1 90704 Total of 1 file, 90704 blocks. $ DIRECTORY/GRAND_TOTAL DKB0:[SHARE_DIRECTORIES...] Grand total of 73 directories, 37182 files.

Then you can calculate the increase in file count and the associated increase in the size of the index file. In this example, these calculations are as follows:

Shared file count increase = 37,182 - 13,512 = 23,670 files Index file size increase = 90,704 - 24,426 = 66,278 blocks.

If you estimate that the number of shared files will grow to 120,000 in the lifetime of the current configuration, then the number of files will have increased by 82,818 files (subtract 37,182 from 120,000).

From that calculation, you can estimate the index file growth by use of simple proportions, where the ratio of the projected file count increase to the projected index file header increase (n) is equal to the ratio of the observed file count increase (23,670 files) to the observed index file header increase (66,278 blocks):

82,818 23,670 ------ = ------ n 66,278

Thus, the projected index file header increase (n) is calculated as follows:

82,818 * 66,278 n = --------------- = 231,897 blocks 23,670

The total size of the future index file will then be its current size plus the projected increase, or:
24,426 + 231,897 = 256,323 blocks

Given that each file header occupies one disk block, and assuming for simplicity that the entire index file consists of file headers (this is an overestimation), the total number of headers needed in the future is 256,323. Thus, to initialize the volume, you would specify this value for the /HEADERS qualifier in the INITIALIZE command mentioned in step 2 in the preceding section.

You can also apply this same reasoning independently to any other product that maintains a large number of files on the volume, such as MAIL or ALL-IN-1, or products such as POLYCENTER HSM (Hierarchical Storage Management) for OpenVMS that maintain file headers in INDEXF.SYS when shelving specified files.

4.1.3.7 Removing PATHWORKS ACEs

To remove some or all ACEs associated with Advanced Server for OpenVMS and PATHWORKS products, use the SYS$SYSTEM:PWRK$DELETEACE.EXE utility provided with the Advanced Server software.

The PWRK$DELETEACE utility allows you to selectively remove:

• PATHWORKS and Advanced Server for OpenVMS file attribute ACEs (the utility refers to these ACEs as "PW ACEs"). When you display file ACEs (see Section 4.1.3.8, Displaying Advanced Server for OpenVMS and PATHWORKS ACEs), these begin with "UNKNOWN=%X80" and are used by Advanced Server for OpenVMS, PATHWORKS V6 for OpenVMS (Advanced Server), and PATHWORKS V5 for OpenVMS (LAN Manager) to store file attributes and dates. These ACEs should be removed only on files that are no longer accessed by the server.
• Advanced Server for OpenVMS and PATHWORKS V6 for OpenVMS (Advanced Server) security ACEs. These ACEs begin with "UNKNOWN=%X86" and are used to store Windows NT-style security information, such as owner, DACL, and SACL.
• PATHWORKS V5 for OpenVMS (LAN Manager) security ACEs. These begin with "UNKNOWN=%X82".
• PATHWORKS V4 ACEs. V4 ACEs begin with "IDENTIFIER =PCFS$READ", "IDENTIFIER=PCFS$UPDATE", or "APPLICATION".
• PATHWORKS for OpenVMS (Macintosh) comment ACEs (the utility refers to these as "AFP Comment ACEs").

The following example shows how the PWRK$DELETEACE utility works:

$ MCR PWRK$DELETEACE Exit=x File Spec: DKA200:[LMSHARES.CSCSEC]*.* Cancel=x Delete V4 ACEs Y/N: Y Cancel=x Delete PW ACEs Y/N: Y Cancel=x Delete V5 security ACEs Y/N: Y Cancel=x Delete V6 security ACEs Y/N: Y Cancel=x Delete AFP Comment ACEs Y/N: Y DKA200:[LMSHARES.C CSCSEC]DEFAULT_SECURITY.EXAMPLE;1 ACEs removed DKA200:[LMSHARES.CSCSEC]NEW__20FOLDER.DIR;1 ACEs removed DKA200:[LMSHARES.CSCSEC]WYSIWYG.EXAMPLE;1 ACEs removed Exit=x FileSpec: x $

4.1.3.8 Displaying Advanced Server for OpenVMS and PATHWORKS ACEs

On OpenVMS Version 6.2 systems, you can display information about PATHWORKS ACEs by using the DCL SHOW SECURITY, DIRECTORY/SECURITY, or DIRECTORY/FULL command for files that contain ACEs. On OpenVMS Version 7.1 and later systems, if you use any of these commands for files containing PATHWORKS ACEs, the hexadecimal representation for each ACE is not displayed. Instead, the commands summarize the total number of ACEs encountered for each file in this message:

"Suppressed n PATHWORKS ACES."

To display the suppressed ACEs, use the DCL DIRECTORY command with the /NOSUPPRESS qualifier along with either the /FULL, /SECURITY, or /ACL qualifier.

4.1.4 Controlling User Access to Disk Resources

By default, when a directory is shared, all users have full access to the share. To control user access to disk resources, you can assign users to the groups that have the appropriate access permissions, or you can assign permissions directly to shares. Administratively, it is easier to use group permissions than user permissions to grant access.

You can set or modify the permissions at the share level (using the ADD SHARE/PERMISSIONS= or MODIFY SHARE/PERMISSIONS= command). You can also assign permissions to specific files or directories within a shared directory (using the SET FILE/PERMISSIONS= command).

Share permissions determine which users can access the shared directory or file, and the type of access those users are allowed. These permissions control network access to the directory or file.

In general, the simplest method to control access to disk resources is to assign FULL access for Everyone to the share (the default), and then restrict access at the directory or file level with the SET FILE command. For more information, see Section 4.3.5, Planning File and Directory Access Permissions, and Section 4.3.6, Specifying File and Directory Access Permissions.

4.1.4.1 Administrator Access

Server administrators can access all resources shared on a server, but only if they have the appropriate access permissions set for those resources. Access permissions apply to administrators as well as ordinary users. However, network administrators can always take ownership of a file or directory.

4.1.4.2 Group Access

If a user belongs to two groups, both of which are assigned access permissions for a resource, then that user has all access permissions assigned to both groups. For example, if the MUNCHKINS group has RW (Read and Write) access permission and the WINKIES group has E (Execute) access permission for the resource REPORTS, then a user who is a member of both groups has RWE access permissions for that resource. A user account that is a member of a group that has been denied access gets no access. (See Section 3.2, Managing Advanced Server Groups, for more information about network groups.)

4.1.4.3 User Access

If you assign access permission explicitly to a specific user, that user has only that access permission, regardless of the permissions assigned to any groups that include that user. For example, a user who is a member of the groups MUNCHKINS and WINKIES, but who has been assigned only R (Read) access permission for the share GREATOZ has only Read permission for GREATOZ. If the user is also in a group denied access, the user has no access.

4.1.4.4 Access Checks

In general, the ability to connect to a resource does not guarantee the ability to perform operations with that resource. If the user name and password match an account in the security accounts database, the user is granted access based on the permissions set on the resource. If the user name is invalid, the user may be able to access the resource as a Guest.

If the resource is a file or directory, the server performs the following checks:

1. For a file, the server checks access permission on the file and the share. Both the file and the share must grant the requested access. If access is permitted, the server continues to step 2. If the check fails at any level, the server denies access.
2. If the Advanced Server and OpenVMS security model is enabled, the server verifies OpenVMS access to the resource based on the host mapped OpenVMS user name.

The Advanced Server automatically creates special shares for administrative and system use. Only network administrators can change their properties. Table 4-5, Network Administrative Shares, lists some of the default shares created when the software is installed.

Table 4-5 Network Administrative Shares

Share Name	Type	Description
ADMIN$	Directory	The Admin share, a special administrative resource for remote administration.
C$	Directory	The root share, an administrative resource that provides a connection to the root of the directory tree containing the Advanced Server's data files. On an Advanced Server, C$ is equivalent to PWRK$LMROOT:[000000].
IPC$	IPC	The IPC share, an administrative resource that supports interprocess communication.

A server's administrative shares allow network administrators to perform certain tasks on the server, including examining the shares, administering the server remotely, and running distributed applications.

Administrative shares include ADMIN$, IPC$, and disk administrative shares. They are hidden from most network users; only administrators can see information about them using the ADMINISTER command-line interface. To display information about hidden shares, including administrative shares, include the /HIDDEN qualifier on the ADMINISTER command SHOW SHARES. For example:

LANDOFOZ\\TINMAN> SHOW SHARES/HIDDEN Shared resources on server "TINMAN": Name Type Description ------------ --------- ----------------------------------------- ADMIN$ Directory Admin Share ALP072$ Directory C$ Directory PATHWORKS share IPC$ IPC IPC Share NETLOGON Directory Logon Scripts Directory PAGE_TINMAN$ Directory PWLIC Directory PATHWORKS Client License Sftwr PWLICENSE Directory PATHWORKS Client License Sftwr PWODS5$ Directory PWROOT$ Directory PWTEST Directory PWUTIL Directory Adv. Srv. Client-based Utilities USERS Directory Users Directory Total of 13 shares

The following sections explain the function of each administrative share and compare how these shares are shared.

4.2.1 The ADMIN$ Share

The ADMIN$ share controls access to server administration functions. A server's ADMIN$ share must be shared if that server is to be administered remotely. When a server starts, Advanced Server automatically shares ADMIN$. You cannot stop sharing the ADMIN$ share.

When you begin an administration session, Advanced Server makes a connection to the ADMIN$ share.

4.2.2 The IPC$ Share

The IPC$ share controls interprocess communication, such as communication between different components of a program, different computers running parts of a single program, or two programs working together. In the Advanced Server environment, interprocess communication occurs when a user or administrator:

• Views a list of a server's available resources
• Administers the server remotely
• Runs a distributed application

Servers share the IPC$ share automatically. You cannot stop sharing the IPC$ share. When the IPC$ share is needed, Advanced Server makes a connection to it automatically.

4.2.3 Disk Administrative Shares

The Advanced Server automatically defines disk devices as shares by offering all mounted disk devices as autoshares (automatic shares) at server startup time. An autoshare points to the top-level (root) directory on the disk. For example, if you connect to the autoshare USER1_DISK$, a volume label, you access the directory USER1_DISK:[000000].

Only administrators can connect to disk administrative resources. Such connections allow access to all directories and files on the disk. Administrators working at remote servers or clients cannot make these connections if the ADMIN$ and IPC$ resource are not shared.

	privacy and legal statement
6556PRO_010.HTML