Managing users
Only single sign-on user accounts and cloud.gov IDP accounts are allowed. Service accounts, such as deployer credentials, are to be generated only via the service account managed service to ensure that they are scoped to a particular space with limited access.
No local accounts to UAA shall be created for user access.
Creating users
Add new users by inviting them.
Changing passwords
Users should reset their own password.
If a user logs in using their agency’s account system, the only way to reset that password is for them to use their agency’s normal password reset process.
Resetting TOTP tokens
Follow the process below for users logging in with a cloud.gov account.
If the user requesting a reset has any apps, routes, or services in their sandbox or access to any other spaces or orgs, tell them that these will be removed and ask them if we should proceed. If they agree:
-
Remove all apps, routes, and services from the user’s sandbox. E.g.:
cf target -o sandbox-agency -s some.user cf apps cf delete app cf services cf delete-service service
-
Remove user’s permissions to all spaces and orgs other than their sandbox. Use the
cg-scripts/cf-get-user-roles.sh
and thencg-scripts/strip-user-org-and-space-roles.sh
to find user roles and strip them away.For those spaces and orgs, notify the Space Managers and Org Managers that we’ve removed the user’s access because of their request to reset their account’s authentication application.
-
Reset the user’s totp_seed in cloudfoundry’s uaa database.
Login to a concourse jumpbox and run the
reset-totp.sh
script:cg-scripts/reset-totp.sh cf-production ${username}
-
Let the user know the reset process is complete. Do not include specific account information such as the user’s roles or roles/contact info for other people in their organization
I’ve reset your one-time password. To regain cloud.gov access, log in to cloud.gov again. After entering your username/password combination, you should be prompted to set up a new one-time password with your authenticator app (for example, 1password, Microsoft Authenticator, or Authy). Since this reset removed your roles on orgs and spaces, you may need to request additional access from your Space Managers and Org Managers again. If you had a sandbox space, that has been reset and is available to you again.
Managing Admins
Make sure you have a copy of the cg-scripts repository so you have access to several utility scripts.
Creating Admins
Make the user a Production CloudFoundry admin using their GSA email address.
# on a production jumpbox, run:
cd ./cg-scripts
./uaa/login.sh
./make-cf-admin.sh <EMAIL_ADDRESS>
# For global auditor, instead use
# ./add-global-cf-auditor-permissions.sh <EMAIL_ADDRESS>
# Check permission with:
./validate-admins.sh
Secondly, make the user a Concourse admin in Tooling using their GSA email address.
# on a tooling jumpbox, run:
./uaa/login.sh
./make-ops-admin.sh <EMAIL_ADDRESS>
# Verify changes with:
./validate-admins.sh
Removing Admins
First, remove the user as a Production CloudFoundry admin using their GSA email address.
# on a production jumpbox, run:
cd ./cg-scripts
./uaa/login.sh
./make-cf-admin.sh -r <EMAIL_ADDRESS>
# verify changes with:
./validate-admins.sh
Secondly, remove the user as a Concourse admin from Tooling using their GSA email address.
# on a tooling jumpbox, run:
cd ./cg-scripts
./uaa/login.sh
./make-ops-admin.sh -r <EMAIL_ADDRESS>
# verify changes with:
./validate-admins.sh
Deleting Admins
Before deleting an admin user using cf delete-user
, be sure to follow the Removing Admins above. If you don’t, you will end up with orphaned group membership. The username will be replaced with the user’s GUID and will appear in roles in cf (cf org-users
or cf space-users
).
In the event you see an orphaned account (denoted by GUID), you need to clean up UAA groups and CF. You can remove the user from cf via:
cf curl /v3/users/${user_guid} -X DELETE
You can clean up UAA groups via cg-scripts/remove-user-guid-from-all-groups.sh or manually using uaac member delete
.
Deleting Users
If a user requests deletion of their cloud.gov account, check to make sure that the user is not an org manager, org auditor, or billing manager - if they are, these roles may need to be transferred to someone else prior to deleting their account. If they are a user in a sandbox account, you may also need to manually remove any services or apps from their sandbox account, and remove their space in the sandbox org.
- Remove the user from their org/space in Stratos.
- Delete the user account with:
cf delete-user {user-name}
(Note - this might not be needed, as Stratos may take care of it.)
If the user is a user in a sandbox account:
- Delete any services and apps in the user’s sandbox space.
- Delete the user’s sandbox space with:
cf delete-space {user-name} -o {sandbox-org-name}