Select Device > Authentication Profile or Panorama > Authentication Profile 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.
on the candidate configuration to determine whether the configuration is correct before you commit.|
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.
|
|||||||||||||||||
|
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.
|
|||||||||||||||||
|
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:
|
|||||||||||||||||
|
(RADIUS, TACACS+, LDAP, or Kerberos only)
|
|||||||||||||||||
|
(SAML only)
|
|||||||||||||||||
|
(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.
|
||||||||||||||||
|
(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.
|
||||||||||||||||
|
(LDAP only)
|
|||||||||||||||||
|
(LDAP only)
|
Consider configuring the GlobalProtect agents to use the pre-logon connection method
. This will enable users to connect to the domain to change their passwords even after the password has expired.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).
|
||||||||||||||||
|
(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.
|
||||||||||||||||
|
(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 Authentication Portal users.
|
||||||||||||||||
|
(SAML only)
|
|
||||||||||||||||
|
(All authentication types except SAML and Cloud Authentication Service)
|
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 format of the domain and username that a user enters during login. The firewall uses the modified string for authentication. Select from the following options:
Note:
If the Username Modifier includes the %USERDOMAIN% variable, the User Domain value replaces any domain string that the user enters. If you specify the %USERDOMAIN% variable and leave the User Domain blank, the firewall removes any user-entered domain string. The firewall resolves domain names to the appropriate NetBIOS name for User-ID group mapping. This applies to both parent and child domains. User Domain modifiers take precedence over automatically derived NetBIOS names.
|
||||||||||||||||
|
(All authentication types except SAML and Cloud Authentication Service)
|
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.
|
||||||||||||||||
|
(All authentication types except SAML and Cloud Authentication Service)
|
If your network supports Kerberos single sign-on (SSO)
, click Import, click Browse to locate the keytab file, and then click OK. A keytab contains Kerberos account information (principal name and hashed password) for the firewall, which is required for SSO authentication. Each authentication profile can have one keytab. During authentication, the firewall first tries to use the keytab to establish SSO. If it succeeds and the user attempting access is in the Allow List, authentication succeeds immediately. Otherwise, the authentication process falls back to manual authentication (username/password) of the specified Type, which doesn’t have to be Kerberos. |
||||||||||||||||
|
(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 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.
|
||||||||||||||||
|
(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.
|
||||||||||||||||
|
(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.
|
||||||||||||||||
|
(Cloud Authentication Service only)
|
Note:
The region you select must match the region you select when you activate your Cloud Identity Engine instance. |
||||||||||||||||
|
(Cloud Authentication Service only)
|
|||||||||||||||||
|
(Cloud Authentication Service only)
|
If you have more than one Cloud Identity Engine identity provider profile (IdP profile), select the Cloud Identity Engine IdP profile you want to use.
|
||||||||||||||||
|
(Cloud Authentication Service only)
|
|||||||||||||||||
|
(Cloud Authentication Service only)
|
Enable force multi-factor authentication in cloud if your IdP is configured to require users to log in using multi-factor authentication.
|
||||||||||||||||
|
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).
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.
|
|||||||||||||||||
|
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.
|
|||||||||||||||||
|
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.
|
|||||||||||||||||
|
(All authentication types except SAML)
|
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.
|
||||||||||||||||
|
(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.
|
||||||||||||||||
