Palo Alto Admin authentication with Entra ID and Duo MFA
I wanted to try out Cisco Duo MFA using SAML and loyal readers of this blog will know in posts passim I set up authentication for a Palo Alto firewall administrator using SAML and ADFS so it seemed a natural progression to try this using Microsoft’s Entra ID (formerly Azure AD) with Cisco Duo.
Microsoft Entra ID, which will act as the SAML primary authentication source is available with an evaluation subscription free for 90 days and Cisco Duo, my secondary authentication source, is available as a free subscription for 30 days. The Palo Alto VM firewall, the service provider in SAML terms, was set up in AWS and is not free but a few dollars if you only use it for a couple of hours.
Cisco Duo provides lots of templates for ‘Protected applications’ that are pre-defined but Palo Alto administrator is not one and is thus added as a ‘Generic SAML’ application’. This will become relevant later.
This is quite a long post but the required steps can be summarised as follows:
1/ Set up SSO (Single Sign On) in Duo choosing the SAML option then configure the Entra ID association.
2/ Set up an Application within Entra ID and configure the SAML SSO option therein to associate it with Duo.
3/ Within Entra ID, create a user and user group and associate it with the above SSO application.
4/ On Duo, define Entra ID as a authentication source then add a ‘Generic SAML application’ as a ‘Protected App‘
5/ Set up the Palo Alto to use a SAML IDP to for administrator login.
Setting up Single-Sign-on (SSO) in DUO
Duo itself comes with good documentation on this:
The first thing to within Duo is enable SSO and then add a SAML identity provider.
Then within Entra ID, add a SAML identity provider which is found under ‘Authenticated Sources’ where we have the option of adding a source:
This information is transferred to Duo…
…together with a certificate which was downloaded from Entra-ID
This includes the option to require an encrypted assertion which then gives us the option to download a certificate – which will then be uploaded into Entra ID – effectively so it can read our assertions.
Setting up SSO in Entra ID
Now, in Entra ID, Duo is configured as an Enterprise Application:
This App has the following options:
Of these, Users and Groups needs setting up which we will touch on later but for the moment we will concentrate on Single Sign On and configure the association with Duo. The Single Sign On configuration page, has the following four sections:. (As described in the above Duo documentation link, the Entity ID and Assertion Consumer service come from the Duo SSO configuration)
…assertions are essentially the fields passed in the SAML header…
The third section contains the link to the certificate (Base64) which will be used by Duo and uploaded (see ‘Existing Certificate’ above)
The fourth section has the values which will be transferred to Duo:
Entra-ID Users
On Entra-ID, I have defined a user called john.smith…
…and put him in a group called Palo Admin:
This user has been created with an associated email address from the domain labtinker.net. When the Entra ID instance is created it is with a generated domain derived from the initial login but essentially an onmicrsoft.com sub-domain eg: labtinker376.onmicrosoft.com.
However, it is possible to add other domains. Entra ID then provides a string to be placed in the domain’s DNS TXT record so that it knows the domain is owned and administrated by the Entra ID admin. Only when this is added to the domain’s DNS is that domain verified within Entra and usable within its configuration.
Service Provider Set Up
Having set up the SSO method and primary authenticator it is necessary to set up the service provider application in Duo and configure the Service Provider itself; Palo Alto this instance.
Duo has a lot of ‘templates already in place for popular service providers but this isn’t the case for ‘Palo Alto administrator access’ so in this case we have to use the Generic SAML application.
https://duo.com/docs/sso-generic
Adding the Application within Duo
Within Duo there is an option to Protect an Application:
This has a searchable list of applications that can be protected and in this instance we are searching for the ‘Generic SAML Service Provider’
This leads us to:
Configuring Cisco DUO as a SAML IDP on the Service Provider (Palo Alto)
The Duo Metadata has to be shared with the Service Provider (the Palo Alto) which can be done by exporting and importing a SAML Metadata file in the XML format or by copying each individual field into its relevant place on the Palo Alto.
The SAML IDP, where the above information is input, is on the Palo Alto device menu Server Profiles/SAML Identity Provider:
The option to import the XML file downloaded from Duo is here, but this did not always parse correctly when attempted – so it was necessary to paste the fields in one by one.
The SAML cert referenced above is the certificate associated with the application in Duo and can be downloaded from Duo with the button just above the one used to export the metadata. This certificate can be imported on the Palo Alto from the ‘Device / Certificates’ menu whereupon it can be used in the above configuration. (If the ‘Validate IDP Provider Certificate’ is required, then the CA cert that signs the Duo IDP cert also has be imported on to the Palo too.)
Once this has been defined it is necessary to create an authentication profile which uses SAML. Again, this is accessed from the device menu. An example is shown below:
The certificate used for signing requests is the certificate associated wit the firewall with a CN of firewall.labtinker.net previously imported on to the device.
The SAML attribute is defined as Username. On the advanced tab this is defined for all users…
Once this definition has been completed – a metadata link appears on the authentication profile which can be downloaded and imported into Duo.
This can be imported into the ‘Duo Application Service Provider section as follows:
On the Palo Alto an administrator has to be created and associated with the SAML authentication profile. In this instance the user John.Smith is created: (the Name is not especially clear in the illustration below but does indeed read john.smith)
On first logging in to the Palo Alto, there may be an error. The SAML/Duo login requires the username in UPN format, i.e: John.smith@labtinker.net but the Palo Alto expects just John.Smith. This can be tackled in two ways, the first is to disable a setting called strict-username-check:
The alternative method is to ‘enable user attribute transformation’ in Duo and strip the domain before passing it to the Palo Alto. This is covered later.
OK now, we have set everything up let’s see what happens when we try to login to the Palo Alto:
Login Process
The login process proceeds as follows: On the standard Palo Alto admin screen there is a ‘Single-Sign-On’ option
This leads to a screen where we can input the username (without domain)
This leads to a Microsoft Entra ID login where the full UPN is required:
Entra ID may have its own MFA requirements (not enabled in this instance). Anyway, once we’ve cleared the Entra ID login we are redirected to Duo (which will prompt for set up the first time but on subsequent occasions allows the user to continue after they have acknowledged a code on the device Duo has been set up on.)
Then the user successfully logs in and this is recorded on the Palo Alto system logs in which is recorded in the Palo Alto system logs…
Before we end there were a couple of other points worth mentioning:
Attribute Encryption
There is an option to encrypt the SAML assertion (see above) but this may not work with all applications. This was the case with the Palo Alto administration access as outlined here:
“Palo Alto Networks requires HTTPS to ensure the confidentiality of all SAML transactions instead of alternative approaches such as encrypted SAML assertions. To ensure the integrity of all messages processed in a SAML transaction, Palo Alto Networks requires digital certificates to cryptographically sign all messages”
Attribute Transformation
Above we had the instance where Palo Alto required a username without the domain but Entra ID required the UPN. In the event, we tackled this on Palo but we could have tackled this by transforming the attribute within Duo. The example below strips the @ sign and everything after it.
