User Accounts#

Overview#

User accounts identify individual users who operate Dynamic Power Software (DPS) through dpsctl, the UI, or the gRPC and REST APIs. Use this guide to connect to an already configured DPS server. Administrators configuring server authentication should follow Configure Server Authentication. For applications, services, and scripts, use Service Accounts.

Sign In to DPS#

Your administrator provides the API endpoint, trusted certificates, and configured authentication mode. With Lightweight Directory Access Protocol (LDAP), use your directory username and password. With OpenID Connect (OIDC), sign in through your identity provider.

Use the hostname, port, and certificate paths for your environment in the following examples. Omit --ca-cert-path when the server certificate uses a certificate authority (CA) your system trusts. dpsctl stores tokens in ${HOME}/.dpsctl/credentials.yaml by default. For full options, refer to dpsctl login.

Follow the instructions for LDAP or OIDC, according to your authentication mode.

LDAP#

In LDAP mode, your directory administrator provisions your account and its required group membership. The following examples use the reference OpenLDAP chart. In the UI, enter your directory credentials on the sign-in page.

Groups and Roles#

The reference OpenLDAP chart creates users in ou=users and the following groups:

  • rogroup, at cn=rogroup,dc=cm,dc=cluster, is a directory group. It does not grant DPS API access by itself.

  • dcpower-users, in ou=groups, identifies DPS users.

  • dcpower-admins, in ou=groups, identifies administrator accounts.

  • automation-users, in ou=groups, identifies service accounts.

The server’s dps.ldap.defaultRole and dps.ldap.groupRoleMapping settings determine the LDAP role mapping. The server separately checks dps.auth.auth_required_groups for API access when the setting is nonempty. Successful sign-in does not guarantee that a later API request is authorized. Ask your administrator to check the required membership through Configure LDAP Mode.

Default Users#

The reference OpenLDAP chart creates the following example users for development and testing:

  • testuser / testuser is a member of rogroup and dcpower-users.

  • adminuser / adminuser is a member of dcpower-users and dcpower-admins.

  • non-dcpower-user / non-dcpower-user is a member of rogroup only, for testing access restrictions.

These example credentials are for development and testing. Provision your own accounts and configure access for a secure deployment.

Create a User Account#

If you administer the directory, use the following LDAP Data Interchange Format (LDIF) example to add alice. Replace the user and group IDs and the password hash with values for your directory. Select group membership for the configured access requirements.

Example LDAP User and Group Membership
# New user
dn: uid=alice,ou=users,dc=cm,dc=cluster
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
cn: Alice
sn: Example
uid: alice
uidNumber: 15001
gidNumber: 15000
homeDirectory: /home/alice
loginShell: /bin/bash
mail: alice@example.com
userPassword: ${SSHA_PASSWORD_HASH}

# Add to the reference directory group
dn: cn=rogroup,dc=cm,dc=cluster
changetype: modify
add: member
member: uid=alice,ou=users,dc=cm,dc=cluster

# Add to the DPS users group
dn: cn=dcpower-users,ou=groups,dc=cm,dc=cluster
changetype: modify
add: member
member: uid=alice,ou=users,dc=cm,dc=cluster

After applying the LDIF, verify the new account with a password prompt:

ldapwhoami \
  -x -H ldaps://openldap.dps.svc.cluster.local:636 \
  -D "uid=alice,ou=users,dc=cm,dc=cluster" \
  -W

Sign In with dpsctl#

In LDAP mode, enter your directory password at the prompt:

dpsctl --host api.dps.example.com --port 443 \
  --ca-cert-path /path/to/api-ca.crt login --username alice

The server returns an access token and a refresh token. dpsctl refreshes the access token when needed.

For a workflow that supplies a password file through secret management, pass its contents through standard input:

dpsctl login --username alice --password-stdin < /path/to/password-file

You can also supply DPSCTL_USERNAME and DPSCTL_PASSWORD through your secret-management workflow before running dpsctl login.

Programmatic Token Retrieval#

In LDAP mode, custom clients can exchange a username and password through nvidia.dcpower.v1.AuthService/Token. Send a passwordCredential with username and password fields over TLS. Use nvidia.dcpower.v1.AuthService/RefreshToken to refresh the returned tokens. For request and response definitions, refer to APIs.

OIDC#

In OIDC mode, your identity-provider administrator provisions your user account. The UI and interactive dpsctl must use separate public OAuth clients without client secrets. Neither client sends a secret during token exchange. Administrators register these clients through Configure OIDC Mode.

Sign In to the UI#

Open the UI sign-in page and follow the redirect to your identity provider. Complete sign-in there. The UI uses the authorization code flow with Proof Key for Code Exchange (PKCE) and sends the access token with API requests by default.

Sign In with dpsctl#

Use the issuer and public client ID provided by your administrator. The provider must support the device authorization flow. Run the following command without username/password options or a client secret.

dpsctl --oidc-issuer https://idp.example.com/realms/dps \
  --oidc-client-id dpsctl \
  --oidc-oauth-scope dps:api login

Open the displayed URL in a browser and enter the displayed code if requested. Complete sign-in through your identity provider. Browser login contacts the provider directly. Configure the DPS API endpoint on later commands, as shown in Check API Access.

Use --oidc-ca-cert-file if the identity provider uses a private CA. For endpoint overrides, refresh behavior, and optional ID token use, refer to dpsctl login.

For unattended applications, obtain client credentials for a separate confidential client as described in Obtain a Service Account Token.

Mutual TLS#

Mutual TLS (mTLS) client certificates can authenticate to specific gRPC services. For the certificate requirements and client command, refer to Mutual TLS. UI access uses LDAP or OIDC sign-in.

Check API Access#

After sign-in, confirm that your account can make a read-only request:

dpsctl --host api.dps.example.com --port 443 \
  --ca-cert-path /path/to/api-ca.crt topology list

If the request is denied, ask your administrator to check the configured access requirements. Repeating sign-in with the same account does not change its permissions.

Best Practices#

Use the following practices to manage user accounts:

  • Assign users only the groups and permissions they require.

  • Enforce your organization’s password and multifactor authentication requirements through the configured identity system.

  • Encrypt LDAP, identity-provider, and DPS connections in secure deployments.

  • Deactivate or remove accounts when users leave the organization.

Further Reading#

Refer to the following guides for account and server setup: