Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.1

# Server security levels

The authentication option you choose is partly determined by the security level set for the server. P4 Server superusers can configure server-wide password usage requirements, password strength enforcement, and supported methods of user/server authentication by setting the `security` configurable.

To set or change the `security` configurable, issue the command:

     p4 configure set security=securitylevel

where `securitylevel` is `0`, `1`, `2`, `3`, `4`, `5`, or `6`

Server security level 4 or higher is recommended.

Each level includes the restrictions of lower levels and adds further restrictions.

Security level | Server behavior | Note
--- | --- | ---
`0` (or unset) | The default security level `0` does not require passwords and does not enforce password strength. Users with passwords can use either their `P4PASSWD` setting or the `p4 login` command for ticket-based authentication. |
`1` | Ensures that all users have passwords. (Users of old P4 Server applications can still enter weak passwords.) Users with passwords can use either their `P4PASSWD` setting or the `p4 login` command for ticket-based authentication. | To enforce a minimum password length at levels `1`, `2`, or `3`, use the `dm.password.minlength` configurable. You might want a value higher than the default of `8` characters. We strongly recommend that when you create a new user, you assign that user an initial password, and that you make it a strong password.
`2` | Ensures that all users have strong passwords. See Password strength requirements. Very old P4 Server applications continue to work, but users must change their password to a strong password and upgrade to 2003.2 or later.
`3` | Requires that all users have strong passwords, and requires the use of ticket-based (`p4 login`) authentication. If you have scripts that rely on passwords, use `p4 login` to create a ticket valid for the user running the script, or use `p4 login -p` to display the value of a ticket that can be passed to P4 Server commands as though it were a password. This can be done from the command line, p4 passwd -O oldpass-P newpass or by setting `P4PASSWD` to the value of the valid ticket. It is prohibited to set passwords with the `p4 user` form or the command
`4` | In multi-server and replicated environments, this level ensures that only authenticated service users can connect to this server, and all replicas need server specs. The following checks are also made: The request must come from a replica with a valid serverid. The serverid must identify a valid server spec. If the server spec has a user field, the request must come from that service user. If the server spec has filters, these are used in preference to whatever filters might have been specified by the replica. | Security level 4 and higher implicitly disables the built-in user named `remote`. Disabling user `remote` can enhance security by ensuring that requests must come from a replica with a valid serverid. To learn more, see Remote depots for code drops. Unless your P4 Server is a standalone server, set the security level to 4 or higher, which protects multi-server and replicated environments. To learn more, see Secure the server.
`5` | Requires that any intermediary has a valid authenticated service user. Intermediaries include, but are not limited to, P4 Broker, P4 Proxy, P4 Code Review, and P4 DAM.
`6` | Requires each intermediary to have a valid server spec, where the service user must match the user named in the `User` field of the spec. The server spec is found by matching the intermediary's P4PORT with a value in the `AllowedAddresses` field of the spec. For example, if connecting to a proxy on `10.0.0.100:1667`, a server spec with this IP address and port number in the `AllowedAddresses` field must exist and must specify the proxy's service user in the `User` field. If structured logging is enabled, errors relating to configuration of intermediaries are logged to the `route.csv` logfile. To learn more, see Enable and configure structured logging.

## Authentication triggers or LDAP

When user authentication occurs through authentication triggers or the native LDAP configuration,
if `security` is:

- Unset, or set to `0`, `1`, or `2`, the server behaves as if the security level is set to 3.
- Set to `3` or higher, the server uses that setting.

Your search for returned results