Cluster Access CRM

Home is your dashboard.

Use it to review:

• My Users: the users currently visible to your CRM scope
• My Requests: the request history that belongs to your scope

Suggested workflow:

1. Use the search box, filters, and pagination controls to narrow large lists.
2. Click a user or request card.
3. Review the detail panel on the right.
4. Then decide whether you need Add User, Manage Access, Transfer User, or Remove User.

Use Add User when a person must be created in the cluster workflow.

Steps:

1. Enter one person in Target CNetID, or turn on Add multiple users at once and paste one CNetID per line in Target CNetIDs.
2. Choose the PI context if the form asks for it.
3. Choose one optional Project Group.
4. Add Justification and Notes if useful.
5. Click Add User.

What the CRM does next: it looks up the institutional identity, creates or confirms the FreeIPA account, applies cluster-access group membership, optionally adds the selected project group, and records the request.

Use Manage Access to add an existing visible user to a project group or remove them from one.

Steps:

1. Select the user in Managed User.
2. Confirm the PI context if needed.
3. Choose one specific Project Group.
4. Add Justification and Notes if helpful.
5. Click Add To Group or Remove From Group.

This screen changes one user and one group per request. If a user needs several groups, repeat the workflow once per group.

PIs only see groups they are allowed to manage through CRM Groups. If a group is missing, contact techstaff@cs.uchicago.edu.

Full admins use Link Existing User to PI when a person already has a DSI cluster account but needs to become visible inside another PI workspace.

Steps:

1. Enter the user in Existing User CNetID.
2. Choose the destination PI in Link to PI.
3. Optionally choose one Project Group.
4. Click Link Existing User.

This does not recreate the DSI account or allocate a new Unix identity. It links the existing account to another PI scope and can optionally add one project group at the same time.

Use Transfer User when an existing CRM-managed user should move from one PI workspace to another.

Steps:

1. Select the user in Managed User.
2. Confirm the current PI if needed.
3. Enter the destination in New PI CNetID.
4. Add Justification and optional Notes.
5. Click Transfer User.

This changes CRM ownership and visibility. It does not recreate the cluster account, and it usually does not rerun full provisioning.

Use Remove User when a user should be offboarded from the cluster workflow.

Steps:

1. Enter one user in the single-user field, or turn on Remove multiple users at once and paste one CNetID per line.
2. Confirm the PI context if the form asks for it.
3. Add Justification and Notes.
4. Submit the request.

This action is for offboarding, not for simple group changes. It removes active CRM ownership for the selected PI, records a removal request, removes cluster-access gate membership, and triggers downstream removal steps such as Slurm removal.

Every action in the CRM is recorded with the acting user, sponsoring PI, target user, timestamps, justification, and notes. Visibility in the UI is scope-based: a PI sees only the users and requests that belong to that PI scope, while full admins can review broader CRM state. This is why ownership and PI assignment matter so much for what appears in My Users, My Requests, and Manage Access.

A PI Delegate can sign in and perform CRM actions on behalf of exactly one sponsoring PI. The delegate inherits that PI's users, requests, and PI-owned project groups. The audit trail keeps both identities: actor is the delegate who clicked the button, and sponsoring PI is the PI whose scope was used.

To request a delegate:

1. Open Delegate PI Requests.
2. Select Request a delegate.
3. Enter the delegate's institutional CNetID.
4. Choose an Access Until date.
5. Add notes and submit the request.
6. Wait for a full administrator to approve it.

The CRM validates the CNetID against the institutional directory. Approval is required before the delegate can sign in. A PI can have one active delegate and one pending request at a time.

To extend access: choose Request an extension, select a new date, and submit it for administrator approval. The old expiration remains active until the extension is approved.

To remove access: choose Request delegate removal and submit the request. After administrator approval, the delegate loses the delegate role and the CRM restores the previous actor state.

Access expiration is enforced on the next CRM request after the expiration date. The CRM does not currently send automatic expiration email. CRM approval also does not grant Grouper access; contact Techstaff separately for Grouper membership.

Full admins review and decide requests in the Pending Delegate Requests panel. Completed decisions remain in Delegate Request History with the expiration date, notes, decision maker, and reason.

Full admins use Admin Access to control who may sign in to the CRM and what role they receive. Set a person as PI, PI Delegate, or Full Admin. If the role is PI Delegate, you must also set the sponsoring PI CNetID. Setting an actor to Inactive blocks CRM login without deleting historical records, which is safer than removing history entirely.

Full admins use CRM Groups to create, update, or retire CRM-managed groups.

Steps:

1. Set Group Name.
2. Set Directory Name.
3. Set Display Name.
4. Choose the Status.
5. Enter one or more PI owners in PI CNetIDs.
6. Click Save Group.

Group ownership controls which PI can manage users inside that group from the CRM. If a PI cannot see a group in Manage Access, the first thing to check is whether that PI is correctly assigned as an owner in CRM Groups.

If you need extra help, contact techstaff@cs.uchicago.edu and include the user, group, PI, and action you were trying to perform, plus the exact CRM error message if one was shown.