Centralized authorization server (P4AUTH)

If you are running multiple Helix Servers, you can configure them to retrieve protections and licensing data from a centralized authorization server. By using a centralized server, you are freed from the necessity of ensuring that all your servers contain the same users and protections entries.

Note

When using a centralized authentication server, all outer servers must be at the same (or newer) release level as the central server.

If a user does not exist on the central authorization server, that user does not appear to exist on the outer server.

You can use any existing Helix Core Server in your organization as your central authorization server. The license file for the central authorization server must be valid because it governs the number of licensed users that are permitted to exist on outer servers. To configure a Helix Core Server to use a central authorization server, set P4AUTH before starting the server, or specify it on the command line when you start the server.

Central server must be at version 2023.1 or later

Starting with release 2023.1, servers using central authentication (P4AUTH) require the central server's release version to be at least 2023.1. The central server must have a valid license, and must be running when its outer servers are starting up or being upgraded.

P4AUTH and p4 info

If your server is making use of a centralized authorization server, the following line will appear in the output of p4 info:

...
Authorization Server: [protocol:]host:port

Where [protocol:]host:port refers to the protocol, host, and port number of the central authorization server. See Specifying hosts.

In the following example, an outer server is configured to use a central authorization server (named central). The outer server listens for user requests on port 1999 and relies on the central server’s data for user, group, protection, review, and licensing information. It also joins the protection table from the server at central:1666 to its own protections table.

For example:

$ p4d -a central:1666 -p 1999

Note

On Windows, configure the outer server with p4 set -S as follows:

C:\> p4 set -S "Outer Server" P4AUTH=central:1666
C:\> p4 set -S "Outer Server" P4PORT=1999

Commands that the central server processes

When you configure a central authorization server, outer servers forward the following commands to the central server for processing:

Command	Forwarded to auth server?	Note
`p4 group`	Yes	Local group data is derived from the central server.
`p4 groups`	Yes	Local group data is derived from the central server.
`p4 license`	Yes	License limits are derived from the central server. License updates are forwarded to the central server.
`p4 passwd`	Yes	Property values are derived from the central server.
`p4 property`	Yes	For example, if two Swarm instances use the same auth server, updating one instance can update the other instance.
`p4 review`	No	The default user named `remote` must have access to the central server. However, best practice is to create Service users and not use the default user named `remote`. See Restricting access to remote depots.
`p4 reviews`	No	The default user named `remote` must have access to the central server. However, best practice is to create Service users and not use the default user named `remote`. See Restricting access to remote depots.
`p4 user`	Yes	Local user data is derived from the central server.
`p4 users`	Yes	Local user data is derived from the central server.
`p4 protect`	No	The local server’s protections table is displayed if the user is authorized (as defined by the combined protection tables) to edit it.
`p4 protects`	Yes	Protections are derived from the central server’s protection table as appended to the outer server’s protection table.
`p4 login`	Yes	Command is forwarded to the central server for ticket generation.
`p4 logout`	Yes	Command is forwarded to the central server for ticket invalidation.

Limitations and notes

Helix Swarm is not supported with the centralized authentication server.
All servers that use P4AUTH must have the same Unicode setting as the central authorization server.
Setting P4AUTH by means of a p4 configure set P4AUTH=[protocol:]server:port command requires a restart of the outer server.

If you need to set P4AUTH for a replica, use the following syntax:

p4 configure set ServerName#P4AUTH=[protocol:]server:port
If you have set P4AUTH, no warning will be given if you delete a user who has an open file or client.
To ensure that p4 review and p4 reviews work correctly, you must enable remote depot access for the service user (or, if no service user is specified, for a user named remote) on the central server.

Note: There is no remote type user but there is a special user named remote that is used to define protections for a remote depot.
To ensure that the authentication server correctly distinguishes forwarded commands from commands issued by trusted, directly-connected users, you must define any IP-based protection entries in the Perforce service by prepending the string “proxy-” to the [protocol:]host:port definition.
Important
Before you prepend the string proxy- to the workstation’s IP address, make sure that a broker or proxy is in place.
Protections for non-forwarded commands are enforced by the outer server and use the plain client IP address, even if the protections are derived from lines in the central server’s protections table.