Custom usernames
By default every job gets a unique, generated cluster username. Custom usernames make that username stable and recognizable per person, which is what lets you attribute a license checkout in an ISV log to a specific engineer.
Why you'd want this
License server logs record the cluster username that checked out a feature. With generated per-job usernames, those logs are unattributable. You can see that 40 checkouts happened, but not who was responsible.
With a custom username policy, the same person always resolves to the same cluster username, so ISV license logs, cluster audit trails, and chargeback reports line up with real people. If you are trying to work out which team is consuming a constrained license pool, this policy is the prerequisite: without it the logs simply do not carry the information.
Where a policy is set
A policy attaches either to the organization or to a single workspace, and the choice decides whether one person can carry different usernames in different places.
The two levels do not offer the same options. An organization-level policy can derive the username automatically, using any of the three modes described below. A workspace-level policy only accepts manually specified usernames, though it will fall back to the organization policy for any user who has no workspace-specific username, which is what lets you override one person without hand-entering everybody.
Pick organization-level unless you have a real reason to differ per workspace. Consistency is the whole point of the feature, and a username that changes between workspaces reintroduces the attribution problem you adopted it to solve.
How the username is derived
An organization-level policy chooses between deriving the username from something Rescale already knows and having an administrator state it outright. The first two modes below derive it and need no ongoing maintenance; the third does not, and that difference matters more than it appears.
From email address
The username is the local part of the email: johndoe@example.com → johndoe.
This is the simplest option and usually the right default. Watch for collisions, though: two people at different domains who share a local part, such as jsmith@example.com and jsmith@contractor.com, resolve to the same username and conflict.
From SSO IdP response
The username comes from an attribute your identity provider releases. Use this when your directory already holds the canonical username you want in license logs.
Two consequences worth planning for:
- Existing users may need to sign out and back in via SSO before the new username takes effect.
- Usernames must be unique. Duplicates fail — so if your IdP releases a non-unique attribute, this mode won't work.
Custom (manually specified)
Each user's username is set explicitly.
If you select Custom at the organization level, every user in the organization must have a username specified. There is no default and no automatic derivation. A user without one has nothing to fall back to.
On a large organization this is a substantial data-entry commitment, and it stays a commitment: every new hire needs one before they can run work. Prefer From email address or From SSO unless you specifically need arbitrary usernames.
Valid characters
A username has to be valid for the operating system running on your clusters, so Rescale accepts letters (A-Z and a-z), digits (0-9), the dash - and the underscore _.
Linux and Windows then differ in what they add on top, length limits and reserved names in particular. A username made only of the characters above is normally safe on both, so when one is rejected despite looking valid, an operating-system constraint is usually the reason.
A workstation or job that is already running or suspended keeps the username it launched with. The new policy applies to work launched afterwards.
That's usually what you want, but it means a suspended workstation can resume with the old username indefinitely, so a license-log audit spanning a policy change will show both.
Setting it up
Custom username policies are configured by Rescale, not self-service. Contact your Rescale representative with the level you want (organization or workspace), the mode, and (for Custom mode) the full username list.
Related
- Invite and manage users — identity vs user, which determines policy scope
- Licensing — where license checkouts are recorded
- Single sign-on — the source for SSO-derived usernames
- Audit logs — platform-side activity records