Managing identities in an ACL-enabled deployment on heterogeneous platforms

In this topic, the OS type of the client means the OS type of the full ClearCase® local client that is using snapshot or dynamic views, or the OS type of the CCRC WAN server that is hosting web views.

Modifying policies and rolemaps from a client of the same OS type as the VOB server.

Policies and rolemaps can include user and group identities. When your deployment includes both Linux or the UNIX system and Windows systems, the account and group names used in ACLs need to be available for both operating system types. Whenever you access a Linux or the UNIX system VOB from a Windows view or Windows client, or access a Windows VOB from a Linux or the UNIX system snapshot view or Linux or the UNIX system client, the identities in the relevant ACLs are translated (credmapped) between the Linux or the UNIX system and Windows systems.

When administering ACLs, if you display and modify rolemaps and policies from a client of the same type as the VOB server, no mapping is performed (native IDs are used). You see the identities from the ACLs displayed using the native account names for those identities. If an account name is not known for a particular ID (for example, the account or group has been deleted), the ID is displayed in the ACL in a numeric form. The numeric form can be used to modify or remove the ID's access.

If you display and modify rolemaps/policies from a client of the opposite OS type as the VOB server, the identities in the ACL are mapped to your client's style account names. If there are any failures mapping the accounts listed in the ACLs, ClearCase applications display the unmapped entries in numeric form. If you attempt to modify a policy or rolemap when some existing entry(ies) cannot be mapped, the modification fails with an error message showing the unmappable identity(ies).

If you are modifying a rolemap, and there are no mapping failures among the identities in the rolemap, but there are mapping failures in the rolemap's policy, you may see an error after saving the rolemap. The generated effective ACL will have mapping failures. Those failures block the reprotection of containers for affected elements.

The same situation can occur if you modify a policy and there are mapping failures among the identities of one or more rolemaps that implement the policy. Again, the generated effective ACL for one or more of those rolemaps will have mapping failures that block the reprotection of affected containers.

If you encounter container protection errors while modifying a rolemap or policy, you should log into the VOB server and execute the subcommands

chpolicy -validate_pools modified-policy

chrolemap -validate_pools modified-rolemap

to re-execute the container protection operations.

Some access control decisions depend on successful credmapping of the process identity to the VOB server host's identity domain. Those operations are checked on the VOB server, and as long as the process identity can be mapped into the server's domain, the access checks will proceed normally. If a process's credentials cannot be mapped into the server's domain, the operation fails.

Some access control decisions depend on the entries in an effective ACL being mapped to the client's domain. For these decisions, if an entry in the EACL is not mappable, it will be skipped during the access checks. Only the mappable entries in the EACL will be checked when determining if an operation may proceed. This may result in a process having fewer permissions than you expect.

Managing unknown account IDs

Named users and groups are stored in the VOB database in numeric ID form. If you have identities that appear in policies or rolemaps that are no longer known to the operating system (for example, you removed an account from the OS user database), they are displayed in numeric form when you describe the policy or rolemap. You can remove them by editing the policy or rolemap on the VOB server host.

If the identities are not known even on the VOB server host, you can still edit the policy or rolemap with chpolicy or chrolemap to remove the IDs. Specify the user or group principal in the form printed by lsrolemap or lspolicy. For example, on Windows with an unknown group or user SID:

M:\view\vob>cleartool lspolicy -l P1
policy "P1"
 2012-03-30T11:41:50-04:00 by Some Q. User (some.user@QVMW108)
  owner: DOMAIN\some
  group: DOMAIN\user
  contents:
    vob ACL:
      User:DOMAIN\some Full
      Role:Role1 Read
    element ACL:
      User:DOMAIN\some Full
    policy ACL:
      User:DOMAIN\some Full
      User:NT:S-1-5-21-1012866697-2925656722-972655990-1000 Read
    rolemap ACL:
      User:DOMAIN\some Full
      Group:NT:S-1-5-21-1012866697-2925656722-972655990-1004 Read

M:\view\vob>cleartool chpolicy -kind policy -remove User:NT:S-1-5-21-1012866697-2925656722-972655990-1000 -nc P1
... [output elided] ...
M:\view\vob>cleartool chpolicy -kind rolemap -remove Group:NT:S-1-5-21-1012866697-2925656722-972655990-1004 -nc P1
... [output elided] ...
M:\view\vob>cleartool lspolicy -l P1
policy "P1"
 2012-03-30T11:41:50-04:00 by Some Q. User (some.user@QVMW108)
  owner: DOMAIN\some
  group: DOMAIN\user
  contents:
    vob ACL:
      User:DOMAIN\some Full
      Role:Role1 Read
    element ACL:
      User:DOMAIN\some Full
    policy ACL:
      User:DOMAIN\some Full
    rolemap ACL:
      User:DOMAIN\some Full

Here is an example on UNIX with an unknown group or user ID:

% cleartool lspolicy -l P1
policy "P1"
 2012-03-30T14:46:30-04:00 by Some Q. User (some.user@qvml055)
  owner: some
  group: user
  contents:
    vob ACL:
      User:your.nis.domain/some Full
      Role:Role1 Read
    element ACL:
      User:your.nis.domain/some Full
    policy ACL:
      User:your.nis.domain/some Full
      User:UNIX:UID-9 Read
    rolemap ACL:
      User:your.nis.domain/some Full
      Group:UNIX:GID-13 Read

% cleartool chpolicy -nc -kind rolemap -remove Group:UNIX:GID-13 P1
... [output elided] ...
% cleartool chpolicy -nc -kind rolemap -remove User:UNIX:UID-9 P1
... [output elided] ...
% cleartool lspolicy -l P1
policy "P1"
 2012-03-30T14:46:30-04:00 by Some Q. User (some.user@qvml055)
  owner: some
  group: user
  contents:
    vob ACL:
      User:your.nis.domain/some Full
      Role:Role1 Read
    element ACL:
      User:your.nis.domain/some Full
    policy ACL:
      User:your.nis.domain/some Full
    rolemap ACL:
      User:your.nis.domain/some Full