GlobalProtect --- Use machine certificate or a user certificate (without specifying Username Field)

[MPotgieter]

Hi,

I'm busy setting up GlobalProtect for a client, and already have LDAP authentication working. However the client requires a second factor for the authentication and went with certificates because they have an internal PKI.

I've been trying to configure this to use machine certificates, so that only corporate machines would have access. I've followed the guides, and this LIVEcommunity post re-iterates what's I've read.

https://live.paloaltonetworks.com/t5/General-Topics/GlobalProtect-Use-Machince-Certificates-for-Auth...

However, when I leave the Username Field blank in the certificate profile, I get failed commits with the following details:

GlobalProtect portal(portal name) auth setting is invalid: no username field is configured in certificate profile.
(Module: sslvpn)
GlobalProtect gateway(gateway name) auth setting is invalid: no username field is configured in certificate profile.
(Module: rasmgr)
global-protect-gateway tunnel interface (tunnel name) in vsys (vsys1) parsing failed
(Module: rasmgr)

What am I missing here that would cause this error, when all the literature I've been through indicates that I should be able to set the Username Field to "None"? We've even moved to a higher maintenance release on the firewall in case this was a bug. Now running PAN-OS 9.0.7.

Any suggestion of where I could or should look for issues will be appreciated.

Thanks.

[LCMember3289]

Hi

Is there an update or workaround for this i get the same issue.

Thanks

[Ezekoli]

User certificate if you are accessing secured device or adding user in authentication server. Machine certificate if you are adding  machine to a domain or setting up SMTP

[MPotgieter]

Hi @Ezekoli

Thanks for your response, but it's not quite what I'm asking. My query isn't about which type of certificate to use.

When you create a certificate profile, you are able to select how the username field will be populated from the certificate (if for e.g. you are using the certificate as part of GlobalProtect authentication). The three options are Subject (which populates from the common name), Alternative Name (which populates from the Email or Principal Name depending on your choice) or None (which doesn't fill the username field at all).

Everything I've read indicates that you can select a username field to add security to that process, i.e. I've got a username and password but I don't have a cert, I can't use another user's certificate if I had to get hold of one or I can't use another users machine to log on with my credentials. But if you don't need or want that extra level of security, you should be able to select "None".

However, when I do that, I get commit failures. This is the issue I would like to address - why does the firewall fail to commit if there is no option selected for the username field on the certificate profile.

[jsayer]

Seeing the same issue committing with a certificate profile if Username set to None.  Tested this with 8.1.14h2 and commit was successful.  Fails on 9.0.8.  Support engineer tested also on 9.0.6 and saw the same commit failure.  

[jsayer]

PA Support Engineer discovered that the commit failure occurs when the setting for Client Authentication is set to "Yes (User Credentials OR Client Certificate Required)".  this appears both in the portal and gateway settings I believe.  Changed this to "No (User Credentials AND Client Certificate Required)" and the commit was successful.  This appears to be a new option in 9.0 that was not available in 8.1.x code.  

Trying to decipher the implications of setting that to User Credentials AND Client Certificate.  We want to have the machine connect pre-logon, so not sure whether this setting will cause problems with the desired behavior or not.

[BrentA]

I'm facing the same issue, Please do update with any information you can get from them!

[tcleghorn]

This is by design.  If you allow a user to connect using Credential OR Client Cert, we'd need a username from the client cert.

A workaround is to set the User Name in the Certificate Profile to using the Subject Alt Name of the Certificate.  When you generate the Machine Certificate for the Pre-Logon, do NOT put anything in the Subject Alt Name field.  This should allow both Machine Cert users (without Cookies) and non-Machine Cert users.

Best practice would be to set-up 2 Portals and 2 Gateways.  One with the CertProfile (for your domain trusted machines) and one without (for your contractors).

[doug-elliott]

I used this document -- https://supportcases.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFoCAK -- and instead of "none" for username in the cert profile, I used `Subject'.