ctsec_map.global File

Purpose

Associates operating system user identifiers on the local system with network security identifiers for authorization purposes.

Description

RSCT trusted services use the identity mapping definition files ctsec_map.global and ctsec_map.local to determine whether an RSCT client application's user should be granted access to specific RSCT functions and resources. The file is used to associate security network identifiers that are used by RSCT's cluster security services with user identifiers on the local system. RSCT trusted services use these files to determine what association, if any, exists for the RSCT client, and then use this association while examining the RSCT access controls to determine whether the RSCT client should be granted access.

Two identity mapping definition files can be used:

The ctsec_map.global file contains associations that are to be recognized on all nodes within the cluster configuration
The ctsec_map.local file contains associations that are specific to a particular node

In a cluster configuration, all ctsec_map.global files should be the same. Any local system additions that are required for that specific system should be made in the ctsec_map.local file.

RSCT provides a default ctsec_map.global file in the /usr/sbin/rsct/cfg directory. Do not change this file. If you need to add more associations for the cluster, copy this file to the /var/ct/cfg directory. Make any changes to this new file: /var/ct/cfg/ctsec_map.global. Any entries that exist in the default ctsec_map.global file must exist in the replacement version of the file in the /var/ct/cfg directory, or the RSCT trusted services may refuse access to other RSCT trusted services peers. RSCT does not provide a default ctsec_map.local file. The administrator can create this file, which must reside in the /var/ct/cfg directory as well.

ctsec_map.global and ctsec_map.local are ASCII-formatted files that can be viewed and modified using a text editor. Each line in the file constitutes an entry. Blank lines and lines that start with a pound sign (#) are ignored. Each entry is used to either associate a security network identifier with a local operating system user identifier, or to expressly state that no association is allowed for a security network identifier.

Ordering of entries within these files is important. Cluster security services parses the ctsec_map.globaland ctsec_map.local files as follows:

If the /var/ct/cfg/ctsec_map.local file exists, cluster security services checks for associations in this file
If the /var/ct/cfg/ctsec_map.global file exists, cluster security services checks for associations in this file
Otherwise, cluster security services checks for associations within the /usr/sbin/rsct/cfg/ctsec_map.global, if this file exists

The first entry that successfully grants or denies an association for a security network identifier in this search path is the one that cluster security services uses. If entries in both the ctsec_map.globaland ctsec_map.local files grant differing associations to the same security network identifier, cluster security services will use the association stated by the entry in the ctsec_map.local file. Also, if two entries within the ctsec_map.global file grant different associations to the same security network identifier, cluster security services will use the association granted by the entry listed earlier in the ctsec_map.global file. You can use the ctsidmck command to verify the association rule that is used by cluster security services for specific security network identifiers.

Cluster security services recognizes these characters as reserved: <, >, :, =, !, @, *, and considers these, along with white space characters, as token separators. The wildcard character * is permitted, but should not be used multiple times between other token separator characters. Contents of the identity mapping definition files use the following Backus-Nour format:

<mapping_entry> ::= <mechanism_mnemonic> ':' <mapping>>

<mechanism_mnemonic> ::= 'unix', 'krb5'

<mapping> ::= <explicit mapping> | <mapping_rule>

<explicit_mapping> ::= <source_mapping> '=' <local_user_identity>
                       | '!' <source_mapping>

<source_mapping> ::= <network_identity> | <match_pattern>'*'

<target_mapping> ::= <mapped_identity> | '*'

<network_identity> ::= <user_name>'@'<registry_name>

<user_name> ::= <match_pattern>'*' | '*'

<registry_name> ::= <match_pattern> | '*' | <mpm_defined_reserved_word>

<mpm_defined_reserved_word> ::= '<'<alphanumeric_string>'>'

<mapped_identity> ::= <alphanumeric_string>

<match_pattern> ::= null string | <alphanumeric_string>

<alphanumeric_string> ::= any non-empty array of alphanumeric characters not
                          consisting of the reserved token separator characters

An <mpm_defined_reserved_word> is a special instruction to the underlying security mechanism associated with the security network identifier that instructs the mechanism to interpret the identifier in a specific manner. The following reserved words are defined:

<iw>: A reserved word for security network identities using the RSCT host-based authentication (HBA) security mechanism. This keyword maps the HBA root network identity of the local node to the root user. When the cluster security services identity mapping program processes the ctsec_map.global file, it replaces the <iw> keyword with the node ID of the node.
<cluster>: A reserved word for security network identities using the HBA security mechanism. The mapping entry is applied to a security network identifier if the identifier is known to originate from any host within the cluster that is currently active for the local node.
<any_cluster>: A reserved word for security network identities using the HBA security mechanism. The mapping entry is applied to a security network identifier if the identifier is known to originate from any host within any cluster that the local node is currently defined. The local node does not need to be active within that cluster when the mapping is applied.
<realm>: A reserved word for security network identities using the Kerberos version 5 mechanism. The mapping entry is applied to a security network identity if the identifier is known to originate within the Kerberos realm that is currently active. See Restrictions.

Security

The default identity mapping definition file /usr/sbin/rsct/cfg/ctsec_map.global is readable by all system users, but permissions prevent this file from being modified by any system user.
When creating the override identity mapping definition files /var/ct/cfg/ctsec_map.global and /var/ct/cfg/ctsec_map.local, make sure that the files can be read by any system user, but that they can only be modified by the root user or other restrictive user identity not granted to normal system users.
By default, these files reside in locally-mounted file systems. While it is possible to mount the /var/ct/cfg directory on a networked file system, this practice is discouraged. If the /var/ct/cfg/ctsec_map.local file were to reside in a networked file system, any node with access to that networked directory would assume that these definitions were specific to that node alone when in reality they would be shared.

Restrictions

RSCT does not support the Kerberos version 5 mechanism. Any entries using the mechanism mnemonic krb5 or the reserved word <realm> will not be applied.

Implementation Specifics

These files are part of the Reliable Scalable Cluster Technology (RSCT) cluster security services. The default file is shipped as part of the rsct.core.sec fileset for AIX®.

Location

/usr/sbin/rsct/cfg/ctsec_map.global: Contains the default identity mapping definition file.
/var/ct/cfg/ctsec_map.global: Contains the replacement for the default global identity mapping definition file. Any entries that exist in the default ctsec_map.global file must be replicated in this file, or necessary access required by RSCT trusted services clients will be refused. This file contains identity mapping definitions expected to be recognized by all nodes within the cluster. It is expected that this file will have the same contents for each node within the cluster.
/var/ct/cfg/ctsec_map.local: Contains additional identity mapping definitions specific to the local node. This file adds identity mapping definitions to the set recognized for the entire cluster. Entries within this file are applied before entries from the ctsec_map.global file. It is expected that the contents of this file will vary from node to node within the cluster, and provide mappings required for clients that access the local node only.

Example

These reserved characters: <, >, :, =, !, and @, are interpreted as token separators, as are white space characters.

Examples of valid identity mapping definition entries:

unix:zathras@epsilon3.ibm.com=zathras: This entry grants the association for the RSCT HBA or HBA2 security mechanism identity zathras@epsilon3.ibm.com to the local user identifier zathras. This entry is not applied to other RSCT HBA or HBA2 identities.
unix:!zathras@greatmachine.net: This entry denies any local user identity association for the RSCT HBA or HBA2 identity zathras@greatmachine.net. This entry is not applied to other RSCT HBA or HBA2 identities.
unix:entilzah@cluster=root: The cluster reserved word matches any RSCT HBA or HBA2 identity containing the user name entilzah that originates from any host within the currently-active cluster. This grants associations for such RSCT HBA or HBA2 identities as entilzah@anglashok.ibm.com and entilzah@mimbar.ibm.com to the local user root when the local node is active within the cluster that also contains the hosts anglashok.ibm.com and mimbar.ibm.com. Associations will not be granted for such RSCT HBA or HBA2 identities as entilzah@whitestar.ibm.com if the host whitestar.ibm.com is not part of the cluster that is currently active.
unix:entilzah@any_cluster=root: The cluster reserved word matches any RSCT HBA or HBA2 identity containing the user name entilzah that originates from any host within the currently-active cluster. This grants associations for RSCT HBA or HBA2 identities such as entilzah@anglashok.ibm.com and entilzah@mimbar.ibm.com to the local user root when the local node is active within the cluster that also contains the hosts anglashok.ibm.com and mimbar.ibm.com. Associations will also be granted for RSCT HBA or HBA2 identities such as entilzah@whitestar.ibm.com to the local user root if the host whitestar.ibm.com is part of any cluster known to the local host.
unix:zathras@*=zathras: The * character in this entry matches any RSCT HBA or HBA2 identity that contains the user name zathras from any host to the local user identifier zathras. This grants associations for RSCT HBA or HBA2 identities such as zathras@epsilon3.ibm.com and zathras@greatmachine.net to the local user identifier zathras.
unix:zathras@*.ibm.com=zathras: The * character in this entry will match any RSCT HBA or HBA2 identity that contains the user name zathras and a host name ending with an ibm.com® network domain to the local user identifier zathras. This grants associations for RSCT HBA or HBA2 identities such as zathras@epsilon3.ibm.com and zathras@newibm.com to the local user identifier zathras.
unix:*@epsilon3.ibm.com=zathras: The * character in this entry matches any RSCT HBA or HBA2 identity from the host epsilon3.ibm.com and associate that client to the local user zathras. This will grant associations for RSCT HBA or HBA2 identities such as zathras@epsilon3.ibm.com and draal@epsilon3.ibm.com to the local user identifier zathras.
unix:*@epsilon3.ibm.com=*: The * characters in this entry matches any RSCT HBA or HBA2 identity from the host epsilon3.ibm.com and associate that client to the local user whose name matches the user name from the security network identifier. This will grant associations for RSCT HBA or HBA2 identities such as zathras@epsilon3.ibm.com to the local user zathras and draal@epsilon3.ibm.com to the local user identifier draal.
unix:!*@epsilon3.ibm.com: The * characters in this entry matches any RSCT HBA or HBA2 identity from the host epsilon3.ibm.com and deny any association for that client to any local user. This will deny associations for RSCT HBA or HBA2 identities such as zathras@epsilon3.ibm.com and draal@epsilon3.ibm.com, but will not deny associations for the UNIX HBA network identifier zathras@greatmachine.net.
unix:*@*=*: The * characters in this entry matches any RSCT HBA or HBA2 identity from any host and associate that client to the local user whose name matches the user name from the security network identifier. This grants associations for RSCT HBA or HBA2 identities such as zathras@epsilon3.ibm.com to the local user zathras and entilzah@anglashok.ibm.com to the local user identifier entilzah.

Examples of identity mapping definition entries that are not valid:

*:zathras@epsilon3.ibm.com=zathras: The security mechanism cannot be determined. Each entry must explicitly name a security mechanism that needs to be applied to interpret the entry.
unix:zathras@epsilon3.ibm.com=z*: The local user identity to use is ambiguous.
unix:zathras@*.ibm.*=zathras: This entry repeats wildcard characters between the token separators @ and =, which makes the entry ambiguous.
unix:*athra*@epsilon3.ibm.com=zathras: This entry repeats wildcard characters between the token separators : and @, which makes the entry ambiguous.
unix:*=*: The wildcard character * is ambiguous. It cannot be determined if the wildcard character applies to the identity name or the identity location.