Granting access to groups of users

Helix Server groups simplify maintenance of the protections table. The names of users with identical access requirements can be stored in a single group. The group name can then be entered in the table, and all the users in that group receive the specified permissions.

Groups are maintained with p4 group, and their protections are assigned with p4 protect. Only Helix Server superusers can use these commands. (Helix Server administrators can use p4 group -A to administer a group, but only if the group does not already exist.)

For information about groups and LDAP, see Synchronizing Helix Server users and groups with LDAP groups.

Creating and editing groups

If p4 group groupname is called with a nonexistent groupname, a new group named groupname is created. Calling p4 group with an existing groupname allows editing of the user list for this group.

To add users to a group, add user names in the Users: field of the form generated by the p4 group groupname command. User names are entered under the Users: field header. Each user name must be typed on its own line, indented. A single user can be listed in any number of groups. Group owners are not necessarily members of a group. If a group owner is to be a member of the group, the userid must also be added to the Users: field.

Groups can contain other groups as well as individual users. To add all users in a previously defined group to the group you’re working with, include the group name in the Subgroups: field of the p4 group form. User and group names occupy separate namespaces, so groups and users can have the same names.

Adding nonexistent users to group definitions does not actually create the users, nor does it consume licenses. To create users, use the p4 user command.

Groups and protections

To use a group with the p4 protect form, specify a group name instead of a user name in any line in the protections table and set the value of the second field on the line to group instead of user. All the users in that group are granted the specified access.

Example Granting access to Helix groups

This protections table grants list access to all members of the group devgrp, and super access to user edk:

list        group        devgrp      *        //...
super       user         edk         *        //...

According to the following three permission lines, group ac1 will have write access to //ac1/... while giving the group read-only access to //ac1/ac1_dev/....

write        group        ac1      *        //ac1/...
list         group        ac1      *        -//ac1/ac1_dev/...
read         group        ac1      *        //ac1/ac1_dev/...

If a user belongs to multiple groups, one permission can override another. For instance, if you use exclusionary mappings to deny access to an area of the depot to members of group1, but grant access to the same area of the depot to members of group2, a user who is a member of both group1 and group2 is either granted or denied access based on whichever line appears last in the protections table. The actual permissions granted to a specific user can be determined by replacing the names of all groups to which a particular user belongs with the user’s name within the protections table and applying the rules described earlier in this chapter.

Synchronizing Helix Server users and groups with LDAP groups

You can configure Helix Server to automatically synchronize the contents of a given Helix Server user or user group with that of an LDAP user or group. Protections are still assigned based on the identity of the Helix Server user or group (using the p4 protect command), but which users are included in the Helix Server group is determined by the membership of the LDAP group.

Synchronization can happen once or at specified intervals. See the Description of the p4 ldapsync command in the Helix Core Command-Line (P4) Reference.

Before you configure group synchronization, you need to define an LDAP configuration.

Note

If the LDAP server requires login for read-only queries, the LDAP configuration must contain valid bind credentials in the LDAP spec’s SearchBindDN and SearchPasswd fields.

To configure group synchronization, you must do the following:

Define the following fields in the Helix Servergroup spec:
- LdapConfig: The name of an LDAP configuration created using the p4 ldap command.
  
  The LDAP configuration:
  - provides the hostname, port, and encryption for the LDAP connection
  - specifies how authentication is to be done using the SearchBindDN, SearchPasswd, and GroupSearchBaseDN fields.
- LdapSearchQuery: The search query to identify the group member records.
- LdapUserAttribute: The attribute that contains the group member’s user id. This user name is added to the Helix Server group.
Define a group owner for the Helix Server group. The owner does not have to be a member of the corresponding LDAP group.
Use the p4 ldapsync command, specifying which Helix Server group(s) should be synchronized, to test the anticipated results using a command like the following.
```
$ p4 ldapsync -g -n my-perforce-group1 my-perforce-group2
```
p4 ldapsync uses the context provided by the LDAP configuration to execute the search query and collect all the defined attributes from the results that are returned. The resultant list becomes the members list of the group.
If you are satisfied with the preview results, run p4 ldapsync again (without -n) to synchronize the groups.

To schedule synchronization to occur at regular intervals, make the p4 ldapsync command run at startup time and specify the value of the interval. See the Examples in the p4 ldapsync command in Helix Core Command-Line (P4) Reference.

The following examples, included in Synchronizing with Active Directory and Synchronizing with OpenLDAP, demonstrate two ways in which you can define group synchronization. These examples illustrate how configurations depend on how references to users and groups are stored on different servers:

OpenLDAP stores a list of memberUid’s in its group records. These can often be used directly as Helix Server user names.
Active Directory stores a list of member’s full DN’s in its group records, and the full DN of each group a user belongs to in its user records. In this case, look for the user records that contain the back reference to the group instead of finding the group record directly.

Note the difference in the GroupBaseDn in the LDAP spec. In Active Directory, we’re looking for users who are in the group. In OpenLDAP, we’re looking for groups that contain users. This affects the path we’re searching under.

In the following examples, both servers have user under the DN ou=users,dc=example,dc=com. We will be creating a Helix Server group called development that is populated from the LDAP group cn=development,ou=groups,dc=example,dc=com.

Synchronizing with Active Directory

We begin with a sample LDAP configuration named my-ad-example defined as follows:

Name:              my-ad-example
Host:              ad.example.com
Port:              389
Encryption:        tls
BindMethod:        search
SearchBaseDN:      ou=users,dc=example,dc=com
SearchFilter:      (&(objectClass=user)(sAMAccountName=%user%))
SearchBindDN:      CN=agupta, OU=users, DC=foodomain, DC=com
SearchPasswd:      password
SearchScope:       subtree
GroupBaseDN:       ou=users,dc=example,dc=com
GroupSearchScope:  subtree

The group spec created by the command p4 group development, would then look like this:

Group:             development
LdapConfig:        my-ad-example
LdapSearchQuery:   (&(objectClass=user)(memberOf=cn=development,ou=groups,
                                                       dc=example,dc=com))
LdapUserAttribute: sAMAccountName
Owners:            super

Synchronizing with OpenLDAP

We begin with a sample LDAP configuration named my-openldap-example defined as follows:

Name:              my-openldap-example
Host:              openldap.example.com
Port:              389
Encryption:        tls
BindMethod:        search
SearchBaseDN:      ou=users,dc=example,dc=com
SearchFilter:      (&(objectClass=inetOrgPerson)(uid=%user%))
SearchBindDN:      CN=agupta, OU=users, DC=foodomain, DC=com
SearchPasswd:      password
SearchScope:       subtree
GroupBaseDN:       ou=groups,dc=example,dc=com
GroupSearchScope:  subtree

The group spec created by the command p4 group development, would then look like this:

Group:             development
LdapConfig:        my-openldap-example
LdapSearchQuery:   (&(objectClass=posixGroup)(cn=development))
LdapUserAttribute: memberUid
Owners:            super

Deleting groups

To delete a group, invoke

$ p4 group -d groupname

Alternately, invoke p4 group groupname and delete all users, subgroups, and owners from the group in the resulting editor form. The group will be deleted when the form is closed.