HP OpenVMS Systems

1. Windows users and groups to OpenVMS usernames (UICs) and resource identifiers
2. Windows permissions to OpenVMS permissions.

The following sections describe the Windows to OpenVMS user and group mapping and the permission mapping provided by CIFS.

User Mapping
User mapping involves mapping users belonging to the Windows domain where CIFS is a member, the domains trusted by it and the CIFS server, to OpenVMS usernames (UICs). There are three ways using which CIFS maps these users to OpenVMS usernames:

1. Automatic user mapping provided by WINBIND.
2. Implicit user mapping – A domain user with the same username in SYSUAF on OpenVMS is implicitly mapped. CIFS local users are also mapped using this mechanism.
3. Explicit user mapping - Using username map file, domain users can be explicitly mapped to any OpenVMS username.

Automatic User Mapping
Users belonging to the Windows domain where CIFS is a member or the domains trusted by it can be automatically mapped to OpenVMS usernames provided that WINBIND is enabled and a valid idmap UID range is available in the Samba Configuration File. This will be explained in detailed under the topic ‘The role of WINBIND in CIFS File Security’.

Implicit User Mapping
A user belonging to the Windows domain where CIFS is a member or the domains trusted by it can be implicitly mapped to an OpenVMS username provided the names are same.  For example, when a user ANITA belonging to the Windows domain connects to CIFS Server, the user ANITA is implicitly mapped an OpenVMS username ANITA, if it exists.

By default, CIFS local users are implicitly mapped to OpenVMS usernames. This is because, a CIFS local user can be created using pdbedit utility, only if a matching OpenVMS username exists in SYSUAF on OpenVMS. For example, to create a CIFS local user STEFFI, you must first create or ensure that an OpenVMS username STEFFI exists in SYSUAF database.  The CIFS user accounts database file, SAMBA$ROOT:[PRIVATE]PASSDB.TDB maintains records related to CIFS local users.

Explicit User Mapping - Mapping domain users using username map file
Explicit user mapping allows you to map users in the Windows domain where CIFS is a member and the domains trusted by it to any OpenVMS username using a username map file.

CIFS supports mapping of multiple domain users to a single OpenVMS username. In this case, the domain users that have been mapped to a single OpenVMS username share the File Security that has been specified for that mapped OpenVMS username. For example, if a directory and the sub directories and files under it are owned by a mapped OpenVMS username ASVUSER, then all the domain users that are mapped to OpenVMS username ASVUSER have access to this directory and the sub directories and files under it. The same is applicable if the mapped OpenVMS username ASVUSER has been explicitly granted resource identifiers in the SYSUAF database, and File Security on any object in a CIFS share contains security for these resource identifiers. In this case, all the domain users that have been mapped to the OpenVMS username ASVUSER will also be able to access objects based on the resource identifiers that have been granted to the user ASVUSER in SYSUAF.

The following examples provide information on how to setup explicit user mapping:

Edit the username map file, SAMBA$ROOT:[LIB]USERNAME.MAP and add the user mappings in any of the following ways based on your CIFS setup requirements:

# The text following a hash (#) or a semi-colon (;) indicate comment lines.
# You can add your own comment lines by prefixing the text with a hash or a semi-colon

; Example for mapping a user in Windows domain (CIFSDOM) to OpenVMS username
SYSTEM=CIFSDOM\administrator

; Example for mapping multiple Windows domain users to a single OpenVMS username
ASVUSER=CIFSDOM\tunga CIFSDOM\kaveri

; Example for mapping a user in trusted domain (TRUSTDOM) to an OpenVMS username
CIFSUSER=TRUSTEDOM\neela

; An example of username map search stopping after encountering the required mapping
!GANGA=CIFSDOM\GANGES

; An example for mapping all the users connecting to CIFS to a single OpenVMS username
cifs$default=*

NOTE:

1. By default, the Samba configuration file parameter “username map” points to the CIFS supplied username map file, SAMBA$ROOT:[LIB]USERNAME.MAP
2. If you create your own “username map” file, ensure that it is in Stream or Stream_LF record format. Then you must update the Samba Configuration file parameter “username map” to point to your own username map file.
3. Do not use “cifs$default=*” unless you want to grant same File Security permissions to all the users connecting to CIFS.

Group Mapping

Group mapping in CIFS involves mapping domain global groups belonging to the domain where CIFS is a member, the domains trusted by the domain and the CIFS server, to OpenVMS resource identifiers.

The only supported mechanism for mapping global groups belonging to the domain where CIFS is a member and the domains trusted by it, to OpenVMS resource identifiers is the automatic mapping provided by WINBIND. This will be explained in detail under the section ‘The role of WINBIND in CIFS File Security’.

A CIFS local group can be explicitly mapped to an OpenVMS resource identifier using the command “NET GROUPMAP ADD”. This command automatically creates the CIFS local group as well as the required mapping with the OpenVMS resource identifier. The CIFS group mapping database file, SAMBA$ROOT:[VAR.LOCKS]GROUP_MAPPING.TDB stores the information about CIFS local groups, members of CIFS local groups and the mapping between CIFS local groups and OpenVMS resource identifiers.

Summary

To summarize, CIFS local users and groups cannot be automatically mapped by WINBIND. Automatic mapping of users and groups by WINBIND is applicable only to users and groups in the Windows domain (where CIFS is a member) and the domains trusted by it.

1. Automatic Mapping - For domain users and groups, WINBIND automatically creates the corresponding OpenVMS users and groups (resource identifier) if a mapping for the same does not exist.
2. Nested Group Support – Using nested groups, domain global groups can be added to CIFS local groups (thus, a group-within-a-group, or "nested" groups). Nested groups are defined locally on any machine and can contain users and global groups from the domain (where CIFS is a member) and the domains trusted by it.
3. Trusts - WINBIND is required for all Trust functionality when CIFS is a PDC.

The winbind functionality provided by CIFS is controlled though the logical, WINBINDD_DONT_ENV. If it is disabled or not defined on a CIFS node, CIFS provides WINBIND support and if it is enabled by defining it to 1, CIFS turns off the WINBIND support. As this logical is not defined by default, CIFS provides WINBIND support by default. When CIFS is a Member Server, automatic mapping and nested group support provided by WINBIND play an important role in CIFS File Security. Due to this, it is recommended not to disable WINBIND support on a CIFS Member Server by defining the logical WINBINDD_DONT_ENV.

Though CIFS provides WINBIND support by default, the automatic mapping feature provided by WINBIND is enabled, only if you have specified a valid “idmap UID” and “idmap GID” range in the Samba Configuration File. The next topic ‘Automatic Mapping’ describes this in detail and the importance of automatic mapping in CIFS File Security.

Automatic mapping:

One of the purposes of WINBIND is to automate the creation of OpenVMS UICs and resource identifiers (in POSIX GID format) and maintain their correspondence to the appropriate Windows SIDs to minimize identity management efforts. The WINBIND identity mapping database file, SAMBA$ROOT:[VAR.LOCKS]WINBINDD_IDMAP.TDB maintains the mapping between Windows SIDs and OpenVMS UICs and resource identifiers. The mapping between a Windows SID and an OpenVMS username or a resource identifier is created only if there is no existing mapping entry in this database file. If the required mapping is missing, the automatic creation and mapping of OpenVMS usernames and groups (resource identifiers) occurs under the following two circumstances:

1. After the user is successfully authenticated, CIFS tries to map the authenticated user and all the groups that the user belongs, to an OpenVMS username (UIC) and groups (resource identifiers). The domain or CIFS groups can be either nested groups or the groups that the authenticated user directly belongs. If a mapping is found missing for an authenticated user and if this user is also a domain user, WINBIND can automatically create the required OpenVMS username and then map this OpenVMS username to the authenticated user. Similarly, if the mapping is found missing for any of the domain global groups that the user belongs; WINBIND can create the required OpenVMS group (resource identifier) and map it to the domain group.
   
2. When setting security on files and directories in CIFS shares, if the security principal (subject) to whom you are granting the permission is a user or global group in the Windows domain (where CIFS is a member) or the domains trusted by it, WINBIND can create and map the required OpenVMS username (UIC) or resource identifier to a domain user or group SID.

When an OpenVMS username is created by WINBIND, it specifies a UIC for that username. Similarly, when it creates an OpenVMS resource identifier, it creates the identifier in POSIX group identifier format by supplying a GID value. In order for WINBIND to use the UIC and GID values specified by you while creating OpenVMS usernames and resource identifiers, WINBIND provides a mechanism, which allows you to explicitly specify a set of values for UICs and GIDs that are allocated solely to WINBIND. WINBIND obtains the user IDs (UIDs) used to assign a UIC value to an OpenVMS username, and group IDs (GIDs) used to assign a value to the POSIX group identifier (resource identifier) from the Samba configuration file global parameters "idmap UID" and "idmap GID". These parameters must be set to a range of values allocated solely to WINBIND. The next two sections explain the steps used by CIFS to create OpenVMS usernames and resource identifiers using “idmap UID” and “idmap GID” range of values. 

How does WINBIND map domain users to OpenVMS users?

WINBIND uses the chosen integer "idmap UID" value, to derive both the OpenVMS username and the UIC. The UID value is converted to a hexadecimal value and appended to the string "CIFS$" to derive the OpenVMS username. The UID value is converted to octal and the octal value is used as the UIC group and member number.

NOTE: Since UIC group numbers are limited to a maximum value of Octal 37776 (decimal 16382), the upper range limit on the "idmap UID value is 16382. Similarly, because UIC group numbers below Octal 376 are reserved for use by HP, it is recommended not to specify a value below 255 as the lower range of "idmap UID".

For example, if the Samba configuration file contains:
idmap uid = 1000-2000

WINBIND will initially allocate UID 1000 and create an OpenVMS user named CIFS$3E8 with a UIC of [1750,1750]. The username CIFS$3E8 is created with interactive login disabled, nodisuser flag enabled and with NETMBX and TMPMBX privileges only. After the user CIFS$3E8 is successfully created in SYSUAF, the mapping of UID 1000 (for user CIFS$3E8) to a corresponding domain user SID is then stored in the file, SAMBA$ROOT:[VAR.LOCKS]WINBINDD_IDMAP.TDB. This file must be backed up regularly to avoid the loss of the required mappings necessary to maintain file security.

How does WINBIND map domain groups to OpenVMS resource identifiers?

WINBIND uses the chosen integer "idmap GID" value, to derive both the OpenVMS resource identifier (group) name and group identifier (GID) value. The GID value is converted to a hexadecimal value and appended to the string "CIFS$GRP" to derive the OpenVMS resource identifier name.

NOTE: Because WINBIND creates POSIX Group Resource Identifiers (POSIX GID), the maximum value is limited to %xFFFFFF or %d16777215. The lower limit is 1. OpenVMS automatically adds %xA4000000 to the value chosen. When CIFS is installed on an OpenVMS system, by default it automatically uses the GID values %xFFFFF0 thru %xFFFFFF and thus the highest GID value that can be specified is limited to %xFFFFFEF or %d16777199.

 For example, if the SMB.CONF file contains:
 idmap gid = 5000-10000

WINBIND will initially allocate GID 5000 and create an OpenVMS resource identifier named CIFS$GRP1388. After the resource identifier CIFS$GRP1388 is successfully created in the RIGHTSLIST database on OpenVMS, the mapping of GID 5000 (for group CIFS$GRP1388) to a corresponding domain group SID is then stored in the file, SAMBA$ROOT:[VAR.LOCKS]WINBINDD_IDMAP.TDB. It is critical that this file is backed up regularly as its loss will result in loss of the required mappings necessary to maintain security.

NOTE:

1. In an existing CIFS configuration, if you have to increase the “idmap uid” or “idmap gid” range values, retain the lower value of the range as it is while increasing only the higher value in the range. For example, in the “idmap uid” range specified above, to increase “idmap uid” range, specify the new range as “1000-3000”. WINBIND will automatically adjust the existing “idmap uid” range while retaining the current mapping entries in the WINBINDD identity mapping database file. This guarantees that the existing security on files and directories that might have been set based on the existing mapping entries are still valid.
2. HP OpenVMS CIFS Administrator’s Guide contains the flow charts on how the user and group mapping occurs in CIFS.
3. WINBIND automatic mapping feature is disabled by default as CIFS does not provide default values for “idmap uid” and “idmap gid” parameters. If WINBIND is enabled, automatic mapping feature is enabled once the valid “idmap uid” and “idmap gid” range values are specified in the Samba configuration file.
4. From CIFS V1.2 onwards, “idmap uid” and “idmap gid” ranges can be specified through Samba configuration utility.

Domain users and groups mapped by WINBIND:

WINBIND does not map all the users and global groups in the domain (where CIFS is a member) or in the domains trusted by it, even if automatic mapping is enabled. Instead it maps only the following domain users and groups:

1. Users belonging to the Windows domain (where CIFS is a member) or the domains trusted by it, who successfully established connection to CIFS Server at least once.
2. The domain global groups in the Windows domain where CIFS is a member or the domains trusted by it that contain the successfully authenticated users as members.
3. Users and groups belonging to the Windows domain where CIFS is a member and the domains trusted by it, to whom the CIFS administrator explicitly granted permissions for any Share, File or directory on CIFS.

Tracking and managing users and groups created by WINBIND

As explained above, WINBIND uses the range of values specified for “idmap uid” and “idmap gid” parameters in the Samba configuration file while creating OpenVMS usernames and resource identifiers. When WINBIND runs out of either of these idmap ranges that are specified in the Samba configuration file, it will report errors in the CIFS client log files. The client’s log files will be created in the directory SAMBA$ROOT:[VAR].

CIFS provides a utility called WBINFO that can be used for viewing the OpenVMS usernames and resource identifiers created by WINBIND and the corresponding mapping to domain users and groups. You can execute the WBINFO utility as:

            $ @SAMBA$ROOT:[BIN]SAMBA$DEFINE_COMMANDS.COM
            $ WBINFO --hostusers-to-domainusers
            $ WBINFO --hostgroups-to-domaingroups

The option “--hostusers-to-domainusers”, displays the domain/CIFS users along with the mapped OpenVMS usernames. The option “--hostgroups-to-domaingroups”, displays the domain/CIFS groups alongside the mapped OpenVMS resource identifiers. These two options are meant only for viewing the mapped users and groups and it cannot be used for enumerating the users and groups either in SYSUAF database on OpenVMS or in the domain/CIFS databases.

To check for the mapping between a single OpenVMS username or resource identifier (group) and a domain user or group, execute the command:

            $ WBINFO --hostname-to-domainname=<OpenVMS username or resource identifier name>

When is automatic mapping provided by WINBIND required?

CIFS supports domain group to OpenVMS resource identifier mapping only through WINBIND. If you plan to set permissions on files and directories based on domain groups, automatic mapping provided by WINBIND is a must. Additionally, because WINBIND automates the OpenVMS username and resource identifier creation and the corresponding mapping with Windows SIDs, it can be used to avoid the manual administrative work related to identity management.

When is automatic mapping provided by WINBIND not required?

Automatic mapping provided by WINBIND need not be used if the following two conditions are satisfied:

1. All the domain users connecting to CIFS Server are either explicitly or implicitly mapped to the OpenVMS usernames.
2. Security Permissions on CIFS shares/files/directories are not based on domain global groups.

In this case, if you want to set permissions for domain global groups, then you must add them as members to CIFS local groups. Then, security on Files/Folders/Shares in CIFS can be set based on CIFS local groups. By virtue of nested group support provided by WINBIND, the security specified on an object for CIFS local groups that contain the domain global groups is automatically applicable to these domain global groups and the users belonging to them. The topic ‘Managing CIFS local groups’ provides examples on how to add domain users and domain global groups as members to CIFS local groups.

Nested group support:

As already mentioned, group within a group is referred to as nested grouping. Using the nested group support provided by WINBIND, you can add the following users and groups as members to CIFS local groups:

1. Users and domain global groups that belong to the Windows domain where CIFS is a member.
2. Users and domain global groups that belong to the domains trusted by the Windows domain where CIFS is a member.
3. Users and local groups in CIFS server database  

As explained under “When is automatic mapping provided by WINBIND not required?” topic, Nested group functionality allows you to setup File Security based on CIFS local groups. WINBIND supports nested groups even when automatic mapping feature provided by it is disabled.

The persona for the mapped OpenVMS user is made up of the following:

1. Mapped OpenVMS user’s UIC and resource identifiers. These resource identifiers are the successfully mapped identifiers for the domain/CIFS groups that the authenticated user belongs.
2. Default privileges of the mapped OpenVMS username in SYSUAF.
3. Any general identifiers that were explicitly granted by the OpenVMS administrator for the mapped OpenVMS username in SYSUAF.

When an authenticated domain/CIFS user tries to access an object in CIFS share, OpenVMS grants access to the object based on the persona of the mapped OpenVMS user mentioned earlier. The only exception to this is, when the authenticated user is part of “admin users” in CIFS. When a user belongs to “admin users” in CIFS, the authenticated user’s persona is same as that of the fully privileged user’s persona that was originally created by the SMBD process for authenticating the domain/CIFS user. By default, the SMBD process authenticates the domain/CIFS users using the persona of SAMBA$SMBD account.

NOTE:

1. CIFS mandatorily requires that an identifier with the same UIC value as the UIC of the mapped OpenVMS username is present in the RIGHTSLIST database. For example, for a mapped OpenVMS user named, STEFFI with a UIC of [600,600], there must be a corresponding identifier with a UIC of [600,600].
2. Even though CIFS provides user mapping, a user connecting to the CIFS Server cannot be authenticated based on the credentials of the mapped OpenVMS username in SYSUAF.
3. SAMBA$SMBD account is created by CIFS as part of CIFS installation.

Windows to OpenVMS Permission Mapping

OpenVMS allows you to specify READ (R), WRITE (W), EXECUTE (E), DELETE (D) or CONTROL (C) access permission on an object or a combination of RWEDC permissions (Refer note). On Windows, you can specify ‘Full Control, Modify, Read and Execute, List Folders Contents (for directories only), Read, Write’ standard permissions on an object using the ‘Security’ dialog box. Using the ‘Advanced Security Setting’ dialog box, Windows provides special permission setting. “Table 1 - Windows Permissions to OpenVMS permissions mapping” gives the list of Windows permissions that are mapped to corresponding OpenVMS permissions by CIFS. The “Advanced” in brackets indicates that this permission is available on Windows, only under the ‘Advanced Security Setting’ dialog box. ‘Full Control’ and ‘Read’ permissions are part of standard as well as special permissions.

Table 1 – Windows Permissions to OpenVMS Permission Mapping

NOTE: Though the access permission, ACCESS=NONE specified on an object on OpenVMS is honoured by CIFS as it depends on OpenVMS to grant access, CIFS does not support setting this access permission on an object from a Windows system.

Windows Inheritance Value to OpenVMS inheritance mapping

On a Windows system, when setting permissions on a directory, you can specify if the access is applicable only to that directory or to the subfolders and files that will be created under it or to a combination of these.

Similarly, OpenVMS provides DEFAULT ACLs for the directories that are applicable only to the files and directories created under it while the access to the directory is controlled by the access ACE on the directory. “Table 2 – Windows inheritance value to OpenVMS inheritance mapping” provides information about Windows to OpenVMS inheritance mapping provided by CIFS.

            Table 2 - Windows inheritance value to OpenVMS inheritance mapping

Mapping OpenVMS RMS protection code to Windows Permissions

By default, OpenVMS automatically sets the protection code (RMS protection code) on each object when it is created. Though the ACLs on an object are optional, the protection code is a must. The syntax of the protection code consists of permissions for SYSTEM, OWNER, GROUP, and WORLD categories. Optionally, OpenVMS lets you specify inheritable DEFAULT_PROTECTION ACE on the directories that consists of protection code for these categories. The protection code specified in this ACE will be applied to the newly created files within the directory and the newly created directories within the parent directory will inherit this ACE.

On a Windows system, it has OWNER category to indicate the owner of the object and Everyone group that contains all the users on the Windows system. CREATOR OWNER and CREATOR GROUP present on the parent directory specify the permissions that will be inherited by the child objects for OWNER and the primary group of the owner respectively.

“Table 3 – OpenVMS RMS protection code category mapping to Windows mapping” shows the mapping provided by CIFS for OpenVMS protection code category to corresponding Windows mapping.

Table 3 - OpenVMS RMS protection code category mapping to Windows mapping

1. The directories and files are newly created
2. Security permissions are explicitly set on the directories.

From CIFS patch set PS009 for CIFS V1.1 ECO1 onwards, the way these SMB.CONF parameters control OpenVMS RMS protection code have been simplified. Due to this, the implementation of many SMB.CONF parameters related to File Security is quite different on CIFS for OpenVMS when compared to Open Source versions of Samba (which are primarily based on the UNIX security model).

With this simplification, CIFS now allows OpenVMS to determine security using standard security rules when new files and directories are created. CIFS then adjusts the RMS protection code and owner based on various SMB.CONF parameters; however, the defaults for these parameters are such that they will not modify the security that OpenVMS would apply (with exceptions noted).

The following SMB.CONF parameters can be used to modify security applied by OpenVMS:

1.  inherit owner - The default value is "no".  If set to "yes", causes CIFS to set the RMS owner of new objects to that of the parent directory.

            NOTE: If "inherit owner = no" and a parent directory is owned by a Resource Identifier, when a non-privileged user who has WRITE access to this directory, creates a new file, CIFS sets the Owner to the UIC of the user creating the file, rather than the Resource Identifier. Thus, in order to retain the OpenVMS behavior (i.e., to set the resource identifier as owner), add "inherit owner = yes" to the applicable [share] sections of the SMB.CONF file. This will be addressed in a future release.

2. inherit vms rms protections - This is a new parameter with a default value of "no". If set to "yes", causes CIFS to:

1. Set the RMS protection code to that of parent directory.
2. Ignore a DEFAULT_PROTECTION ACE, if present.
3. Ignore the RMS protection mask specified by the SYSGEN parameter RMS_FILEPROT.
4. Ignore the mask and mode parameter values specified in the SMB.CONF file.

3. “Table 4 – mask and mode parameters” provides the list of mask and mode parameters supported by CIFS. The value of the appropriate "mask" parameter is AND'd with the result of the RMS protection code that OpenVMS would apply.  This result is then OR'd with the value of the appropriate mode parameter:

Table 4 – mask and mode parameters

NOTE:

1. CIFS for OpenVMS does not use the SMB.CONF parameters "security mask" and "force security mode" when a Windows user modifies the security of a file.
2. As "create mode" parameter is same as "create mask" parameter, if required, use "create mask" parameter instead of "create mode".
3. The following mask and mode parameter are related for doing AND & OR operation to  generate a resultant RMS protection code:

1. "create mask" and "force create mode"
2. "directory mask" and "force directory mode"
3. "directory security mask" and "force directory security mode"

1. By default, the value of the mask parameters is 07777 and that of mode parameters is 00000 with the only exception of “force directory mode”. From CIFS version 1.2 onwards, the default value for “force directory mode” is 04000. This is to allow DELETE permission for OWNER category of the protection code when a new directory is created.

SMB.CONF parameters that cannot be modified

The following SMB.CONF parameters must not be modified from their default values and if you modify the value to a non-default value, it is not supported by CIFS:

1. inherit acls                     - Default is "yes"; you cannot disable inheritance of ACLs
2. inherit permissions           - Replaced by the "inherit vms rms protections" parameter
3. security mask                 - Not supported
4. force security mode         - Not supported

Delete access support for RMS protection code when using mask and mode parameters

One of the significant changes introduced with the release of patch set PS006 for CIFS V1.1 ECO1 concerns granting DELETE access in the RMS protection code on new objects. Previously, the various mask and mode parameters tied DELETE access to the WRITE bit; i.e. if you enabled WRITE access you also enabled DELETE access. However, with the release of PS006, DELETE and WRITE protections have been separated as documented below.

In addition, with the release of patch set PS009 for CIFS V1.1 ECO1, the default values for the mask and mode parameters have been changed such that they will not adjust the security that OpenVMS would itself apply (except where noted).

The values for the mask and mode parameters now have this significance:

<mask or mode parameter name> = 0dogw

Where:
'0' = Indicates the value is Octal
'd' = Controls granting DELETE access across all categories of the RMS protection code (see   below)
'o' = Controls granting READ, WRITE, and EXECUTE access for the Owner category of the RMS protection code
'g' = Controls granting READ, WRITE, and EXECUTE access for the Group category of the RMS protection code
'w' = Controls granting READ, WRITE, and EXECUTE access for the World category of the
RMS protection code

NOTE: The System category of the RMS protection code receives the same permission as the Owner category; there is no option to modify this behavior.

DELETE access is signified using a bitmask with the following values:

            4 = Grant DELETE access to Owner category of RMS protection code
            2 = Grant DELETE access to Group category of RMS protection code
            1 = Grant DELETE access to World category of RMS protection code

    The Owner, Group, and World access values are also bitmasks which signify the following access:

            4 = Grant READ access
            2 = Grant WRITE access
            1 = Grant EXECUTE access

Due to the contrasting nature of Windows and OpenVMS systems’ ACL processing, it is important to understand the order in which the ACLs are applied by CIFS when setting security on an object. When a CIFS administrator sets security permission on an object present in the CIFS share from a Windows system, CIFS first converts these Windows permissions to OpenVMS permissions. If the security was applied for users and groups, the converted OpenVMS permissions will contain OpenVMS ACLs for the mapped OpenVMS usernames and resource identifiers. After this conversion, CIFS applies the OpenVMS ACLs on the object. While applying OpenVMS ACLs on an object, CIFS must preserve the existing OpenVMS specific ACLs that would have been added by an OpenVMS administrator and these ACLs should ideally be retained in their original order (Refer note for information about OpenVMS specific ACEs). For example, on an OpenVMS system, users who fail to have access to a file based on any of the top order ACEs could be granted READ access by using an ACE, (IDENTIFIER=*,ACCESS=READ). Typically, an ACE similar to this would be present at the bottom of ACLs. CIFS, when setting permission, needs to ensure that this ACE is almost always present at the bottom of the ACLs on an object. Due to this reason, following design is implemented in CIFS when applying security on an object from a Windows system:

1. When a new ACE for a user or group is applied on an object in a CIFS share from a Windows system, after converting the Windows ACE to OpenVMS ACE format, CIFS applies this ACE at the top of the OpenVMS ACL order on an object.
2. While modifying an existing ACE for a user or group on an object in a CIFS share from a Windows system, after converting the Windows ACE to OpenVMS ACE format, CIFS finds out the location of the existing ACE that is getting modified. Then, it replaces the existing ACE with a modified ACE entry at the same location.
3. All the OpenVMS specific ACEs like AUDIT, ALARM, IDENTIFIER=*, PROTECTED and HIDDEN are retained in their existing locations.

NOTE: OpenVMS specific ACEs like AUDIT, ALARM, IDENTIFIER=*, PROTECTED, and HIDDEN that exist on an object in a CIFS share cannot be viewed or modified from a Windows system.

1. Object access
2. File permission setting
3. Built-in Administrators group
4. Windows inheritance value mapping
5. Windows permission mapping
6. Viewing permissions on a directory from Windows

Object access limitation:

As mentioned in Windows File Security, Windows systems allow access to an object based on the accumulated access permissions for an object unless the user has special rights. Refer section ‘Windows File Security’ to understand how Windows derives accumulated access permissions for an object. Thus the order in which the ACLs appear on an object has no importance on Windows systems.

On OpenVMS systems, the order in which the ACLs appear on an object is very important. This is because OpenVMS grants access to an object based on the first matching ACE that it encounters from the top of ACE list unless the user has special privileges or is an owner of the file.

When a user tries to access an object in a CIFS share from a client system, CIFS lets the OpenVMS system to decide access to the user based on the persona of the mapped OpenVMS user that was created by CIFS. According to the OpenVMS security rules, if the user is not an owner of the object and has no special privileges, user connecting to CIFS would be granted access to an object based on the first matching ACE encountered by OpenVMS system on that object. This can lead to access permission limitation in the following scenario:

A user ANITA belongs to two domain global groups FINANCE and ACCOUNTS. On an object, an ACE corresponding to one of the domain global groups FINANCE is granted READ access and is above the ACE corresponding to another domain global group ACCOUNTS which has full permissions (RWEDC).  When a user ANITA that belongs to these 2 domain global groups access this object on a CIFS share, OpenVMS grants read only access to this user for the object based on the first matching ACE. On this object, the first matching ACE for the user ANITA is for the domain global group FINANCE. Thus, the ACE corresponding to the domain global group ACCOUNTS which has higher access permissions is not exercised for the user ANITA when the object is accessed by this user. This is an architectural limitation.

The workaround to this problem is to set security on an object in a CIFS share path from an OpenVMS system. While doing so, it must be ensured that the ACEs with highest access permissions are at the top of ACL order and the ACEs with lowest access permissions are at the bottom of ACL order.

File Permission setting limitation:

CIFS does not support exclusive permission setting on a file, though the same is supported for directories/folders. For example, in a directory with 100 files and folders under it, one user may have READ access to this directory and the files and folders under it. Just for a single file in this directory, you may want to grant modify (RWED) access for this user. This is not supported by CIFS with one exception. The exception to this problem is, either you make this user as OWNER of the file or grant ‘Change Permission’ (CONTROL) access to the file for this user. You may want to use this workaround only if you want this user to have control access to this file and not otherwise.

CIFS does not support exclusively specified OpenVMS specific ACEs (like PROTECTED, HIDDEN etc) on a file though the same is supported for directories. For example, in a directory with 100 files and folders, you might have exclusively set an AUDIT ACE on a particular file in this directory. A user with modify (RWED) access to this file, opens it, then saves the modified file and closes it. The AUDIT ACE that was exclusively set on this file might have been lost after the file was closed. This is particularly applicable for Microsoft office application files. The only workaround to this problem is to apply an inheritable default ACEs on the parent directory. This will lead to all the files and sub directories under the parent directory inheriting the ACE.

Built-in Administrators group limitation:

Prior to CIFS patch set PS005 for CIFS V1.1 ECO1, all the members of CIFS built-in (local) Administrators group were granted the two special OpenVMS privileges, BYPASS and SYSPRV. This allowed full administrative privileges to users belonging to built-in ‘Administrators’ group. By virtue of nested grouping, if the built-in ‘Administrators’ contained any other CIFS local groups or domain global groups (like ‘Domain Admins’), the users belonging to these nested groups were also granted the BYPASS and SYSPRV privileges. Due to this, these users were automatically entitled to perform CIFS Administrative work like File Security setting, user and group management and so on. From CIFS patch set PS005 for CIFS V1.1 ECO1 onwards, members of built-in Administrators group are no longer granted BYPASS and SYSPRV privilege. As a result, though the members of built-in ‘Administrators’ group can perform rest of the administrative work, they cannot set security on files and folders. Next section describes how the members belonging to built-in ‘Administrators’ group can be granted permission on files and directories for managing security on the same.

Windows inheritance value mapping limitation

When setting permissions on a directory in CIFS share from a Windows system, Windows provides multiple options on how the permissions can be applied on a directory. CIFS does not support ‘Subfolder only’ and ‘Files only’ Windows inheritance value options. Refer to “Table 2 - Windows inheritance value to OpenVMS inheritance mapping” for interpretation of rest of the Windows inheritance value options and their mapping to OpenVMS ACEs.

Windows permissions mapping limitation

CIFS does not support the special permission ‘Delete Subfolder and Files’ options that is available from the permissions list in the ‘Advanced Security Setting’ dialog box. If you try to set permission for this option, you are likely to encounter “Access denied” error.

Limitation in viewing permissions on a directory from Windows

From Windows, when viewing permissions on a CIFS directory or share using the ‘Security’ dialog box, you will see empty permissions for users and groups. This does not correctly reflect the permissions existing for the users and groups on that directory or share. In order to correctly view permissions on a CIFS directory or share, always use ‘Advanced Security Setting’ dialog box. In the ‘Security’ dialog box, click on ‘Advanced’ tab to go to ‘Advanced Security Setting’ dialog box.

On the other hand, you can correctly view permissions on files in a CIFS folder using the ‘Security’ dialog box itself.

Permissions for users belonging to built-in Administrators group:

The topic ‘Built-in Administrators group limitation’ mentioned the reasons why a user who belongs to built-in Administrators either directly or through nested grouping, can no longer set File Security or access files and directories in CIFS shares. CIFS provides an alternative option such that all the users belonging to the built-in Administrators group either directly or through nested grouping, can still manage File Security on files and directories in a CIFS share. To use this option, you should grant READ access to the files and directories in CIFS shares for the OpenVMS resource identifier, CIFS$ADMINISTRATORS. You can apply this identifier either for all the files and directories under all the CIFS share paths or only to a selected files and directories under certain share paths. Once the resource identifier CIFS$ADMINISTRATORS is applied on an object with READ access, while setting permissions from a Windows system, a user belonging to built-in Administrators group (either directly or through nested grouping) can take ownership of the object. After the user becomes an owner of the object, the user is allowed to set required permissions for other users and groups on that object.

The READ access to the OpenVMS resource identifier, CIFS$ADMINISTRATORS can be granted by executing the commands similar to the following on an OpenVMS system:

$ SET DEFAULT [CIFSSHARE]

To apply inheritable default ACE to directories under CIFSSHARE.DIR, execute:

$SET SECURITY/ACL= (IDENTIFIER=CIFS$ADMINISTRATORS,OPTIONS=DEFAULT,ACCESS=READ) [...]*.DIR

To apply access ACE for files and directories under CIFSSHARE.DIR, execute:

$ SET SECURITY/ACL= (IDENTIFIER=CIFS$ADMINISTRATORS,ACCESS=READ) [...]*.*;*

If you would like to grant CIFS$ADMINISTRATORS resource identifier to the parent directory CIFSSHARE.DIR, execute:

Applying default ACE for inheritance:
$ SET SECURITY/ACL=(IDENTIFIER=CIFS$ADMINISTRATORS,OPTIONS=DEFAULT,ACCESS=READ) –
_$ [-]CIFSSHARE.DIR

Applying access ACE:
$ SET SECURITY/ACL= (IDENTIFIER=CIFS$ADMINISTRATORS,ACCESS=READ) [-]CIFSSHARE.DIR

NOTE:

1. CIFS, by default creates CIFS$ADMINISTRATORS OpenVMS resource identifier after CIFS has been successfully configured and connection was established to it at least once.
2. You can grant any other access permission to CIFS$ADMINISTRATORS in addition to READ depending upon the security setup in your CIFS environment.

Full privileges to selected domain users and CIFS local users:

For granting full administrative privileges to a selected list of domain users and CIFS local users, you can use the SMB.CONF parameter, “admin users”. By administrative privilege, it is meant full privileges that can be granted to a user on an OpenVMS system.  You can follow the steps mentioned below for granting administrative privilege to a selected list of users.

On a CIFS member server, to grant an administrative privilege to a user belonging to the Windows domain (where CIFS is a member) or the domains trusted by it, the format of the “admin users” parameter in the Samba configuration file is:

        admin users = <DOMAINNAME\domain-user>

On CIFS a member server, to grant an administrative privilege to a CIFS local user, the format of the “admin users” parameter in the Samba configuration file is:

        admin users = <CIFS local username>

NOTE:

1. You can specify multiple usernames in the same line. When specifying multiple usernames, separate each username by a comma.
2. Domain usernames and CIFS local usernames can be specified in the same line. For example, domain users and CIFS local users can be specified in the same line as:

admin users = <DOMAINNAME\domain-user>, <CIFS local username>

3. Prior to CIFS version 1.2, the “admin users” parameter can be added in the [global] section of the Samba configuration file SAMBA$ROOT:[LIB]SMB.CONF. From CIFS version 1.2 onwards, you can update the “admin users” parameter in the Samba configuration include file, SAMBA$ROOT:[LIB]ADMIN_USERS_SMB.CONF.
4. “admin users” parameter, if specified under the [global] section of Samba configuration file grants full privileges to all the CIFS shares and files and folders under these shares in addition to allowing these admin users the right to do other administrative operations
5. “admin users” parameter, if specified under the share section of the Samba configuration file, grants administrative privileges to the specified admin users only for that share.

Granting privileges to a mapped OpenVMS username

A domain or a CIFS local user whose account is mapped to an OpenVMS username will derive the same privileges as the mapped OpenVMS username. Due to this, a domain or a CIFS local user can become a privileged administrative user, provided you have granted the necessary privileges (like BYPASS, SYSPRV, GRPPRV) for the mapped OpenVMS username. The privileges mentioned here are the default privileges of a mapped OpenVMS username in SYSUAF database. CIFS does not honor authorized privileges of a mapped OpenVMS username.

You can use the following DCL command to grant privileges for a mapped OpenVMS user:

$ MCR AUTHORIZE MODIFY <OpenVMS-username>/DEFPRIVILEGES = (<privileges>)

Privileges can be BYPASS, SYSPRV, and GRPPRV etc. Multiple privileges can be specified by separating them using a comma.

NOTE: Some of the utilities provided by CIFS honor current privileges of the terminal process that is executing the utilities on behalf of the user.

Special permission – ‘Change Permission’ or CONTROL access

A user, who has ‘Change Permission’ or CONTROL access to an object, can modify permissions on that object for other users and groups. The same is possible, if any of the groups that the user belongs to (either directly or through nested grouping), has ‘Change Permission’ or CONTROL access to an object. Again, this is subject to OpenVMS security rules and depends on the ACE location in the ACLs on the object unless the user is an owner of the object or has special privileges.

By granting a ‘Change Permission’ (CONTROL access) on an object for a user or to any of the groups that the user belongs to, you allow the user to set permissions on this object for any other users and groups.

Privileges/Permissions for a user when setting CIFS File Security from an OpenVMS system

A user who tries to set up CIFS File Security on an object in a CIFS share path from an OpenVMS system must have full privileges (BYPASS privilege is a must) to set security.

This section describes the steps that are required for setting up File Security on CIFS shares and directories. For setting File Security on a share using the steps provided below, the share is treated as a directory. This section includes the following topics:

1. Managing CIFS local groups – Describes how to add users and groups to CIFS local groups
2. Setting up File Security from a Windows system – Describes how to set up File Security from a Windows system.
3. Setting up File Security from an OpenVMS system - Describes how to set up File Security from an OpenVMS system.

NOTE: Before you follow rest of the topics, you must ensure that you have successfully added CIFS as member server to a Windows domain as rest of the topics assume that a working CIFS configuration is already in place.

As the above mentioned topics will be based on practical examples in most cases, sample configuration information used in these examples is as follows:

Windows Domain name (where CIFS is a Member Server): CIFSDOM
CIFS Member Server name (OpenVMS system name):                    PIANO
Windows PDC emulator name for the domain CIFSDOM:               ROX3

Managing CIFS local groups

This section describes the steps and commands that can be executed for managing CIFS local groups. Following users and groups can be added as members to a CIFS local group:

1. Users and global groups of the domain where CIFS is a member
2. Users and global groups of the domains trusted by the domain where CIFS is a member
3. CIFS local users and groups

NOTE: In an OpenVMS cluster, if multiple nodes in a cluster share the same samba$root installation directory where CIFS is configured as Member Server, use the CIFS cluster alias name for the “-W” option of NET RPC GROUP command instead of OpenVMS system name.

The steps for managing CIFS local groups are as follows:

Step 1: Login to an OpenVMS system and define Samba commands

1. Login to an OpenVMS system (PIANO) where CIFS is configured, using a fully privileged OpenVMS user account (say, SYSTEM).
2. Define Samba commands by executing:

$ @SAMBA$ROOT:[BIN]SAMBA$DEFINE_COMMANDS.COM

Step 2: Creating a privileged CIFS user
            To execute the commands mentioned in ‘Step 3’ that let you manage CIFS local groups, you must first create a CIFS local user with an administrative privilege if no such user exists. To do this, execute the following commands:

1. Create an OpenVMS username say, CIFSADMIN:

$ SHOW LOGICAL SYSUAF

If it is not defined, execute:
            $ DEFINE SYSUAF SYS$SYSTEM:SYSUAF

      $ MCR AUTHORIZE COPY SAMBA$TMPLT CIFSADMIN/UIC=[600,600]/FLAG=NODISUSER

      NOTE: From CIFS version 1.2 onwards, CIFS by default creates CIFSADMIN account in SYSUAF.

2. Create a CIFS user account with the same name as the OpenVMS username created in previous step:

$ PDBEDIT “-a” CIFSADMIN
new password: any1willdo
retype new password: any1willdo

3. Update “admin users” parameter
1. For versions prior to CIFS V1.2, edit the Samba configuration file, SAMBA$ROOT:[LIB]SMB.CONF and add or update (append) the following parameter in the [global] section:

admin users = cifsadmin

2. From CIFS version 1.2 onwards, edit the Samba configuration include file, SAMBA$ROOT:[LIB]ADMIN_USERS_SMB.CONF and update (append) the following parameter:

admin users = cifsadmin

Step 3: Executing commands to add/modify/delete CIFS local groups

1. Adding or Creating a CIFS local group:

Add a resource identifier say, CIFSUSERS in the RIGHTSLIST database by executing the following command:

$ MCR AUTHORIZE ADD/IDENTIFIER/ATTRIBUTE=RESOURCE CIFSUSERS
 

To add/create a CIFS local group by mapping it to the resource identifier, CIFSUSER, execute:

$ NET GROUPMAP ADD NTGROUP=CIFSUSERS UNIXGROUP=CIFSUSERS TYPE="L"

2. To list the groups in CIFS local database, enter one of the following commands:

$ NET GROUPMAP LIST
OR
$ NET RPC GROUP LIST "-W" PIANO "-S" PIANO "-U" CIFSADMIN%"Pwd of CIFSADMIN"

3. To add an already existing CIFS local user (STEFFI) or a local group (PLAYERS) to a CIFS local group (CIFSUSERS), enter the following commands:

$ NET RPC GROUP ADDMEM CIFSUSERS STEFFI "-W" PIANO "-S" PIANO -
_$ "-U" CIFSADMIN%"Pwd of CIFSADMIN"

$ NET RPC GROUP ADDMEM CIFSUSERS PLAYERS "-W" PIANO "-S" PIANO -
_$ "-U" CIFSADMIN%"Pwd of CIFSADMIN"

4. To a CIFS local group (CIFSUSERS), to add a domain user (ANITA) or a domain global group (ACCOUNTS) that belong to the domain CIFSDOM, enter the following commands:

$ NET RPC GROUP ADDMEM CIFSUSERS CIFSDOM\ANITA "-W" PIANO –
_$ "-S" PIANO "-U" CIFSADMIN%"Pwd of CIFSADMIN"

$ NET RPC GROUP ADDMEM CIFSUSERS CIFSDOM\ACCOUNTS "-W" PIANO –
_$ "-S" PIANO "-U" CIFSADMIN%"Pwd of CIFSADMIN"

5. To list members of a CIFS local group (CIFSUSERS), enter the following command:

$ NET RPC GROUP MEMBERS CIFSUSERS "-W" PIANO "-S" PIANO –
_$ "-U" CIFSADMIN%"Pwd of CIFSADMIN"

6. To delete a group from a CIFS local group (CIFSUSERS), enter the following command:

$ NET RPC GROUP DELMEM CIFSUSERS CIFSDOM\ACCOUNTS "-W" PIANO –
_$ "-S" PIANO "-U" CIFSADMIN%"Pwd of CIFSADMIN"

NOTE: The same command can be used to delete a CIFS local user or a group OR a domain user or a domain global group. To delete a CIFS local user or a group, specify only the name, i.e., without the ‘DOMAINNAME\’

7. To delete a CIFS local group (CIFSUSERS), enter the following command:

$ NET RPC GROUP DELETE CIFSUSERS "-W" PIANO "-S" PIANO –
_$ "-U" CIFSADMIN%"Pwd of CIFSADMIN"

NOTE: You must first delete all the members from CIFS local group (CIFSUSERS) before deleting the group itself.

Additional Note:

In the above examples, to add/remove users and groups that belong to domains trusted by a Windows domain (CIFSDOM) to a CIFS local group, use the member name as ‘TRUSTEDDOMAIN\<USERNAME or GROUPNAME>

Setting up File Security from a Windows system

This section describes the steps that should be followed for setting up File Security on shares/folders from a Windows system. It is assumed that you will be using a user account that has the required permissions or privileges (described in earlier sections) to execute the following steps.

Step 1: Login to CIFS Server

From the Windows system, connect to CIFS server (PIANO) by specifying \\<CIFS server name or IP address> at the prompt, “Start->Run” or map the required CIFS share by right-clicking on the ‘My Computer’ icon on the desktop and then select ‘Map Network drive’ in the menu. This will take you to ‘Map Network drive’ dialog box. In the ‘Map Network Drive’ dialog box, enter shared folder name under ‘Folder’ drop–down and then click ‘Finish’. If prompted for credentials, connect using a user account (say, ANITA) that has the required privileges/permissions to manage the security on the shared folder.

Step 2: Setting security

• Select the shared folder or any folder within the shared folder that you would like to manage and right-click on it and select Properties->security->Advanced.
• If the user account (ANITA) that you used for connecting to CIFS Server in step 1 (under this topic) is a member of built-in Administrators group (either directly or because of nested grouping) and you are managing the share/folder only because of the permissions that have been granted for the OpenVMS resource identifier CIFS$ADMINISTRATORS, then follow rest of the steps under ‘b’, otherwise go to step ‘c’.
• Select ‘Owner’ tab in the ‘Advanced Security Setting’ dialog box.
• When the ‘Owner’ dialog box is displayed, check if you are the owner of this object. If so, proceed to step ‘c’.
• When the ‘Owner’ dialog box is displayed, if the connected user account name is not displayed in ‘Change owner to’ list, click on ‘Other Users or Groups’. This will take you to ‘Select User, Computer, or Group’ dialog box.
• In the ‘Select User, Computer, or Group’ dialog box, if connected user (ANITA) does not belong to the location (domain) displayed, click on ‘Locations’ tab. In the ‘Locations’ list box, select the appropriate location where the connected user account (ANITA) is present and click ‘OK’.
• In ‘Select User, Computer, or Group’ dialog box, enter the connected user name (ANITA) under the ‘Enter the object name to select (examples):’ and click on ‘Check Names’. If Windows finds multiple names for the name that you have entered, it will display ‘Multiple Names Found’ list box. In this box, select the appropriate name (RDN) and click ‘OK’. If ‘Multiple Names Found’ box is not displayed or once you return from the ‘Multiple Names Found’ box, click ‘OK’ in the ‘Select User, Computer, or Group’ dialog box.
• After returning to ‘Owner’ dialog box, select the connected user name (ANITA) under ‘Change owner to’ list box and click ‘Apply’ button. Once the owner name is set to connect user name (ANITA), select ‘Permissions’ tab. As you are now an owner of this object, proceed to step ‘c’ for setting permissions to other users and groups.
• In the ‘Advanced Security Setting’ box, choose permissions tab (by default permissions tab is chosen). Click on “Add” tab if you would like add a new permission entry for a user or group, or to modify/remove an existing permission entry, select the user or group under the ‘Permission  entries’.
• If you want to remove the selected ‘Permission entry’, click on ‘Remove’ tab and then click on ‘Apply’ button. Now, go to step ‘i’.
• If you want to modify the selected ‘Permission entry’, skip this step and go to step ‘f’. If you want add a new ‘Permission entry’, follow rest of the steps under this step.
• If you want to add a new permission entry, click on the ‘Add’ tab. Windows now displays ‘Select User, Computer, or Group’ dialog box.
• In the ‘Select User, Computer, or Group’ dialog box, if a user or group name to whom you want to grant permissions belongs to the displayed location (domain), proceed to next step ‘iii’. If a user or group belongs to any other location (domain), click on ‘Locations’ tab; Select the appropriate ‘Location’ in the ‘Locations’ list box and click ‘OK’.
• In ‘Select User, Computer, or Group’ dialog box, under ‘Enter the object name to select (examples)’, type the user or group name to whom you want to grant permission, Then, click on ‘Check Names’ tab. If Windows finds multiple names for the name that you have entered, it will display ‘Multiple Names Found’ list box. In this box, select the appropriate name (RDN) and click ‘OK’. If ‘Multiple Names Found’ box is not displayed or once you return from ‘Multiple Names Found’ box, click ‘OK’ in the ‘Select User, Computer, or Group’ dialog box. From this step onwards, follow instructions from step ‘f’.
• Windows will now display ‘Object’ dialog box. Select the permissions that you would like to grant for the selected ‘Name’ from the ‘Permissions’ list. If you are setting permissions for a directory or a shared folder object, select the appropriate inheritance value from the ‘Apply onto’ drop-down. Next, click ‘OK’.
• Once you return to ‘Permissions’ dialog box in ‘Advanced Security Setting’, click on ‘Apply’ button.
• Next, you can either repeat steps ‘b’ to ‘g’ or click on ‘OK’ to exit the ‘Advanced Security Setting’ dialog box. Once you return to ‘Security’ dialog box, click ‘OK’ to exit the ‘Security’ dialog box.

Setting up File Security from an OpenVMS system:

This section describes the steps/commands that should be followed for setting File Security from an OpenVMS system for users and groups belonging to the Windows domain, where CIFS is a member (CIFSDOM), the domains trusted by it and the CIFS Server. This method is limited to a user who has a fully privileged user account on the OpenVMS system. The steps to be followed are:

1. Login to an OpenVMS system using a fully privileged OpenVMS account, say “SYSTEM”.
2. Define Samba commands by executing:

$ @SAMBA$ROOT:[BIN]SAMBA$DEFINE_COMMANDS.COM

3. Find out the mapped OpenVMS identifier of a domain/CIFS user or group to whom you are trying to grant permissions by executing the following command and note down the identifier name (VMSIDENTIFIER-NAME) displayed:

$ WBINFO --domainname-to-hostname=<DOMAINNAME\USERNAME OR GROUPNAME>
VMSIDENTIFIER-NAME

NOTE:

• If it is a user or a group belonging to Windows domain (CIFSDOM), where CIFS is a member, replace DOMAINNAME with the Windows domain name (CIFSDOM).
• If it is a user or a group belonging to a domain trusted by Windows domain (CIFSDOM), replace DOMAINNAME with the trusted domain name.
• If it is a user or a group that exists on the CIFS local database, replace DOMAINNAME with CIFS server name (PIANO).

4. Execute the following command to set required permission for the identifier (VMSIDENTIFIER-NAME) noted down in step ‘3’. For example,
1. if you want to grant READ and EXECUTE access permissions to a directory DIRECTORY_NAME.DIR that is under a CIFS share path, you can execute:

$ SET SECURITY/ACL=(IDENTIFIER=VMSIDENTIFIER-NAME,ACCESS=READ+EXECUTE) –
_$ DEVICENAME:[PARENT_DIR_PATH]DIRECTORY_NAME.DIR

2. If you would like to apply the inheritable DEFAULT ACE on this directory, you can set DEFAULT ACE by executing:

$ SET SECURITY/ACL=(IDENTIFIER=VMSIDENTIFIER-NAME,OPTIONS=DEFAULT, -
_$ ACCESS=READ+EXECUTE) DEVICENAME:[PARENT_DIR_PATH]DIRECTORY_NAME.DIR

5. To modify permissions for an existing ACE and to replace the modified ACE at the existing ACE location, you can execute:

$ SET SECURITY/ACL=(IDENTIFIER=VMSIDENTIFIER-NAME,ACCESS=READ+EXECUTE) –
_$ /REPLACE= (IDENTIFIER=VMSIDENTIFIER-NAME,ACCESS=READ+WRITE+EXECUTE) -
_$ DEVICENAME:[PARENT_DIR_PATH]DIRECTORY_NAME.DIR

6. To insert an ACE after another ACE, you can execute:

$ SET SECURITY/ACL=(IDENTIFIER=VMSIDENTIFIER-NAME,ACCESS=READ+WRITE+EXECUTE) –
_$ /AFTER=(IDENTIFIER=EXISTING-VMSID-NAME,ACCESS=READ+WRITE+EXECUTE+DELETE) -
_$ DEVICENAME:[PARENT_DIR_PATH]DIRECTORY_NAME.DIR

NOTE: The ACE specified for /AFTER must exactly match the existing ACE on the directory.

NOTE: This step can be used as a workaround for the “File access limitation”. The ACE with higher permission can be place before the ACE with lower permission.

7. To remove an ACE for a user or a group whose identifier was obtained in ‘3’, execute the following command:

$ SET SECURITY/ACL=(IDENTIFIER=VMSIDENTIFIER-NAME, -
_$ ACCESS=READ+WRITE+EXECUTE)/DELETE –
_$ DEVICENAME:[PARENT_DIR_PATH]DIRECTORY_NAME.DIR

NOTE: Execute $ HELP SHOW SECURITY to obtain more help.

winbindd_idmap.tdb      - Stores records for WINBIND created mapping between domain SIDs and idmap UID/GID values (or OpenVMS UICs and resource identifiers).
group_mapping.tdb       - Stores records for CIFS local groups and the members of these groups
passdb.tdb                    - Stores records for CIFS local users when passdb backend = tdbsam
secrets.tdb                     - Stores private information like workstation passwords, the ldap admin dn and trust account information
account_policy.tdb         - Stores NT account policy settings such as pw expiration
share_info.tdb                - Stores information about share ACLs
ntdrivers.tdb                   - Stores information about installed Printer drivers
ntforms.tdb                    - Stores information about installed Printer forms
ntprinters.tdb                  - Stores information about installed printers

The passdb.tdb and secrets.tdb database files will be present in the directory, SAMBA$ROOT:[PRIVATE]. Rest of the database files will be present in the directory, SAMBA$ROOT:[VAR.LOCKS].

The information present in this article has the following sources:

• SAMBA Official HOW-TO
• HP OpenVMS CIFS Administrator’s Guide
• HP OpenVMS Guide to System Security
• Microsoft Authentication and Access Control Technologies
• Release notes for CIFS Patch set for CIFS V1.1 ECO1