Authentication Profile
Table of Contents
Authentication Profile
- Device > Authentication Profile
Select or to manage
authentication profiles. To create a new profile, Add one
and complete the following fields.
After configuring an authentication profile,
use the test authentication CLI command to
determine whether the firewall or Panorama management server can
communicate with the back-end authentication server and whether
the authentication request succeeded. You can perform authentication tests
![]()
on the candidate
configuration to determine whether the configuration is correct
before you commit.
Authentication Profile Settings | Description |
|---|---|
Name | Enter a name to identify the profile. The
name is case-sensitive, can have up to 31 characters, and can include
only letters, numbers, spaces, hyphens, underscores, and periods.
The name must be unique in the current Location (firewall
or virtual system) relative to other authentication profiles and
to authentication sequences. In a firewall
that is in multiple virtual systems mode, if the Location of
the authentication profile is a virtual system, don’t enter the
same name as an authentication sequence in the Shared location.
Similarly, if the profile Location is Shared,
don’t enter the same name as a sequence in a virtual system. While
you can commit an authentication profile and sequence with the same
names in these cases, it can result in reference errors. |
Location | Select the scope in which the profile is
available. In the context of a firewall that has more than one virtual
system (vsys), select a vsys or select Shared (all
virtual systems). In any other context, you can’t select the Location;
its value is predefined as Shared (firewalls) or as Panorama.
After you save the profile, you can’t change its Location. |
Authentication Tab The
firewall invokes the authentication service that you configure in
this tab before invoking any multi-factor authentication (MFA) services
that you add in the Factors
Tab. If the firewall integrates with an MFA vendor
through RADIUS instead of the vendor API, you must configure a RADIUS
server profile for that vendor, not an MFA server profile. | |
Type | Select the type of service that provides
the first (and optionally the only) authentication challenge
that users see. Based on your selection, the dialog displays other
settings that you define for the service. The options are:
Administrators can use SAML to authenticate
to the firewall or Panorama web interface but not to the CLI. |
Server Profile (RADIUS, TACACS+,
LDAP, or Kerberos only) | Select the authentication server profile
from the drop-down. See Device > Server
Profiles > RADIUS, Device > Server
Profiles > TACACS+, Device > Server
Profiles > LDAP, or Device > Server
Profiles > Kerberos. |
IdP Server Profile (SAML only) | Select the SAML Identity Provider server
profile from the drop-down. See Device > Server
Profiles > SAML Identity Provider. |
Retrieve user group from RADIUS (RADIUS
only) | Select this option to collect user group
information from Vendor-Specific Attributes (VSAs) defined on the
RADIUS server. The firewall uses the information to match authenticating
users against Allow
List entries, not for enforcing policies or generating reports. |
Retrieve user group from TACACS+ (TACACS+
only) | Select this option to collect user group
information from Vendor-Specific Attributes (VSAs) defined on the
TACACS+ server. The firewall uses the information to match authenticating
users against Allow
List entries, not for enforcing policies or generating reports. |
Login Attribute (LDAP only) | Enter an LDAP directory attribute that uniquely
identifies the user and functions as the login ID for that user. |
Password Expiry Warning (LDAP only) | If the authentication profile is for GlobalProtect
users, enter the number of days before password expiration to start
displaying notification messages to users to alert them that their
passwords are expiring in x number of days. By default, notification
messages will display seven days before password expiry (range is
1 to 255). Users will not be able to access the VPN if their passwords
expire. Consider configuring the GlobalProtect agents
to use the pre-logon connection method
If users allow their passwords
to expire, the administrator can assign a temporary LDAP password
to enable users to log in to the VPN. In this workflow, we recommend
setting the Authentication Modifier in the
portal configuration to Cookie authentication for config
refresh (otherwise, the temporary password will be used
to authenticate to the portal, but the gateway login will fail,
preventing VPN access). |
Certificate for Signing Requests (SAML only) | Select the certificate that the firewall
will use to sign SAML messages that it sends to the identity provider
(IdP). This field is required if you enable the Sign
SAML Message to IdP option in the IdP Server
Profile (see Device > Server
Profiles > SAML Identity Provider). Otherwise, selecting
a certificate to sign SAML messages is optional. When generating
or importing a certificate and its associated private key, the key
usage attributes specified in the certificate control how you can
use the key:
Palo
Alto Networks recommends using a signing certificate to ensure the
integrity of SAML messages sent to the IdP. |
Enable Single Logout (SAML only) | Select this option to enable users to log
out of every authenticated service by logging out of any single
service. Single logout (SLO) applies only to services that users
accessed through SAML authentication. The services can be external
to your organization or internal (such as the firewall web interface).
This option applies only if you entered an Identity Provider
SLO URL in the IdP
Server Profile. You cannot enable SLO for Captive Portal users. After
logging out users, the firewall automatically removes their IP address-to-username mappings
|
Certificate Profile (SAML only) | Select the Certificate Profile that the
firewall will use to validate:
|
User Domain and Username Modifier (All authentication
types except SAML) | The firewall uses the User Domain for matching
authenticating users against Allow
List entries and for User-ID group mapping
You
can specify a Username Modifier to modify
the domain/username string that a user enters during login. The firewall
uses the modified string for authentication. Select from the following
options:
|
Kerberos Realm (All authentication
types except SAML) | If your network supports Kerberos single
sign-on (SSO), enter the Kerberos Realm (up
to 127 characters). This is the hostname portion of the user login
name. For example, the user account name user@EXAMPLE.LOCAL has
realm EXAMPLE.LOCAL. |
Kerberos Keytab (All authentication
types except SAML) | If your network supports Kerberos single sign-on (SSO)
If the
firewall is in FIPS/CC mode, the algorithm must be aes128-cts-hmac-sha1-96
or aes256-cts-hmac-sha1-96. Otherwise, you can also use des3-cbc-sha1
or arcfour-hmac. However, if the algorithm in the keytab does not
match the algorithm in the service ticket that the Ticket Granting
Service issues to clients to enable SSO, the SSO process fails.
Your Kerberos administrator determines which algorithms the service
tickets use. |
Username Attribute (SAML only) | Enter the SAML attribute that identifies
the username of an authenticating user in messages from the IdP
(default is username). If the IdP Server Profile contains
metadata that specifies a username attribute, the firewall automatically
populates this field with that attribute. The firewall matches usernames
retrieved from SAML messages with users and user groups in the Allow
List of the authentication profile. Because you cannot
configure the firewall to modify the domain/username string that
a user enters during SAML logins, the login username must exactly
match an Allow List entry. This is the only
SAML attribute that is mandatory. SAML messages might
display the username in the subject field. The firewall automatically
checks the subject field if the username attribute doesn’t display
the username. |
User Group Attribute (SAML only) | Enter the SAML attribute that identifies
the user group of an authenticating user in messages from the IdP
(default is usergroup). If the IdP Server Profile contains
metadata that specifies a user group attribute, the field automatically
uses that attribute. The firewall uses the group information to
match authenticating users against Allow List entries,
not for policies or reports. |
Admin Role Attribute (SAML only) | Enter the SAML attribute that identifies
the administrator role of an authenticating user in messages from
the IdP (default is admin-role). This attribute applies only
to firewall administrators, not to end users. If the IdP
Server Profile contains metadata that specifies an admin-role attribute,
the firewall automatically populates this field with that attribute. The
firewall matches its predefined (dynamic) roles or Admin Role profiles with
the roles retrieved from SAML messages to enforce role-based access control.
If a SAML message has multiple admin-role values for an administrator
with only one role, matching applies only to the first (left-most)
value in the admin-role attribute. For an administrator with more
than one role, the matching can apply to multiple values in the attribute. |
Access Domain Attribute (SAML only) | Enter the SAML attribute that identifies
the access domain of an authenticating user in messages from the
IdP (default is access-domain). This attribute applies only
to firewall administrators, not to end users. If the IdP
Server Profile contains metadata that specifies an access-domain attribute,
the firewall automatically populates this field with that attribute. The
firewall matches its locally configured access domains with those retrieved
from SAML messages to enforce access control. If a SAML message
has multiple access-domain values for an administrator with only one
access domain, matching applies only to the first (left-most) value
in the access-domain attribute. For an administrator with more than
one access domain, the matching can apply to multiple values in
the attribute. |
Factors Tab | |
Enable Additional Authentication Factors | Select this option if you want the firewall
to invoke additional authentication factors (challenges) after users
successfully respond to the first factor (specified in the Type field
on the Authentication tab). Additional
authentication factors are supported for end-user authentication
through Authentication Policy only. Additional factors are not supported
for remote user authentication to GlobalProtect portals and gateways
or for administrator authentication to the PAN-OS or Panorama web
interface. Although you can configure additional factors, they will
not be enforced for these use cases. You can, however, integrate with
MFA vendors using RADIUS or SAML for all authentication use cases. After
configuring an authentication profile that uses multi-factor authentication
(MFA), you must assign it to an authentication enforcement object
(Objects>Authentication)
and assign the object to the Authentication policy rules (Policies>Authentication) that
control access to your network resources. |
Factors | Add an MFA server profile (Device>ServerProfiles>
Multi Factor Authentication) for each authentication factor
that the firewall will invoke after users successfully respond to
the first factor (specified in the Type field
on the Authentication tab). The firewall
invokes each factor in the top-to-bottom order that you list the
MFA services that provide the factors. To change the order, select
a server profile and Move Up or Move Down.
You can specify up to three additional factors. Each MFA service
provides one factor. Some MFA services let users choose one factor
from a list of several. The firewall integrates with these MFA services through
vendor APIs. Additional MFA vendor API integrations are added
periodically through Applications or Applications and Threats content
updates. |
Advanced Tab | |
Allow List | Click Add and select all or
select the specific users and groups that can authenticate with
this profile. When a user authenticates, the firewall matches the
associated username or group against the entries in this list. If
you don’t add entries, no users can authenticate. To limit authentication to only the users
who have legitimate business access needs and reduce the attack
surface, specify users or user groups, don’t use all. If
you entered a User Domain value, you don’t
need to specify domains in the Allow List.
For example, if the User Domain is businessinc and
you want to add user admin1 to the Allow List,
entering admin1 has the same effect as entering businessinc\admin1.
You can specify groups that already exist in your directory service
or specify custom groups based on LDAP filters. |
Failed Attempts (All authentication
types except SAML) | Enter the number of failed successive login
attempts (0 to 10) that the firewall allows before locking out the
user account. A value of 0 specifies unlimited login attempts. The
default value is 0 for firewalls in normal operational mode and
10 for firewalls in FIPS-CC mode. Set
the number of Failed Attempts to 5 or fewer
to accommodate a reasonable number of retries in case of typing
errors, while preventing malicious systems from trying brute force
methods to log in to the firewall. If
you set the Failed Attempts to a value other
than 0 but leave the Lockout Time at 0, the Failed Attempts is
ignored and the user is never locked out. |
Lockout Time (All authentication
types except SAML) | Enter the number of minutes (range is 0
to 60; default is 0) for which the firewall locks out a user account
after the user reaches the number of Failed Attempts.
A value of 0 means the lockout applies until an administrator manually
unlocks the user account. Set the Lockout Time to
at least 30 minutes to prevent continuous login attempts from a
malicious actor. If you set
the Lockout Time to a value other than 0
but leave the Failed Attempts at 0, the Lockout
Time is ignored and the user is never locked out. |