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

P4 Server Administration Documentation | 2025.2

# Authorization server (P4AUTH)

Using an Authorization server frees you from the necessity of ensuring that all your servers contain the same users and protections entries.

If you are running multiple P4 Servers, you can configure them to retrieve protections and licensing data from the dedicated server configured as the Authorization server by the environment variable, P4AUTH.

On this page, "outer server" means any server that connects to the Authorization server.

## Prerequisites

1. Use a dedicated server as the Authorization server.

2. All outer servers must be at the same, or newer, release level as the Authorization server.

3. Ensure that the license file for the Authorization server is valid because it governs the number of licensed users that are permitted to exist on the outer servers.

4. Each user must exist on the Authorization server. Otherwise such users will not appear to exist on the outer servers.

5. Configure any serviceUser that is used by an outer server to be a valid service user on the Authorization serverbefore you set the `P4AUTH` environment variable on the outer server. Otherwise a lockout occurs.

6. To ensure that p4 review and p4 reviews work correctly, enable remote depot access for the service user on the Authorization server.

7. Starting with release 2023.1, servers using P4AUTH authentication require the Authorization server's release version to be at least 2023.1.

8. All servers that use `P4AUTH` must have the same Unicode setting as the Authorization server.

## Configure the Authorization server

To configure a P4 Server to use the Authorization server, set the `P4AUTH` environment variable before starting the server, or specify it on the command line when you start the server.

The Authorization server must be running when its outer servers are starting up or being upgraded.

## P4AUTH and p4 info

If your P4 Server is making use of an Authorization server for authentication and authorization, 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 Authorization server. See Specify hosts.

For example, an outer server is configured to use an Authorization server named `guardian`. The outer server listens for user requests on port 1999 and relies on the Authorization server’s data for user, group, protection, review, and licensing information. It also joins the protection table from the server at `guardina:1666` to its own protections table.

For example:

    p4d -a guardian:1666 -p 1999

### Windows outer server

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

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

## Commands that the Authorization server processes

When you configure an Authorization server, outer servers forward the following commands to the Authorization server for processing:

Command | Forwarded to auth server? | Note
--- | --- | ---
`p4 group` | Yes | Local group data is derived from the Authorization server.
`p4 groups` | Yes | Local group data is derived from the Authorization server.
`p4 license` | Yes | License limits are derived from the Authorization server. License updates are forwarded to the Authorization server.
`p4 passwd` | Yes | This command to change the password is forwarded to the Authorization server.
`p4 property` | Yes | Local property data is derived from the Authorization server.
`p4 review` | No | The default user named `remote` must have access to the Authorization server. However, best practice is to create Service users and not use the default user named `remote`. See Restrict access to remote depots.
`p4 reviews` | No | The default user named `remote` must have access to the Authorization server. However, best practice is to create Service users and not use the default user named `remote`. See Restrict access to remote depots.
`p4 user` | Yes | Local user data is derived from the Authorization server.
`p4 users` | Yes | Local user data is derived from the Authorization 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 Authorization server’s protection table as appended to the outer server’s protection table.
`p4 login` | Yes | Command is forwarded to the Authorization server for ticket generation.
`p4 logout` | Yes | Command is forwarded to the Authorization server for ticket invalidation.

## Limitations and notes

- P4 Code Review is not supported with the P4AUTHized authentication 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 the `P4AUTH` environment variable, no warning will be given if you delete a user who has an open file or client.
- To ensure that the Authorization 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. 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 Authorization server’s protections table.

Your search for returned results