User Policies: Registration and Passwords

Overview

User Policies controls how people get accounts and what those accounts must satisfy. These are system-wide settings and require Administrator access.

Nav path: Settings → Licensing & Users → User Policies. See Administration settings for the wider map.

Registration

Three settings decide how someone becomes a user, and they combine:

The combination that matters most is the first two. Allow public user registration on, with Require admin approval off, means anyone who reaches your instance gets in unreviewed. That may be fine for an internal network and is rarely fine otherwise.

The common safe configurations:

• Invite-only — public registration off. Users arrive only via invitation. The right default for most teams.
• Open with a gate — public registration on, admin approval on. Useful when you want self-service without losing control of who gets in.
• Open — public registration on, approval off. Only sensible where the network already restricts who can reach the product.

Leave Require email verification on in all of them. It costs a user one click and it stops accounts being created against addresses that don't exist or aren't theirs.

Default Role Settings

Default User Role is the role a new user receives when nothing more specific applies.

Set this to the lowest-privilege role that lets someone do useful work. It's the role every account that arrives through a path nobody thought about will land on, so it should be the one you'd be comfortable handing to a stranger. Elevate individuals afterwards.

See Role permissions for what each role can do.

Max Users Per Project

Max Users Per Project caps how many users a single project may have. Use it to keep project membership deliberate rather than accumulating everyone who ever needed a look.

Note this is separate from your licence's user entitlement — see License management.

Password requirements

The password policy applies to every account:

A note on how these interact in practice: Minimum Length does far more for real security than the four character-class rules combined. Length is what defeats brute force; composition rules mostly push people toward predictable substitutions and writing passwords down. If you want one lever, raise the length.

Maximum Age deserves thought rather than reflex. Forced rotation on a short cycle tends to produce weaker passwords with a counter on the end. Modern guidance favours rotating on evidence of compromise rather than on a timer. Set it if your compliance regime requires it; otherwise a long or unset age with a strong length is usually the stronger position.

On Enterprise, SSO takes most of this off your plate — authentication moves to your identity provider and its policy governs. See Single sign-on.

Resetting

Reset User Policies returns these settings to defaults. It affects who can register and what passwords are accepted from that point on, so treat it as a deliberate act rather than a way to clear a form.

Troubleshooting

• New users can't sign in after registering — Require admin approval or Require email verification is on and the step hasn't completed. Check pending accounts in User management.
• Nobody can register at all — Allow public user registration is off. That's an invite-only configuration; invite them instead.
• A user can't be added to a project — you may be at Max Users Per Project, or at your licence's user limit. They're different limits with a similar symptom.
• Password changes are rejected — the new password fails a policy rule. The rules are cumulative; all enabled ones must pass.
• Settings are read-only — you're not an Administrator.

Related articles

• User management
• Role permissions
• Administration settings
• Single sign-on
• License management