Configure Google as an IdP in the Cloud Identity Engine

If you use Google to authenticate users, you can configure your Google IdP as an authentication type in the Cloud Identity Engine.

The Cloud Identity Engine does not support the ForceAuthn attribute for Google as an IdP.

1. Prepare to configure Google as an IdP in the Cloud Identity Engine.
1. If you have not already done so,  activate  the Cloud Identity Engine app.
2. In the Cloud Identity Engine app, select  AuthenticationSP MetadataDownload SP Metadata  and  Save  the metadata in a secure location.

3. Log in to the Google Admin Console and select  AppsSAML Apps .

4. Select  Add AppAdd custom SAML app .

5. Enter an  App name  then  Continue  to the next step.
6. Click  Download Metadata  to  Download IdP metadata  then  Continue  to the next step.

7. Copy the metadata information from the Cloud Identity Engine and enter it in the Google Admin Console as described in the following table then  Continue  to the next step:

Copy from Cloud Identity Engine	Enter in Google Admin Console
Copy the  Entity ID  from the SP Metadata page.	Enter it as the  Entity ID .
Copy the  Assertion Consumer Service URL .	Enter the URL as the  ACS URL .

8. Add mapping  to select the  Google Directory attributes  then specify the corresponding  App attributes . Repeat for each attribute you want to use then click  Finish  when the changes are complete.

9. View details  to specify the users and groups you want to authenticate with Google and enable the app to turn it  ON for everyone  then  Save  your changes.

10. Select  DirectoryUsers  to specify the users you want to authenticate using Google.

2. Add Google as an authentication type in the Cloud Identity Engine app.
1. Select  Authentication Types  and click  Add New Authentication Type .

2. Set Up  a  SAML 2.0  authentication type.

3. Enter a  Profile Name .

4. Select  Google  as your  Identity Provider Vendor .
2. Select the method you want to use to  Add Metadata  and  Submit  the profile.

• If you want to enter the information manually, copy the identity provider ID and SSO URL, download the certificate, then enter the information in the Cloud Identity Engine.
1. In the Google Admin Console, select the Cloud Identity Engine app and  Download Metadata .

2. Click  Download Metadata  then copy the necessary information from Google and enter it in the Cloud Identity Engine app as indicated in the following table:

Copy or Download from Google Admin Console	Enter in Cloud Identity Engine IdP Profile
Copy the  Entity ID .	Enter it as the  Identity Provider ID .
Download  the  Certificate .	Click to Upload  the certificate from Google.
Copy the  SSO URL .	Enter the URL as the  Identity Provider SSO URL .

3. 
• If you want to upload a metadata file, download the metadata file from your IdP management system.
1. In the Google Admin Console, select the Cloud Identity Engine app and  Download Metadata .
2. Click  Download Metadata  and  Save  the file to a secure location.
3. In the Cloud Identity Engine app, select  Upload Metadata  then click  Browse files  to select the metadata file then  Open  the metadata file.

• To use the  Get URL  method, copy the URL from your IdP and enter it in Cloud Identity Engine.
1. Log in to the Google portal using your administrator credentials.
2. Select  AppsWeb and mobile apps .

3. Select the Google app you created in step 

1.d

.

4. Click  Download Metadata .

5. Copy the  SSO URL  and store it in a secure location.

6. In the Cloud Identity Engine, select  Get URL  and paste the URL as the  Identity Provider Metadata URL .

7. Click  Get URL  to confirm the URL and populate the  Identity Provider ID  and  Identity Provider SSO URL .

• If you don't want to enter the configuration information now, you can  Do it later . This option allows you to submit the profile without including configuration information. However, you must edit the profile to include the configuration information to use the authentication type in an authentication profile.

4. Select the  HTTP Binding for SSO Request to IdP  method you want to use for the SAML binding that allows the firewall and IdP to exchange request and response messages:

• HTTP Redirect —Transmit SAML messages through URL parameters.
• HTTP Post —Transmit SAML messages using base64-encoded HTML.

5. Specify the  Maximum Clock Skew (seconds) , which is the allowed difference in seconds between the system times of the IdP and the firewall at the moment when the firewall validates IdP messages (default is 60; range is 1–900). If the difference exceeds this value, authentication fails.
6. To require users to log in using their credentials to reconnect to GlobalProtect, enable  Force Authentication .

7. Test SAML setup  to verify the profile configuration.

This step is necessary to confirm that your firewall and IdP can communicate.

8. Select the SAML attributes you want the firewall to use for authentication and  Submit  the IdP profile.

Select the  Username Attribute  and optionally, the  Usergroup Attribute ,  Access Domain ,  User Domain , and  Admin Role .

Configure a SAML 2.0-Compliant IdP in the Cloud Identity Engine

To use a SAML 2.0-compliant identity provider (IdP) that is not listed as an  Identity Provider Vendor , you can configure the IdP using the  Others

1. Obtain the information from your SAML 2.0-compliant IdP that you need to configure in the Cloud Identity Engine.
1. Copy the following information from your IdP:
• Identity Provider ID
• Identity Provider Certificate
• Identity Provider SSO URL
2. In the Cloud Identity Engine app, select  AuthenticationSP MetadataDownload SP Metadata  and  Save  the metadata in a secure location.

2. Configure the IdP in the Cloud Identity Engine.
1. Select  Authentication Types  and click  Add New Authentication Type .

2. Set Up  a  SAML 2.0  authentication type.

3. Enter a  Profile Name .

4. Select  Others  as your  Identity Provider Vendor .
2. Select the method you want to use to  Add Metadata .

• If you want to enter the information manually, obtain the necessary information from your IdP then enter the information in the Cloud Identity Engine.

1.                   Copy or download the following information from your IdP and enter it in the Cloud Identity Engine app:

• Identity Provider ID
• Identity Provider Certificate
• Identity Provider SSO URL

2.                   Select the  HTTP Binding for SSO Request to IdP  method you want to use for the SAML binding that allows the firewall and IdP to exchange request and response messages:

• HTTP Redirect —Transmit SAML messages through URL parameters.
• HTTP Post —Transmit SAML messages using base64-encoded HTML.

• If you want to upload a metadata file, download the metadata file from your IdP management system.

1.                   Download the metadata from your IdP.

2.                   In the Cloud Identity Engine app, click  Browse files  to select the metadata file then  Open  the metadata file.

• If you want to use a URL to retrieve the metadata, copy the URL from your IdP. Enter it as the  Identity Provider Metadata URL  in the Cloud Identity Engine and click  Get URL  to obtain the metadata.
• If you don't want to enter the configuration information now, you can  Do it later . This option allows you to submit the profile without including configuration information. However, you must edit the profile to include the configuration information to use the authentication type in an authentication profile.

4. Specify the  Maximum Clock Skew (seconds) , which is the allowed difference in seconds between the system times of the IdP and the firewall at the moment when the firewall validates IdP messages (default is 60; range is 1–900). If the difference exceeds this value, authentication fails.
5. To require users to log in using their credentials to reconnect to GlobalProtect, enable  Force Authentication .
6. Test SAML setup  to verify the profile configuration.

This step is necessary to confirm that your firewall and IdP can communicate.

7. Select the SAML attributes you want the firewall to use for authentication and  Submit  the IdP profile.
1. In the IdP, edit as necessary the attributes you want to use to authenticate users.
2. In the Cloud Identity Engine app, select the  Username Attribute  and optionally, the  Usergroup Attribute ,  Access Domain ,  User Domain , and  Admin Role .

Configure a Client Certificate

To use a client certificate to authenticate users, configure a certificate authority (CA) and client certificate.

1. Configure a Certificate Authority (CA) chain to authenticate users.

Upload the CA chain, including the root certificate and any intermediate certificates, that issues the client certificate. The Cloud Identity Engine supports multiple intermediate certificates but does not support sibling intermediate certificates in a single CA chain.

1. In the Cloud Identity Engine app, select  AuthenticationCA ChainsAdd CA Chain .

2. Enter the necessary information for the CA chain profile.

• CA Name —Enter a unique name to identify the CA chain in the Cloud Identity Engine tenant.
• Upload Certificate — Drag and drop file(s) here  or  Browse files  to your CA certificate then  Open  the certificate to select it.

The file must end in the  .crt  or  .pem  file extension.

• Certificate Revocation List Endpoint (Optional) —(Optional but recommended) Specify the URL for the certificate revocation list (CRL) list that you want the Cloud Identity Engine to use to validate the client certificate.
2. Submit  the changes to complete the configuration.
1. In the Cloud Identity Engine app, select  AuthenticationAuthentication TypesAdd New Authentication Type .

3. Select  Client CertificateSet Up .

4. Enter a unique  Authentication Type Name  for the client certificate.
5. Select the  Username Field  that you want the Cloud Identity Engine to use to authenticate users.

Select the  Username Field  based on the attribute type of the client certificate that you want to use to authenticate the user; for example, if the username is defined in the client certificate using  Subject , select  Subject .

6. Configure the  Username Attribute  based on the previous step and the attribute that your client certificate uses to authenticate users.

• If the Username Field is  Subject , the Username Attribute is  CN .
• If the Username Field is  Subject Alt Name , select  Email  or  User Principal Name  based on the attribute that your client certificate specifies.

7. Click  Add CA Chain  to add one or more CA chains to authenticate users.

8. Enter a search term in the  Search CA Chain  field or select a CA chain you previously configured and  Add  it to the configuration.

The Cloud Identity Engine supports grouping multiple CA chains in a certificate type to authenticate client certificates issued by multiple CA chains.

9. Submit  your changes to configure the authentication type.

Configure an OIDC Authentication Type

OpenID Connect (OIDC) provides additional flexibility for your Cloud Identity Engine deployment. By supporting single sign-on (SSO) across multiple applications, OIDC simplifies authentication for users, allowing them to log in once with the OIDC provider to access multiple resources without needing to log in repeatedly.

The OIDC authentication type supports the Prisma® Access Browser. It does not support GlobalProtect™ or Authentication Portal.

To configure an OpenID Connect (OIDC) provider as an authentication type in the Cloud Identity Engine, complete the following steps for your identity provider (IdP) type.

• Configure OIDC for Azure
• Configure OIDC for Okta
• Configure OIDC for PingOne
• Configure OIDC for Google

When you configure OIDC as an authentication type, the Cloud Identity Engine determines the username attribute using the following order (where if the current attribute isn’t found, the Cloud Identity Engine attempts to match using the next attribute in the list):

1. email
2. preferred_username
3. username
4. sub

Configure OIDC for Azure

1. Set up OIDC as an authentication type in the Cloud Identity Engine.
1. Select  AuthenticationAuthentication TypesAdd New Authentication Type .
2. Set Up  the OIDC authentication type.

3. Enter a unique and descriptive  Authentication Type Name  for your OIDC configuration.

4. Copy the  Callback URL/ Redirect URL .

5. Select the  JWT Encryption Algorithm  that you want to use.

The default value is  RS256, default for most Identity Providers .

2. Configure Azure to use OIDC with the Cloud Identity Engine.
1. Log in to the Azure account you want to use to connect to the Cloud Identity Engine.

2. Click  App registration .

3. Click  New registration .

4. Enter a  Name  for the application.

5. Select  Accounts in this organizational directory only .

6. For the  Redirect URI , enter the domain for your Cloud Identity Engine instance and append  oidc/callback

7. Click  Register  to submit the configuration.

8. Click  Add user/group  and add the users or groups you want to be able to configure OIDC as an authentication type (for example, service accounts).

3. Obtain the information you need to complete your OIDC Azure configuration.
1. Select the application you just created then click  Overview .
2. Copy the  Display name  and  Application (client) ID  and save them in a secure location.

3. Click  Add a certificate or secret .

Don’t allow the client secret to expire. If the client secret isn’t up to date, users can’t log in using OIDC.

4. Select  Client secrets  then click  New client secret .

Don’t allow the client secret to expire. If the client secret isn’t up to date, users can’t log in using OIDC.

5. Select when the secret  Expires  then click  Add .

Don’t allow the client secret to expire. If the client secret isn’t up to date, users can’t log in using OIDC.

6. Copy  the  Value  of the client secret and save them in a secure location.

Because the secret displays only once, be sure to copy the information before closing or leaving the page. Otherwise, you must create a new secret.

Don’t allow the client secret to expire. If the client secret isn’t up to date, users can’t log in using OIDC.

7. (Optional) Select  OverviewEndpoints  and  Copy  the  OpenID Connect metadata document  up to  /2.0  (the  well-known/openid-configuration  section of the URL isn't necessary).

4. Complete and submit the OIDC configuration.
1. Enter the  Display name  you copied from Azure in step 

3.2

 as the  Client Name .

2. Enter the  Client ID  you copied from Azure in step 

3.6

.

3. Enter the  Value  you copied from Azure in step 

3.7

 as the  Client Secret .

4. Enter  https://login.microsoftonline.com/organizations/2.0/  as the  Issuer URL .

5. (Optional) Enter the  Endpoint URL  you copied in step 

3.7

.

6. Click  Test Connection  and log in to confirm that the Cloud Identity Engine can reach your Azure IdP using OIDC.

If you did not enter the OIDC Issuer URL in the previous step, the Cloud Identity Engine automatically populates the information.

7. After confirming that the connection is successful,  Submit  the configuration.

You can now use OIDC as an authentication type when you  Set Up an Authentication Profile .

Configure OIDC for Okta

1. Set up OIDC as an authentication type in the Cloud Identity Engine.
1. Select  AuthenticationAuthentication TypesAdd New Authentication Type .
2. Set Up  the OIDC authentication type.

3. Enter a unique and descriptive  Authentication Type Name  for your OIDC configuration.

4. Copy the  Callback URL/ Redirect URL .

2. Configure Okta to use OIDC with the Cloud Identity Engine.
1. Sign in  to Okta.

2. Select  ApplicationsApplications .

3. Click  Create App Integration .

4. Select  OIDC - OpenID Connect  as the  Sign-in method  and  Web Application  as the  Application Type  then click  Next .

5. Enter an  App integration name .

6. Click  Add URI  and enter the information you copied in step 

1.4

.

7. Select the  Controlled Access  you want to allow then click  Save .

3. Obtain the information you need to complete your OIDC Okta configuration.
1. Copy  the  Client ID .

2. Copy  the  Secret .

The secret for Okta does not expire.

4. Complete and submit the OIDC configuration.
1. Enter the  App integration name  you entered in Okta in step 

2.5

 as the  Client Name .

2. Enter the  Client ID  you copied from Okta in step 

3.1

.

3. Enter the  Secret  you copied from Okta in step 

3.2

 as the  Client Secret .

4. Enter the domain name URL for your Okta IdP as the  Issuer URL .

5. (Optional) If you have your  Endpoint URL , enter it here. If not, continue to the next step (the Cloud Identity Engine populates the  Endpoint URL  automatically after you successfully test the connection).

6. Click  Test Connection  and log in to confirm that the Cloud Identity Engine can reach your Okta IdP using OIDC.

If you did not enter the OIDC Issuer URL in the previous step, the Cloud Identity Engine automatically populates the information.

7. After confirming that the connection is successful,  Submit  the configuration.

You can now use OIDC as an authentication type when you  Set Up an Authentication Profile .

Configure OIDC for PingOne

1. Set up OIDC as an authentication type in the Cloud Identity Engine.
1. Select  AuthenticationAuthentication TypesAdd New Authentication Type .
2. Set Up  the OIDC authentication type.

3. Enter a unique and descriptive  Authentication Type Name  for your OIDC configuration.

4. Copy the  Callback URL/ Redirect URL .

2. Configure PingOne to use OIDC with the Cloud Identity Engine.
1. Sign On  to your PingOne account.

2. Select  Applications .

3. Select  OIDC  then click  Add Application .

4. Select  Web App  then click  Next .

5. Enter an  Application Name , a  Short Description  for the app, and select the app  Category , then click  Next .

3. Continue the OIDC Okta configuration.
1. Click  Add Secret  then click  Next .

2. Enter the  Start SSO URL  and the  Redirect URIs  then click  Next .

3. Click  Next .

No configuration changes are necessary for this step.

4. Add all the scopes in the  List of Scopes  to the  Connected Scopes  then click  Next .

5. Select  Email (Work)  as the  sub  attribute then click  Next .

6. Select all the  Available Groups  and add them to the  Added Groups  then click  Done .

4. Obtain the information you need to complete your OIDC PingOne configuration and enter it in your Cloud Identity Engine configuration.
1. Copy the following information from your configuration and save it in a secure location:
• The  Application Name  you entered in step 

2.5

.

• The  Client ID  and  Client Secrets  you added in step 

3.1

.

Don’t allow the client secret to expire. If the client secret isn’t up to date, users can’t log in using OIDC.

• The  Issuer  URL (as shown below).

2. Enter the  Application Name  you entered in PingOne in step 

2.5

 as the  Client Name .

3. Enter the  Client ID  you created in PingOne in step 

3.1

.

4. Enter the  Client Secrets  you created in PingOne in step 

3.1

 as the  Client Secret .

5. Enter the  Issuer  URL for your PingOne IdP that you copied in step 

4.1

 as the  Issuer URL .

6. (Optional) If you have your  Endpoint URL , enter it here. If not, continue to the next step (the Cloud Identity Engine populates the  Endpoint URL  automatically after you successfully test the connection).

7. Click  Test Connection  and log in to confirm that the Cloud Identity Engine can reach your PingOne IdP using OIDC.

If you did not enter the OIDC Issuer URL in the previous step, the Cloud Identity Engine automatically populates the information.

8. After confirming that the connection is successful,  Submit  the configuration.

You can now use OIDC as an authentication type when you  Set Up an Authentication Profile .

Configure OIDC for Google

1. Set up OIDC as an authentication type in the Cloud Identity Engine.
1. Select  AuthenticationAuthentication TypesAdd New Authentication Type .
2. Set Up  the OIDC authentication type.

3. Enter a unique and descriptive  Authentication Type Name  for your OIDC configuration.

4. Copy the  Callback URL/ Redirect URL .

2. Configure Google to use OIDC with the Cloud Identity Engine.
1. Select your account and  Enter your password  then click  Next .

2. Create  a new project or select an existing project.
3. Enable the  Identity and Access Management (IAM)  API (if it's not already enabled).
4. Select  APIs & ServicesOAuth consent screen  then  configure  the OAuth consent screen.
5. Create  your OAuth 2.0 credentials, copy the  Client ID  and  Client Secret , and store them in a secure location.

Don’t allow the client secret to expire. If the client secret isn’t up to date, users can’t log in using OIDC.

3. Obtain the information you need to complete your OIDC Google configuration and enter it in your Cloud Identity Engine configuration.
1. Copy the following information from your configuration and save it in a secure location:
• The  Name  you entered in step 

2.4

.

• The  Client ID  and  Client secret  you copied in step 

2.5

 (if you did not do so in the previous step).

• The  Authorized redirect URIs  you copied in step 

1.4

.

2. 
3. Enter the application name you entered in step 

2.4

 as the  Client Name .

4. Enter the  Client ID  you copied in step 

2.5

.

5. Enter the  Client Secret  you copied in step 

2.5

.

6. Enter the  Authorized redirect URIs  that you copied in step 

1.4

 as the  Issuer URL .

7. (Optional) If you have your  Endpoint URL , enter it here. If not, continue to the next step (the Cloud Identity Engine populates the  Endpoint URL  automatically after you successfully test the connection).

8. Click  Test Connection  and log in to confirm that the Cloud Identity Engine can reach your Google IdP using OIDC.

If you did not enter the OIDC Issuer URL in the previous step, the Cloud Identity Engine automatically populates the information.

9. After confirming that the connection is successful,  Submit  the configuration.

You can now use OIDC as an authentication type when you  Set Up an Authentication Profile .

Set Up an Authentication Profile

Configure an authentication profile to use to authenticate users with the Cloud Identity Engine. You can specify one or more authentication types by group or by directory or for all directories.

To use more than one authentication type in your authentication profile, you must  configure a directory  in the Cloud Identity Engine. For a single client certificate authentication type, configuring a directory in the Cloud Identity Engine is optional. There is no directory requirement for a single SAML 2.0-compliant authentication type.

1. Select  AuthenticationAuthentication Profiles  then  Add Authentication Profile .

2. If you have not already done so,  Configure a SAML 2.0 Authentication Type  or  Configure a Client Certificate  to use as an authentication type.
3. Enter a unique  Profile Name .
4. Select the  Authentication Mode .

• If you select  Single  as the authentication mode, click  Select authentication type  and select the authentication type you want to use.

• If either of the following apply to your configuration, select the  Directory Sync Username Attribute  and  Directory Sync Group Attribute .
• You selected  Multiple  as the Authentication Mode and you have configured a client certificate.
• You selected  Single  and the Authentication Type is Client Certificate.

To successfully authenticate users using a client certificate, the value of the  Directory Sync Username Attribute  must match the value of the  Username Attribute  you select when you configure the Client Certificate Authentication Type.

5. (Multiple Authentication Mode only) Define the  Authentication mapping order  by selecting the configured authentication types that you want to use to authenticate users.

6. (Multiple Authentication Mode only) During authentication, the Cloud Identity Engine uses the given user identity information to obtain the directory group information for the user to determine if the user’s group has an assigned authentication type. If the user belongs to multiple groups, the Cloud Identity Engine uses the first authentication type you assign to the group for user authentication.

7. Select the  Default authentication type  that you want the Cloud Identity Engine to use to authenticate users if the user is not in an assigned group.

As a best practice, assign an authentication type for each group you want to authenticate using the Cloud Identity Engine.

8. Choose directories and groups  by selecting a directory or selecting  All Directories .

You can also search by  Directory Sync Group Attribute  (such as  Common-Name ).

9. Select the group or groups from each directory that you want to authenticate using the authentication type you select in the next step.

10. Select an authentication type  and  Assign  it to assign this authentication type to the group or groups you selected.

11. Review your selections by authentication type or select  All Authentication Types  to see all assigned groups.

12. Submit  your changes to configure the authentication profile.

Configure Cloud Identity Engine Authentication on the Firewall or Panorama

After you  Configure the Cloud Identity Engine as a Mapping Source on the Firewall or Panorama  and  Configure a SAML 2.0 Authentication Type ,  Configure a Client Certificate , or both, you can create an authentication profile that redirects users to the authentication type (either a client certificate or a SAML 2.0-compliant identity provider) you configure for authentication.

If you use Panorama to manage your firewalls, configure an authentication profile in Panorama then push the authentication profile to the managed firewalls.

Some steps in the following procedure are required only if you want to configure an authentication policy rule on the firewall using the Cloud Identity Engine and aren’t required if you want to authenticate administrators or to authenticate users with Prisma Access or GlobalProtect. These steps are indicated below.

1. Configure an authentication profile to use the Cloud Authentication Service.
1. On the firewall, select  DeviceAuthentication Profile .

2. Enter a  Name  for the authentication profile.
3. Select  Cloud Authentication Service  as the  Type .
4. Select the  Region  of your Cloud Identity Engine tenant.

For more information on regions, refer to  Activate the Cloud Identity Engine .

5. Select the Cloud Identity Engine  Instance  you want to use for this authentication profile.

For more information on Cloud Identity Engine tenants, refer to  Cloud Identity Engine Tenants .

6. Select an authentication  Profile  that specifies the authentication type you want to use to authenticate users.
7. Specify the  Maximum Clock Skew (seconds) , which is the allowed difference in seconds between the system times of the IdP and the firewall at the moment when the firewall validates IdP messages (default is 60; range is 1–900). If the difference exceeds this value, authentication fails.
8. Select  Force multi-factor authentication in cloud  if your IdP is configured to require users to log in using multi-factor authentication (MFA).
1. (Required for authentication policy rule only) Configure the Authentication Portal settings to use the authentication profile.
1. Select  DeviceUser IdentificationAuthentication Portal Settings .
2. Edit  the settings and select the  Authentication Profile  from the first step.
3. Select  Redirect  as the  Mode .

For more information on how to configure redirect mode, refer to  Configure Authentication Portal .

4. Click  OK .
2. (Required for authentication policy rule only) Create an Authentication Enforcement object that uses the authentication profile to redirect users to log in using their authentication type.
1. Select  ObjectsAuthentication .
2. Add  an Authentication Enforcement object and enter a  Name  for the object.
3. Select  web-form  as the  Authentication Method .
4. Select the  Authentication Profile  from the first step.
5. (Optional) Enter a  Message  to display to users.
6. Click  OK .
3. Create a URL list as a  custom URL category  to allow the necessary traffic for the Cloud Identity Engine.
1. If you don’t need to strictly limit traffic to your region, you can enter  *.apps.paloaltonetworks.com . Otherwise, determine your region-based URL using the show cloud-auth-service-regions command to display the URLs for the region associated with your Cloud Identity Engine tenant and enter each region-based URL. The following table includes the URLs for each region:

Region	Cloud Identity Engine Region-Based URL
United States	cloud-auth.us.apps.paloaltonetworks.com cloud-auth-service.us.apps.paloaltonetworks.com
Europe	cloud-auth.nl.apps.paloaltonetworks.com cloud-auth-service.nl.apps.paloaltonetworks.com
United Kingdom	cloud-auth.uk.apps.paloaltonetworks.com cloud-auth-service.uk.apps.paloaltonetworks.com
Singapore	cloud-auth.sg.apps.paloaltonetworks.com cloud-auth-service.sg.apps.paloaltonetworks.com
Canada	cloud-auth.ca.apps.paloaltonetworks.com cloud-auth-service.ca.apps.paloaltonetworks.com
Japan	cloud-auth.jp.apps.paloaltonetworks.com cloud-auth-service.jp.apps.paloaltonetworks.com
Australia	cloud-auth.au.apps.paloaltonetworks.com cloud-auth-service.au.apps.paloaltonetworks.com
Germany	cloud-auth.de.apps.paloaltonetworks.com cloud-auth-service.de.apps.paloaltonetworks.com
United States - Government	cloud-auth-service.gov.apps.paloaltonetworks.com cloud-auth.gov.apps.paloaltonetworks.com
India	cloud-auth-service.in.apps.paloaltonetworks.com cloud-auth.in.apps.paloaltonetworks.com
Switzerland	cloud-auth-service.ch.apps.paloaltonetworks.com cloud-auth.ch.apps.paloaltonetworks.com
Spain	cloud-auth-service.es.apps.paloaltonetworks.com cloud-auth.es.apps.paloaltonetworks.com
Italy	cloud-auth-service.it.apps.paloaltonetworks.com cloud-auth.it.apps.paloaltonetworks.com
France	cloud-auth-service.fr.apps.paloaltonetworks.com cloud-auth.fr.apps.paloaltonetworks.com
China	cloud-auth-service.cn.apps.prismaaccess.cn cloud-auth.cn.apps.prismaaccess.cn This region is only accessible in the Cloud Identity Engine within the specified region.
Poland	cloud-auth-service.pl.apps.paloaltonetworks.com cloud-auth.pl.apps.paloaltonetworks.com
Qatar	cloud-auth-service.qa.apps.paloaltonetworks.com cloud-auth.qa.apps.paloaltonetworks.com
Taiwan	cloud-auth-service.tw.apps.paloaltonetworks.com cloud-auth.tw.apps.paloaltonetworks.com
Israel	cloud-auth-service.il.apps.paloaltonetworks.com cloud-auth.il.apps.paloaltonetworks.com
Indonesia	cloud-auth-service.id.apps.paloaltonetworks.com cloud-auth.id.apps.paloaltonetworks.com
South Korea	cloud-auth-service.kr.apps.paloaltonetworks.com cloud-auth.kr.apps.paloaltonetworks.com
Saudi Arabia	cloud-auth-service.sa.apps.paloaltonetworks.com cloud-auth.sa.apps.paloaltonetworks.com

2. Enter the URLs that your IdP requires for user authentication (for example,  *.okta.com ).
4. Create a  security policy rule  to allow traffic to the authentication type and Cloud Identity Engine and select the custom URL category as the match criteria.
5. Create a  internet management profile  in the trusted zone and enable response pages.
6. (Required for authentication policy rule only) Configure an  Authentication policy rule  to use the Authentication Enforcement object and allow traffic to the custom URL category.
7. ( Panorama only ) If you use Panorama to manage multiple firewalls, configure the Cloud Identity Engine for Panorama.
1. Select the Cloud Identity Engine authentication method you want to use with Panorama.
• To configure the Cloud Identity Engine in an authentication profile for managed devices, select  DeviceAuthentication Profile .
• To use the Cloud Identity Engine in an authentication profile for Panorama administrators, select  PanoramaAuthentication Profile .
2. Select  PanoramaSetupManagement  and  Edit  the  Authentication Settings , then select the  Authentication Profile  for the Cloud Identity Engine tenant you want to associate with Panorama.
3. Select  PanoramaDevice Groups  and  Add  or  Edit a device group.
4. Select the  Cloud Identity Engine  and  Add  the Cloud Identity Engine tenant you want to associate with Panorama then click  OK .
8. Commit  your changes and verify that the firewall redirects authentication requests to the Cloud Authentication Service.
1. On the client device, use the browser to access a webpage that requires authentication.
2. Confirm that the access request redirects to the Cloud Authentication Service.
3. Enter your credentials to log in.

Configure the Cloud Identity Engine as a Mapping Source on the Firewall or Panorama

When you configure the Cloud Identity Engine as a User-ID source, the firewall or Panorama retrieves the group mapping information from the Cloud Identity Engine. You can then use the group information from the Cloud Identity Engine to create and enforce group-based security policy rules.

If your tenant contains an Okta directory that uses subdomains, enter the following CLI command on the firewall before configuring the Cloud Identity Engine profile: debug user-id dscd subdomains on. This command is disabled by default. To disable the subdomain capability, use the debug user-id dscd subdomains off CLI command. These commands are supported for PAN-OS version 10.2.9.

The Cloud Identity Engine retrieves the information for your tenant based on your device certificate. It also uses the Palo Alto Networks Services  service route , so make sure to allow traffic for this service route or  configure a custom service route .

To ensure that the Cloud Identity Engine can successfully retrieve users and groups, all user or group names must meet the following requirements: the name is case-sensitive and can have up to 63 characters on the firewall or up to 31 characters on Panorama. It must be unique and use only letters, numbers, hyphens, and underscores.

1. On the firewall, select  DeviceUser IdentificationCloud Identity Engine  and  Add  a profile.

On Panorama, to configure the Cloud Identity Engine as a User-ID source for managed devices, select  DeviceUser IdentificationCloud Identity Engine . To configure the Cloud Identity Engine as a User-ID source for Panorama administrators, select  PanoramaUser IdentificationCloud Identity Engine .

2. For the  Instance , specify each of the following:
• Region —Select the regional endpoint for your tenant.

The region you select must match the region you select when you  activate  your Cloud Identity Engine tenant.

• Cloud Identity Engine Instance —If you have more than one tenant, select the tenant you want to use.
• Domain —Select the domain that contains the directories you want to use.

If you have enabled subdomain retrieval for Okta, select the subdomain you want to use for this profile.

• Update Interval (min) —Enter the number of minutes that you want the firewall to wait between updates from the Cloud Identity Engine app to the firewall (also known as a refresh interval). The default is 60 minutes and the range is 5—1440.

3. Verify that the profile is  Enabled .

4. For the  User Attributes , select the format for the  Primary Username . You can optionally select the formats for the  E-Mail  and an  Alternate Username . You can configure up to three alternate username formats if your users log in using multiple username formats.

5. For the  Group Attributes , select the format for the  Group Name .

6. For the  Device Attributes , select the  Endpoint Serial Number .

If you are using GlobalProtect and you have enabled Serial Number Check, select the Endpoint Serial Number option to allow the Cloud Identity Engine to collect serial numbers from managed endpoints. This information is used by the GlobalProtect portal to check if the serial number exists in the directory for verification that the endpoint is managed by GlobalProtect.

7. Click  OK  then  Commit  your changes.
8. Configure  security policy rules  for your users (for example, by specifying one or more users or groups that the firewall retrieves from the Cloud Identity Engine as the  Source User ).

The firewall collects attributes only for the users and groups that you use in security policy rules, not all users and groups in the directory.

9. Verify that the firewall has the mapping information from the Cloud Identity Engine.

1.                   On the client device, use the browser to access a web page that requires authentication.

2.                   Enter your credentials to log in.

3.                   On the firewall, use the show user ip-user-mapping all command to verify that the mapping information is available to the firewall.

Configure Dynamic Privilege Access in the Cloud Identity Engine

Enabling Dynamic Privilege Access (DPA) allows you to isolate network resources so they are only accessible to users on a per-project basis.

Contact your Palo Alto Networks account representative to activate this functionality.

Complete the following steps to enable and configure DPA in the Cloud Identity Engine. For more information, refer to the  Prisma Access documentation . The  Prisma Access release notes  have information on known issues for DPA.

Syncing new user groups for SAML applications in Azure may require up to 3 hours for the Cloud Identity Engine to complete the sync. Wait until the sync is complete before assigning projects to the new group.

1. Configure an authentication type in the Cloud Identity Engine.

The authentication type you configure in the Cloud Identity Engine is only for use with DPA authentication; don't use the same authentication type you use for DPA for another authentication type.

1. In the Cloud Identity Engine, select  Authentication TypesAdd New Authentication Type .

The Cloud Identity Engine supports Azure Active Directory (Azure AD) in this release. To use an existing Azure IdP configuration, select  Authentication TypesActionsEdit .

2. If you  Set Up  a new  SAML 2.0  authentication type,  configure  Azure as the identity provider (IdP) in a new configuration.

If you edit the configuration for an existing Azure IdP authentication type,  synchronize all attributes  for the directory (also known as a full sync) after editing and submitting the configuration.

3. Select  Dynamic service provider metadata  as the  Metadata Type .

2. Copy and save the information from the Cloud Identity Engine that you must configure in your identity provider.

Select one of the following methods to obtain the information you need to configure for the Cloud Identity Engine to communicate with your identity provider:

• Copy the  Entity ID  and the  Assertion Consumer Service URL , then save them in a secure location.

Don't edit the Entity ID or use the Entity ID for other applications. You don't need to download the SP metadata if you use the Entity ID.

• Click  Download SP Metadata  and save the metadata in a secure location. For more information, refer to the first step in the procedure for  configuring Azure as an IdP  in the Cloud Identity Engine.

This step is mandatory for successful DPA configuration using SP metadata, even if you edit an existing Azure IdP configuration. The SP metadata provides the Entity ID, the Reply URL (Assertion Customer Service URL) and the Logout URL; you must manually enter the Sign on URL.

If you want to configure the authentication type so you can obtain the necessary information and you don't want to enter the metadata now, you can choose to  Do It Later . This option allows you to generate the data you need to enter in the IdP for the next steps; however, you must enter the metadata before submitting the configuration to successfully use the authentication type with the Cloud Identity Engine.

3. In the IdP administrator portal, download the SAML application for the Cloud Identity Engine from the gallery.
1. Log in to the Azure Portal and select  Enterprise Applications .

2. Search for the  Palo Alto Networks Cloud Identity Engine - Cloud Authentication Service  gallery application and select it.

3. (Optional) Edit the application  Name .
4. Create  the configuration.

5. For  Set up single sign-on , click  Get started .

4. Depending on the method you used in step 

2

, complete the necessary steps to configure the SAML application.

• If you copied the Entity ID and Assertion Consumer Service URL:
1. Edit  the  Basic SAML Configuration  you created.

2. Click  Add identifier  and paste the  Entity ID  you copied from the Cloud Identity Engine.

3. Click  Add reply URL  and paste the  Assertion Consumer Service URL  you copied from the Cloud Identity Engine.

4. Enter your regional endpoint as the  Sign on URL  using the following format:  https://<RegionUrl>.paloaltonetworks.com/sp/acs  (where <RegionUrl> is your regional endpoint). For more information on regional endpoints, see  Configure Cloud Identity Engine Authentication on the Firewall or Panorama .
5. Save  your configuration.
6. Close  the window and  Copy  the  App Federation Metadata URL .
• If you downloaded the SP metadata:
1. Click  Upload metadata file  to upload the SP metadata file from the Cloud Identity Engine.

2. Browse  to the SP metadata file you downloaded from the Cloud Identity Engine.
3. Add  the file.
4. Edit  the  Basic SAML Configuration  you created.

5. Enter your regional endpoint as the  Sign on URL  using the following format:  https://<RegionUrl>.paloaltonetworks.com/sp/acs  (where <RegionUrl> is your regional endpoint). For more information on regional endpoints, see  Configure Cloud Identity Engine Authentication on the Firewall or Panorama .
6. Save  your configuration.
7. Close  the window and  Copy  the  App Federation Metadata URL .

5. Assign your account to the application and save the configuration.
1. Assign your account to ensure your access to the application and to any other users you want to authenticate using the SAML application. For more information, refer to step 3 in  configuring Azure as an IdP .
2. Save  the configuration.
6. Continue the IdP configuration in the Cloud Identity Engine.
1. Enter the remaining information to  configure your identity provider  (refer to step 5).
2. In the Cloud Identity Engine, enter the  App Federation Metadata URL  you copied as the  Identity Provider Metadata URL  .
3. Click  Get URL  to confirm the Cloud Identity Engine can connect to the URL.

This step is mandatory to confirm the configuration. If you don't click  Get URL  before clicking  Test SAML Setup , the test isn't successful.

4. Select whether  Multi-factor Authentication is Enabled on the Identity Provider  and whether you want to  Force Authentication .

Refer to steps 6-7 in  Configure Azure as an IdP in the Cloud Identity Engine  for more information.

7. Configure the SAML attributes for the Cloud Identity Engine to use for authentication.
1. Click  Test SAML Setup  to verify the configuration.
2. Select the  Username Attribute  for the Cloud Identity Engine to use for authentication.

Select the username attribute that uses the  Name  ( /identity/claims/name: ) format. If you do not select the correct username attribute, user authentication for projects is not successful. For more information, refer to the  Microsoft documentation .

3. (Optional) Select other attributes to use for authentication, such as  Usergroup Attribute ,  Access Domain ,  User Domain , and  Admin Role .
7. If you have not already done so,  Collect enterprise applications  data from your  Azure directory .  Sign in  to confirm the changes and  Submit  the update to the configuration.

The Cloud Identity Engine begins a complete synchronization of the attributes (also known as a  full sync ) when you submit the configuration. Wait until the sync is complete before continuing.

This step is mandatory to complete the configuration regardless of whether you're creating a new configuration or editing an existing configuration. You must complete this step before enabling Dynamic Privilege Access in the Cloud Identity Engine.

9. Enable Dynamic Privilege Access in the Cloud Identity Engine authentication profile.
1. Select  Enable Dynamic Privilege Access .
2. Click  Detect Directory and SAML  to allow the Cloud Identity Engine to detect available directories and SAML attributes.

When the Cloud Identity Engine completes the collection of the attributes, the  Directory  and  SAML 2.0 Application  information displays.

If the Cloud Identity Engine can't detect the SAML application, complete a  full sync  then reattempt this step.

3. After confirming the information is correct,  Submit  the configuration.
9. Configure an  authentication profile  in the Cloud Identity Engine to use the authentication type you configured.

Configure Security Risk for the Cloud Identity Engine

Security Risk for the Cloud Identity Engine obtains specific information to evaluate risk (such as an outdated OS, failed password attempts, or suspicious device activity) for users and devices. By using telemetry and receiving risk scores for these sources, the Cloud Identity Engine allows you to define the risk criteria for a group, then the Cloud Identity Engine automatically assigns users and devices to that group using the information it receives from your risk assessment sources. This enables closed-loop automation, since after you address the source of the risk for a user or device, the Cloud Identity Engine removes it from the group.

Microsoft Azure analyzes user behavior and sign-in events to determine a user risk score and create a list of risky users. By identifying suspicious or anomalous user activity and assigning a risk score, you can quickly assess user risk level, evaluate priority, and take actions to reduce risk.

SentinelOne reviews all device activity (such as processes) on the endpoint to assign specific attributes that determine the risk level of the endpoint.

The SentinelOne Endpoint Detection and Response (EDR) agent monitors device activity and behavior. By specifying the attributes you want the agent to collect, you can identify at-risk device endpoints.

The bidirectional integration between Prisma Access and SentinelOne helps ensure your Zero Trust Security policy by continuously receiving device information and risk signals from SentinelOne and automatically enforcing access restrictions, such as quarantining the device.

You can also use the Strata Cloud Manager to view the list of devices currently in quarantine.

• If you want to obtain risk information about users, 

Configure Azure for Security Risk in the Cloud Identity Engine

.

• If you want to obtain security posture and risk information about devices, 

Configure SentinelOne for Security Risk in the Cloud Identity Engine

.

By continuously monitoring the device security posture and risk information from SentinelOne, updating and enforcing quarantine lists across all devices, and removing devices after remediation, Security Risk for the Cloud Identity Engine helps you enforce adaptive Security policy and just-in-time access.

1. In the Cloud Identity Engine, select  Security RiskRisk Sources .
2. Click  Add Risk Source .

3. Select the type of risk source you want to configure.

You can configure up to one Azure Active Directory source and up to one SentinelOne source.

The Cloud Identity Engine uses the risk source you configure to obtain risk information.

• Azure — Click  Connect  and  Configure a new Azure directory  or select an  Existing Directory  to obtain risk information about users.

If you configure Security Risk to use a directory and you want to remove the directory from the Cloud Identity Engine, you must first remove the directory from the Security Risk configuration.

• SentinelOne —Click  Connect  and continue to 

Configure SentinelOne for Security Risk in the Cloud Identity Engine

 as a risk source to obtain risk information about devices.

Configure Azure for Security Risk in the Cloud Identity Engine

1. View and optionally edit the dynamic risky user groups.
1. In the Cloud Identity Engine, select  Security RiskCloud Dynamic Groups .
2. Select the  Risky User Group  tab to view the groups that the Cloud Identity Engine creates to isolate users who it identifies as risky. You can optionally click the  Details  icon to view more information about the specific group.

3. (Optional) Search the groups by entering a search query then click  Apply Search .

You can specify a  Text Search  or a  Substring Search .

4. (Optional) To include additional  context and attributes  for the cloud dynamic risky user group, select  ActionsEdit , add the additional context and attributes, and  Submit  the changes.

5. (Optional) To delete a group, select  ActionsRemove  and click  Yes  to confirm removal of the group.

2. (Optional) Create a new cloud dynamic risky user group.
1. Click  Create New Risky User Group .

2. Select  Risky User  as the  Category .

3. Enter the  Common Name  you want to use for the dynamic risky user group.

4. (Optional) Enter a  Group Email  a  Description  for the group.

5. Select the  context and attributes  to use for the dynamic risky user group.

6. (Optional) To include additional context and attributes, click  Add OR  and optionally  Add AND  and select the context and attributes to use for the dynamic risky user group.

7. Submit  the configuration.

Configure SentinelOne for Security Risk in the Cloud Identity Engine

1. To configure SentinelOne as a risk source for Security Risk, collect the necessary information from your SentinelOne configuration.
1. Before logging in to SentinelOne, copy the URL without the  /login  part of the address and save it in a secure location.

2. Log in to SentinelOne and select  SettingsUsersService Users .
3. Click  ActionsCreate New Service User .

4. Enter a  Name  for the service user account and select the  Expiration Date  then click  Next .

5. Select Scope of Access  and click  Create User .

6. Enter the  Two-Factor Authentication Code  within the 30-minute duration and click  Confirm Action .

7. Click  Copy API Token  to copy the API token and save it in a secure location. Because the API token only displays once, ensure you copy the token before clicking the  Close  button.

8. (Optional but recommended) Click the  Site  button to confirm the creation of the site.

2. Configure SentinelOne as a risk source in the Cloud Identity Engine.
1. Enter the SentinelOne  Source Name .

The source name must use lowercase.

2. Paste the  Endpoint URL  you copied from SentinelOne in step 

1.a

.

3. Paste the  Authorization Method  API token you copied in step 

1.7

 and paste it in your SentinelOne configuration.

4. Click  Test Connection  to verify that the Cloud Identity Engine can communicate with your SentinelOne configuration.

5. After confirming that the Cloud Identity Engine can successfully communicate with your provider using your SentinelOne configuration,  Submit  the SentinelOne configuration.

3. View or edit the dynamic risky endpoint groups.
1. In the Cloud Identity Engine, select  Security RiskCloud Dynamic Groups .
2. Select the  Risky Endpoint Group  tab to view the groups that the Cloud Identity Engine creates to isolate endpoints that it identifies as risky. You can optionally click the  Details  icon to view more information about the specific endpoint group.

The Cloud Identity Engine creates a default group without any attributes; you must specify the attributes you want to use for the group (see step 

3.4

).

3. (Optional) Search the groups by entering a search query then click  Apply Search .

You can specify a  Text Search  or a  Substring Search .

4. Specify the  context and attributes  for the cloud dynamic risky endpoint group by selecting  ActionsEdit , adding the context and attributes, and clicking  Submit  to confirm the changes.

5. (Optional) To delete a group, select  ActionsRemove  and click  Yes  to confirm removal of the group.

The Cloud Identity Engine does not currently support creation of a dynamic risky endpoint group if there is an existing group.

4. Use Strata Cloud Manager to view the devices that have been  quarantined .

The Cloud Identity Engine places devices in quarantine using device security posture information and risk signals from SentinelOne. It removes devices from the quarantine list only when the device no longer meets any of the match criteria in the Cloud Identity Engine configuration. If a device is in quarantine due to SentinelOne information, Palo Alto Networks does not recommend manually removing the device from the quarantine list using Strata Cloud Manager or Panorama.

1. Log in to Strata Cloud Manager.
2. Select  ManageConfigurationNGFW and Prisma Access .
3. Select  Prisma Access  as the  Configuration Scope .

4. Select  ObjectsQuarantined Device List .

5. Review the devices in the quarantine list to determine what remediation actions to take.

Manage the Cloud Identity Agent

After you have installed and configured the agent, learn how to ensure you are using the latest agent version. If you need to perform maintenance, you can stop and restart the agent’s connection to your tenant. To help troubleshoot any issues, learn more about the events logged by the agent and how to use the logs.

Configure Cloud Identity Agent Logs

The Cloud Identity agent logs Cloud Identity Engine events that occur on the agent host. You can use these logs to monitor informational events such as new connections ( Information—New connection 192.0.2.0: 49161 ), or for troubleshooting ( Error—Verification of Server Cert failed, stopping Cloud Identity Agent ). For example, the agent automatically generates logs if you test connectivity when you  Configure the Cloud Identity Agent . You can also use the Event Viewer on the agent host to review logs created if the agent is unable to connect to the Cloud Identity Engine due to an incorrect bind DN or password, server unavailability, or other issue.

The agent displays logs in the order in which they were generated. To provide a consistent timestamp across timezones, logs include the timezone information in Coordinated Universal Time (UTC), where the time offset is indicated by + or -. For the complete log history, check the CloudIdAgentDebug log file on the agent host, which permanently retains all logs.

1. Launch the agent.
2. Select  FileDebug .
3. Select the type of event you want to log.

The agent logs the events of the selected type and all subsequent types. For example, if you select  Debug , the logs include error, warning, information, and debug events.

• If you select  None , the Cloud Identity agent does not log events at any level.
• If you select  Information ,  Warning , or  Error , the agent deletes the data from the log after sending it to the debug log on the agent host.
• If you select  Debug  or  Verbose , the received data is stored permanently on the disk until you delete the files.

To remove log files from the agent’s user interface, you can optionally  Clear Cloud Identity Agent Logs .

Search Cloud Identity Agent Logs

To troubleshoot issues with the Cloud Identity Engine, use keywords to search the Cloud Identity agent logs. For example, you could search for the IP address of a directory where the agent wasn’t able to connect to learn more about why the error occurred.

Search terms are case-sensitive.

1. From the Cloud Identity agent, select  Monitoring .
2. Enter the search terms in the entry field to the left of  Search .
3. Click  Search . The results are highlighted in blue below the entry field.

Clear Cloud Identity Agent Logs

You can clear outdated logs on the agent’s user interface. This does not delete the entries from the CloudIdAgentDebug log file on the agent host.

1. From the Cloud Identity agent, select  Monitoring .
2. Click  Clear Log .

Update the Cloud Identity Agent

Using the latest version of the agent is strongly recommended. If your Cloud Identity agent is not the latest version available, the Cloud Identity Engine app displays a notification.

Use the following procedure to update your Cloud Identity agent to the latest version.

When you upgrade the agent to version 1.7.0, it creates a backup of the existing agent configuration before removing the deprecated version of the agent. During installation of the new version of the agent, the existing configuration is automatically restored.

1. Stop  the connection to the Cloud Identity Engine service.

You must stop the connection between the agent and the service before you can update the agent. Check  Agents & Certificates  in the Cloud Identity Engine app to confirm the agent’s status.

2. Uninstall the outdated agent from the host ( StartControl PanelPrograms and FeaturesCloud Identity AgentUninstall ).

You must uninstall the outdated agent from the host before installing the latest version of the agent.

3. Log in to the  hub  and select the Cloud Identity Engine app.
4. Select your Cloud Identity Engine tenant (if you have more than one) then select  Agents & Certificate .
5. Click  Download New Agent , then  Install the Cloud Identity Agent .

Start or Stop the Connection to the Cloud Identity Engine

When you start the Cloud Identity agent, it automatically starts communicating with the Cloud Identity Engine to synchronize the attributes. To prevent this communication (for example, if a directory server is unavailable or if you want to  Remove the Cloud Identity Agent ), you can stop communication between the Cloud Identity agent and the Cloud Identity Engine. You can then restart the connection later to allow communication.

1. On the agent host, start the Cloud Identity agent if it is not already running, then select  Cloud Identity Configuration .

The current connection status of the agent displays at the lower-left corner of the window.

2. Stop or re-establish the connection between the agent and the service.
• To connect the agent to the Cloud Identity Engine, click  Start .

• To prevent the agent from communicating with the Cloud Identity Engine, click  Stop .

Remove the Cloud Identity Agent

If you no longer need a Cloud Identity agent, you can remove it from your Cloud Identity Engine tenant.

1. Stop  the connection to the Cloud Identity Engine.

You must stop the connection between the agent and the Cloud Identity Engine before you can remove the agent.

2. Uninstall the agent from the host server ( StartControl PanelPrograms and FeaturesCloud Identity AgentUninstall ).
3. Log in to the hub and select the Cloud Identity Engine tenant that contains the agent you want to remove.
4. Select  Agents & Certificates .
5. Confirm that the agent’s  Status  is  Offline  and  Remove Agent .

You can only remove an agent that is offline (the connection between the agent and the Cloud Identity Engine is not active). If the agent is not offline, the  Remove Agent  button is not available.

Manage Cloud Identity Engine Certificates

After you generate the certificate to  Authenticate the Agent and the Cloud Identity Engine , you can view the certificate and its associated agent in the Cloud Identity Engine app.

The Cloud Identity agent version 1.5.0 and later versions automatically renews the certificate before it expires.

You can view the identification number and lifetime of the certificate on the  Agents & Certificates  page in the Cloud Identity Engine app.

If you need to  Revoke Cloud Identity Agent Certificates , you must  Delete Obsolete Cloud Identity Agent Certificates  before you generate and install the new certificate.

To generate a new certificate for an agent, click  Get New Certificate , then follow the steps to  Authenticate the Agent and the Cloud Identity Engine .

Revoke Cloud Identity Agent Certificates

If a Cloud Identity agent’s certificate is compromised, revoke the certificate.

1. Log in to the  hub  and select  Cloud Identity Engine .
2. Select the tenant associated with the agent with the compromised certificate.
3. From the Cloud Identity Engine app, select  Agents & Certificates .
4. Revoke  the certificate.
5. Delete Obsolete Cloud Identity Agent Certificates  to remove the previous certificate.
6. Generate a new certificate to  Authenticate the Agent and the Cloud Identity Engine  and install it on the agent host.

Delete Obsolete Cloud Identity Agent Certificates

You must delete the previous certificate for the agent before installing the new certificate. If you do not delete the previous certificate, the Cloud Identity Engine may reference the previous certificate instead of the new certificate.

1. On the agent host, open Microsoft Management Control (MMC) by selecting  StartRun , then entering  MMC .
2. Select  FileAdd/Remove Snap-In .

3. Select  CertificatesAdd .

4. Select  Computer AccountNext .

5. Select  Local ComputerFinish .

6. Click  OK , then navigate to  Console RootCertificates (Local Computer)PersonalCertificates .

7. Select the previous certificate from the list.
8. Right-click the certificate, then  Delete  and click  Yes  to confirm the deletion.
9. Generate a new certificate to  Authenticate the Agent and the Cloud Identity Engine  and install it on the agent host.

Associate the Cloud Identity Engine with Palo Alto Networks Apps

The following procedures describe the steps for the support account view in the Hub. If you are using the tenant account view, association is not necessary for a tenant service group ( TSG ). For more information, refer to the  Hub Getting Started  guide.

By associating your Cloud Identity Engine tenants with other Palo Alto Networks apps, you can allow these apps and services to access your directory information for reporting and policy enforcement. You can associate the Cloud Identity Engine tenant with another app during activation or with an existing app at any time.

To share user attributes with multiple apps, associate the same Cloud Identity Engine tenant with each app.

Associate the Cloud Identity Engine During Activation

The following procedures describe the steps for the support account view in the Hub. If you are using the tenant account view, association is not necessary for a tenant service group ( TSG ). For more information, refer to the  Hub Getting Started  guide.

1. Using your Auth Code,  activate  the Palo Alto Networks cloud app you want to associate with the Cloud Identity Engine tenant.

2. Enter the information required to activate the application, such as an  Instance Name  and a  Region , which will vary depending on the app.
3. Select the  Cloud Identity Engine  tenant you want to associate with the app.

Only Cloud Identity Engine tenants that are compatible with the Palo Alto Networks cloud application are displayed in the drop-down list. For example, a Cloud Identity Engine tenant assigned to the US region would be compatible with another Palo Alto Networks cloud service app assigned to the US region. If the Cloud Identity Engine field is not available, the Palo Alto Networks cloud services app you selected does not support the Cloud Identity Engine.

4. Agree and Activate  the app.

Associate the Cloud Identity Engine with an Existing App

The following procedures describe the steps for the support account view in the Hub. If you are using the tenant account view, association is not necessary for a tenant service group ( TSG ). For more information, refer to the  Hub Getting Started  guide.

1. Log in to the hub, click  Settings  (

   

) then  Manage Apps .

2. Select the app you want to associate with the Cloud Identity Engine tenant.
3. Select the  Cloud Identity Engine  tenant you want to associate with the app and click  OK .

Only Cloud Identity Engine tenants that are compatible with the Palo Alto Networks cloud application are displayed in the drop-down list. For example, a Cloud Identity Engine tenant assigned to the US region would be compatible with another Palo Alto Networks cloud service app assigned to the US region. If the Cloud Identity Engine field is not available, the Palo Alto Networks cloud services app you selected does not support the Cloud Identity Engine.

After you associate the app, the Cloud Identity Engine tenant name displays in the  Cloud Identity Engine  column in the hub ( SettingsManage Apps ).

Authenticate Users with the Cloud Identity Engine

Learn how to deploy the Cloud Identity Engine for user authentication by configuring a SAML 2.0-based identity provider (IdP), a client certificate and certificate authority (CA) chain, or both. After specifying how you want to authenticate your users, set up your authentication profile to define your authentication security policy and optionally configure the authentication policy on your firewall or Panorama. After you’ve done that, configure the Cloud Identity Engine as a User-ID source for group mapping and user mapping to enforce group-based policy.

You can configure SAML 2.0-compliant identity providers (IdPs) in the Cloud Identity Engine to authenticate your users. The following topics provide detailed steps on how to configure specific IdPs as authentication types in the Cloud Identity Engine.