Server security levels

The authentication option you choose is partly determined by the security level set for the server. Helix 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:

Security level Server behavior

0 (or unset)

The default security level 0 does not require passwords and does not enforce password strength.


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.

A new user with no password can run p4 passwd unchallenged. For example, p4 -u newUser passwd allows anyone who knows the value of newUser to set the new password without any prior authentication.

This security issue is present even though security levels higher than level 1 require passwords for all user accounts.

Users with passwords can use either their P4PASSWD setting or the p4 login command for ticket-based authentication.


Ensures that all users have passwords. (Users of old Helix 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.


Ensures that all users have strong passwords. See Password strength requirements.

Very old Helix Server applications continue to work, but users must change their password to a strong password and upgrade to 2003.2 or later.


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 Helix Server commands as though it were a password (that is, either from the command line, or by setting P4PASSWD to the value of the valid ticket).

Setting passwords with the p4 user form or the p4 passwd -O oldpass -P newpass command is prohibited.


In multi-server and replicated environments this level ensures that only authenticated service users (subject to all of the restrictions of level 3) can connect to this server.

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.

Requires that any intermediary (such as a proxy or broker) has a valid authenticated service user.


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, 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.

Errors relating to configuration of intermediaries are logged to the route.csv logfile, if structured logging is enabled. See Enable and configure structured logging.


Use the dm.password.minlength configurable to enforce a minimum password length at levels 1 - 3.

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