Configure Kerberos Authentication for Explicit Proxy Deployments

Set up your Explicit Proxy deployment.

Get the FQDN, proxy FQDNs, and DNS CNAMEs that are required to set up your Kerberos authentication.

Kerberos authentication uses the information retrieved from the Prisma Access API script to create and configure the Kerberos keytabs. The API script retrieves the following information:

ep_geo_lb_fqdn
—The Explicit Proxy DNS FQDN used in the Explicit Proxy network load balancer configuration. This FQDN is identical to the Explicit Proxy
Explicit Proxy URL
in the Prisma Access UI under
Settings
Prisma Access Setup
Explicit Proxy
.
ep_geo_lb_cname
—The DNS CNAME for the Explicit Proxy tenant.
ep_regional_fqdn
—The FQDNs used for the onboarded Explicit Proxy locations.
Explicit Proxy gives each location a public IP address for the network load balancer; the ep_regional_fqdn is the FQDN associated with that IP address. If multiple locations share the same public IP address, those locations use the same regional FQDN.

Go to Cloud Managed Prisma Access and select
Settings
Prisma Access Setup
Shared
.
Generate New API Key
.
You use this key as part of the API curl command.

Create a .txt file and enter the following command options in the file:
{
"serviceType": "swg_proxy",
"location": "deployed",
"addrType": "network_load_balancer"
}
Enter the following command to retrieve the required FQDNs to use Kerberos authentication:
curl -X POST --data @option.txt -H header-api-key:Current-API-Key "https://api.prod.datapath.prismaaccess.com/getPrismaAccessIP/v2"
Where
option.txt
is the .txt file you created in a previous step and
Current-API-Key
is the Prisma Access API key.
Make a note of the FQDNs.
There is at least one
ep_geo_lb_fqdn
, one
ep_geo_lb_cname
, and one
ep_regional_fqdn
per onboarded location.

Create a new user for the Prisma Access Explicit Proxy service in your organization’s Active Directory (AD) by entering the following command:

New-ADUser -Name "
USER_NAME" -GivenName "
USER_GIVEN_NAME" -SamAccountName "
USER_SAMACCOUNTNAME" -UserPrincipalName "
USER_NAME@
DNS_DOMAIN_NAME" -Path "
X_500_PATH" –AccountPassword (ConvertTo-SecureString “
PASSWORD” -AsPlainText -force) -Enabled $true -KerberosEncryptionType RC4,AES128,AES256

Where:

USER_NAME
is the name of the user object.
USER_GIVEN_NAME
is the user’s given name.
USER_SAMACCOUNTNAME
is the user’s Security Account Manager (SAM) name.
USER_NAME
@
DNS_DOMAIN_NAME
is the user’s user principal name (UPN).
X_500_PATH
is the X.500 path of the OU or container where the new object is created (for example,
DC=EXAMPLE,DC=COM
.)
PASSWORD
is the password to use for the account.

The following CLI example has a user name of

example

, a SAM name of

example

, a given name of

PrismaAccess EP Service User

, a UPN of

example@exmp.com

, a path of

DC=EXMP,DC=COM

, and a password of Ex@mple123:

New-ADUser -Name "example" -GivenName "PrismaAccess EP Service User" -SamAccountName "example" -UserPrincipalName "example@exmp.com" -Path "DC=EXMP,DC=COM" –AccountPassword (ConvertTo-SecureString “Ex@mple123” -AsPlainText -force) -Enabled $true -KerberosEncryptionType RC4,AES128,AES256

The previous command specifies an encryption type of RC4, which uses a weak NTLM hash. Follow your organization’s security policies and guidelines to include or exclude RC4 in this command.

Enter the following command to prevent the password from expiring and to prevent it from being changed:

Get-ADUser 
USER_NAME|Set-ADUser -PasswordNeverExpires:$True -CannotChangePassword:$true

Follow your organization’s security policies and guidelines for password expiration and rotation policies.

Enter the following command to display the newly-created user account:

Get-ADUser 
USER_NAME -property msDS-
KeyVersionNumber

Associate the SPNs and export keytab files to use with Kerberos authentication in your Windows AD.

A keytab file allows Explicit Proxy to validate the Kerberos authentication tokens provided during the traffic flows from users, servers, IoT devices, or other headless machines. During the keytab file creation, Explicit Proxy requires that the values you retrieved using the API in Step 2 be associated as ServicePrincipalNames (SPNs) with the user account you created in Step 3.

Use the

ep_geo_lb_fqdn

,

ep_geo_lb_cname

, and

ep_regional_fqdn

values. These values allow Explicit Proxy to authenticate traffic flows to either of those proxy domains.

Generate and export a keytab using the

ep_geo_lb_fqdn

value as the service principal name (SPN) by entering the following commands:

ktpass -princ HTTP/
ep_geo_lb_fqdn@
REALM -mapuser 
DOMAIN\
USER_NAME -ptype KRB5_NT_PRINCIPAL -crypto all -pass 
PASSWORD -out 
KEYTAB_NAME_1.keytab

Where:

ep_geo_lb_fqdn
is the
ep_geo_lb_fqdn
value returned from the Explicit Proxy API script.
REALM
is the realm (for example,
EXMP.COM
).
In most cases, you enter the realm using uppercase letters.
DOMAIN
\
USER_NAME
is the domain-level logon name (for example,
EXMP\example
).
PASSWORD
is the password to use for the keytab. This password does not have to match the user password, but must match the value you create for the
ep_geo_lb_cname
and
ep_regional_fqdn
SPNs in the next steps.
KEYTAB_NAME_1
is the name of the keytab. The keytab name must be unique to this SPN.

Be sure to follow the best practices for creating SPNs and passwords.

The following CLI example has an

ep_geo_lb_fqdn

of

example.proxy.prismaaccess.com

, a

REALM

of

EXMP.COM

, a

DOMAIN

\

USER_NAME

of

EXMP\example

, a

PASSWORD

of

Ex@mple123

, and an exported keytab name of

exmp1.keytab

:

ktpass -princ HTTP/example.proxy.prismaaccess.com@EXMP.COM -mapuser EXMP\example -ptype KRB5_NT_PRINCIPAL -crypto all -pass Ex@mple123 -out exmp1.keytab

Generate and export a keytab using the

ep_geo_lb_cname

value as the SPN by entering the following commands:

ktpass -princ HTTP/
ep_geo_lb_cname@
REALM -mapuser 
DOMAIN\
USER_NAME -ptype KRB5_NT_PRINCIPAL -crypto all -pass 
PASSWORD -out 
KEYTAB_NAME_2.keytab

Where:

ep_geo_lb_cname
is the
ep_geo_lb_cname
value returned from the Explicit Proxy API script.
REALM
is the realm for example,
EXMP.COM
DOMAIN
\
USER_NAME
is the domain-level logon name (for example,
EXMP\example
).
PASSWORD
is the password to use for the keytab. This password must match the
ep_geo_lb_fqdn
and
ep_regional_fqdn
SPN passwords.
KEYTAB_NAME_2
is the name of the keytab you want to export. This name should be different than the other SPN keytab names you create.

The following CLI example has an

ep_geo_lb_cname

of

prisma-abcde12345.proxy.prismaaccess.com

, a

REALM

of

EXMP.COM

, a

DOMAIN

\

USER_NAME

of

EXMP\example

, a

PASSWORD

of

Ex@mple123

, and an exported keytab name of

exmp2.keytab

:

ktpass -princ HTTP/prisma-abcde12345.proxy.prismaaccess.com@EXMP.COM -mapuser EXMP\example -ptype KRB5_NT_PRINCIPAL -crypto all -pass Ex@mple123 -out exmp2.keytab

Generate and export a keytab using the

ep_regional_fqdn

value as the SPN by entering the following commands:

ktpass -princ HTTP/
ep_regional_fqdn@
REALM -mapuser 
DOMAIN\
USER_NAME -ptype KRB5_NT_PRINCIPAL -crypto all -pass 
PASSWORD -out 
KEYTAB_NAME_3.keytab

Where:

ep_regional_fqdn
is the
ep_regional_fqdn
value returned from the Explicit Proxy API script.
REALM
is the realm (for example,
EXMP.COM
).
DOMAIN
\
USER_NAME
is the domain-level logon name (for example,
EXMP\example
).
PASSWORD
is the password to use for the keytab. This password must match the
ep_geo_lb_fqdn
and
ep_geo_lb_cname
SPN passwords.
KEYTAB_NAME_3
is the name of the keytab you want to export. This name should be different than the other SPN keytab names you create.

The following CLI example has an

ep_regional_fqdn

of

us-west-2.prisma-abcde12345.proxy.prismaaccess.com

, a

REALM

of

EXMP.COM

, a

DOMAIN

\

USER_NAME

of

EXMP\example

, a

PASSWORD

of

Ex@mple123

, and an exported keytab name of

exmp3.keytab

:

ktpass -princ HTTP/us-west-2.prisma-abcde12345.proxy.prismaaccess.com@EXMP.COM -mapuser EXMP\example -ptype KRB5_NT_PRINCIPAL -crypto all -pass Ex@mple123 -out exmp3.keytab

(

Optional

) If you have additional locations that use different

ep_regional_fqdn

values, and you want to create keytabs for those locations, generate and export one or more additional keytabs by repeating Step 6.c, using the

ep_regional_fqdn

value for those locations.

Create a unique keytab name for each unique

ep_regional_fqdn

. For example, if the

ep_regional_fqdn

for another location is

us-east-2.prisma-abcde12345.proxy.prismaaccess.com

, enter the following sample CLI with a unique exported keytab file name:

ktpass -princ HTTP/us-east-2.prisma-abcde12345.proxy.prismaaccess.com@EXMP.COM -mapuser EXMP\example -ptype KRB5_NT_PRINCIPAL -crypto all -pass Ex@mple123 -out exmp4.keytab

Delete unsupported ciphers in the created keytabs by entering the following

ktutil

commands in Ubuntu.

The following system output provides examples for cleaning up various ciphers:

slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 3 HTTP/us-west-2.prisma-abcde12345.proxy.prismaaccess.com@PANW.COM (des-cbc-crc)
2 3 HTTP/us-west-2.prisma-abcde12345.proxy.prismaaccess.com@PANW.COM (des-cbc-md5)
3 3 HTTP/us-west-2.prisma-abcde12345.proxy.prismaaccess.com@PANW.COM (arcfour-hmac)
4 3 HTTP/us-west-2.prisma-abcde12345.proxy.prismaaccess.com@PANW.COM (aes256-cts-hmac-sha1-96)
5 3 HTTP/us-west-2.prisma-abcde12345.proxy.prismaaccess.com@PANW.COM (aes128-cts-hmac-sha1-96)

# display all keytabs, get the key entry numbers to remove DES-CBC-MD5 and DES-CBC-CRC. 
# Also, enable or disable RC4-HMAC based on your organization’s policy.
for i in `ls keytab_name*.keytab`; do echo $i; klist -Kte -k $i; done

# cleanup unsupported ciphers
# entry #1 is typically des-cbc-crc
# entry #2 is typically des-cbc-md5
# entry #3 is typically arcfour-hmac

ktutil
rkt 
KEYTAB_NAME_1.keytab
delent 2 
delent 1
wkt new1.keytab
quit

ktutil
rkt 
KEYTAB_NAME_2.keytab
delent 2 
delent 1
wkt new2.keytab
quit

ktutil
rkt 
KEYTAB_NAME_3.keytab
delent 2 
delent 1
wkt new3.keytab
quit

Where

KEYTAB_NAME_1

.keytab,

KEYTAB_NAME_2

.keytab, and

KEYTAB_NAME_3

.keytab are the keytabs you created in the previous step.

(

Optional

) If you created more keytabs for other regions, remove unsupported ciphers on those keytabs by entering the previous

ktutil

command, substituting

KEYTAB_NAME_1

.keytab with the keytab name you used for the region or regions and specifying a different output file (for example,

new4.keytab

,

new5.keytab

, and so on).

Merge the keytabs you created by entering the following

ktutil

command, where new1.keytab, new2.keytab, and new3.keytab are the keytabs you created in the previous step, Be sure to include all the region-specific keytabs in this command:

ktutil
rkt new1.keytab
rkt new2.keytab
rkt new3.keytab
# if you created any additional region-specific keytab files, add them here.
wkt papxv1.keytab
quit

When complete, you use the keytab you created (

papxv1.keytab

in this example) as the keytab to use with Explicit Proxy.

(

Optional

) If you need to add more regions to the keytab file you created later, use the Prisma Access API script to get the

ep_regional_fqdn

for that region, then repeat Step 6.c to generate and export a keytab for the newly-added region.

The following command is a sample, where:

us-south-1.prixma-abcde12345.prismaaccess.com@EXMP.COM
is the
ep_regional_fqdn
and
realm
.
EXMP\example
is the domain-level logon name.
Ex@mple123
is the password.
KEYTAB_NAME_5.keytab
is the name of the newly-created regional keytab file.
new5.keytab
is the name of the keytab file with the ciphers removed.
papxv1.keytab
and
new5.keytab
are the keytabs you are combining to create the final keytab,
papxv2.keytab
.

# associate new ep_regional_fqdn as SPN
ktpass -princ HTTP/us-south-1.prixma-abcde12345.prismaaccess.com@EXMP.COM -mapuser EXMP\example -ptype KRB5_NT_PRINCIPAL -crypto all -pass Ex@mple123 -out KEYTAB_NAME_5.keytab
# repeat cleanup and merge of KEYTAB_NAME_5.keytab to generate new5.keytab, and merge it with papxv1.keytab. 

ktutil
rkt KEYTAB_NAME_5.keytab
delent 2 
delent 1
wkt new5.keytab
quit

ktutil
rkt papxv1.keytab
rkt new5.keytab
wkt papxv2.keytab
quit

When complete, you use the keytab you created (papxv2.keytab in the previous example) as the keytab to use with Explicit Proxy. Update the authentication profile with this new keytab.

Set up a Kerberos authentication profile.

The profile defines how Explicit Proxy connects to the Kerberos server for mobile user authentication.

Go to
Manage
Configuration
Identity Services
Authentication
Authentication Profiles
, set the scope to
Explicit Proxy
, and
Add Profile
.

Select the
Authentication Method
:
Kerberos
.

Enter the
Profile Name
to identify the server profile.
The authentication profile specifies the server profile that the portal or gateways use when they authenticate users.
Enter the
Kerberos Realm
(up to 127 characters) to specify the hostname portion of the user login name. For example, the user account name user@EXMP.COM has the realm EXMP.COM.
Import the
Kerberos Keytab
(
Import Keytab
) you created in Step 9.
During authentication, the endpoint first attempts to establish SSO using the keytab.

Add the
Users Allowed to Authenticate
with this profile.
To select all users,
Match all
.
If you’re using the Cloud Identity Engine to populate the list of users, select the users from a list, or select
all
to allow all users to authenticate.
To add local users that can log in using Kerberos,
Add Local User
, add the
Name
, and create a
Password
.

Save
your changes.

Associate the authentication profile with an authentication method.

Go to
Settings
Prisma Access Setup
Explicit Proxy
.

Select the
Connection Name
.
Select an
Authentication Method
of
Kerberos
and select the Kerberos
Profile
you created.

Save
your changes.

Add the egress IP addresses of the branch or campus location where your users, servers, IoT devices, or headless machines are located to the list of trusted Explicit Proxy addresses.

Go to
Settings
Prisma Access Setup
Explicit Proxy
.

Add Address
(one or more) to the
Trusted Source Address
field.
If you do not add the egress endpoint IP addresses to the trusted list, Explicit Proxy forces users and machines to authenticate with SAML as well as Kerberos.
Enter a maximum of 100,000 IP addresses.

Save
your changes.

Push Config

to save your configuration changes.

Verify that Kerberos authentication is working with Prisma Access by viewing the traffic and authentication logs.

(

Decrypted traffic only

) Go to

Activity

Log Viewer

Firewall/Traffic

and check that the Kerberos authentication is working.

Decrypted traffic displays the user name in the traffic logs.

(

Undecrypted traffic only

) Go to

Activity

Log Viewer

Firewall/Authentication

and check that Kerberos authentication is working correctly.

The following fields provide more information about the authentication event:

Object
—The website the user was attempting to access before being redirected to Kerberos to authenticate.
Auth Event
—The status of the authentication attempt.
Authentication Success
indicates that the authentication event was successful;
Authentication Failure
indicates that the attempt failed.
Authentication Description
—If the authentication attempt failed, additional information about the type of failure.
For example,
user not allowed
indicates that the user or group is not allowed to use Kerberos to authenticate, possible because it was not added to the
Allow List
in the authentication profile.