This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
About dannyman
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About dannyman
08-08-2018
15Posts
2Likes
1Solution
Aug 08, 2018Last Visited
User
Activity
User
Profile
Latest posts by dannyman
| Subject | Views | Posted |
|---|---|---|
| 2097 | 07-02-2018 10:58 AM | |
| 7737 | 11-14-2017 04:18 PM | |
| 7415 | 11-14-2017 02:54 PM | |
| 7419 | 11-14-2017 02:25 PM | |
| 7423 | 11-14-2017 01:33 PM | |
| 7573 | 11-14-2017 10:01 AM | |
| 7587 | 11-13-2017 03:15 PM | |
| 7590 | 11-13-2017 12:38 PM | |
| 8418 | 11-13-2017 10:46 AM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 2 Likes | 11-14-2017 04:18 PM |
User Badges
Community Statistics
| Member Since | 07-05-2017 11:40 AM |
| Date Last Visited | 08-08-2018 04:10 PM |
| Posts | 15 |
| Total Likes Received | 2 |
07-02-2018
10:58 AM
@santonic I tested your very question out on the previous page. All I got to work was having the CN match the username. Alternatively, you can run a patched version of openconnect, which doesn't enforce username matching. https://github.com/dlenski/openconnect Caveat: in my opinion, that GP is relying on the client to enforce an InfoSec rule is a bug. After some run-around, Palo Alto agreed that this was a bug, so they might fix it one day if they haven't already.
... View more
11-14-2017
04:18 PM
2 Kudos
PALO ALTO NETWORKS SECURITY VULNERABILITY: GlobalProtect 2FA password + certificate does not verify that certificate matches user Reboot-between-experiments ... load up a virgin System ... Certificate Profile > Username Field: Subject Gateways > Authentication > Client Authentication *none* User key like this: Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=djh/name=Daniel Howard/emailAddress=djh@example.com Mac GlobalProtect will load the key in PKCS12 format. User shows up as djh. ***** Certificate Profile > Username Field: Subject Gateways > Authentication > Client Authentication *LDAP* Mac GlobalProtect will only let me log in as the user in the CN on the certificate. This achieves 2FA: User needs to have their SSL cert. User needs to know their password. On the unsupported Linux openconnect client, I can log in with any signed cert. There is no server-side enforcement that the user matches the certificate. This is a surprising vulnerability in a security product: that we rely on a client to enforce the server's authentication credentials.
... View more
- Tags:
- vulnerability
11-14-2017
02:54 PM
To better understand how this work, I have disabled LDAP Auth on the GW. Given a key like this: Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=65.50.203.123/name=user1/emailAddress=user1@example.com IF Certificate Profile Username: Subject (common-name), THEN user is listed as the IP address in the CN. IF Certificate Profile Username: Subject Alt (Email), THEN user is listed as the IP address in the CN. IF Certificate Profile Username: Subject Alt (Principal Name), THEN user is listed as the IP address in the CN. IF I delete the key from the client and import one with a different CN, THEN user is listed as the IP address in the previous CN. I figured out the "GlobalConnect Service" is still running between tests, so now when testing I reboot the Mac between tests. (This is faster than the PAN Commit process.) At this point, I can not replicate connect-with-certificate-only. I suspect that the best PAN might support is user password auth plus valid certificate that does not map to a user.
... View more
11-14-2017
02:25 PM
Q: How do I get the certificate to be read by the GlobalProtect client on MacOS? A: The key will only be used by Mac GlobalProtect client IF CN=<IP address of the gateway>. A: Import the key to the system using PKCS12 instead of PEM. (Source: Step C) In my case: openssl pkcs12 -export -out user.pfx -inkey user.key -in user.crt -certfile ca.crt One problem down . . .
... View more
11-14-2017
01:33 PM
Oh yeah, I have tried that and just tried again. Even with Username none, the Mac client cannot find a certificate. The only way to get this working is to disable Certificate Profile. I have yet found no circumstances under which the Mac client finds a certificate which it will try to use with the server. The Linux openconnect will, of course, use any signed cert you pass to it on the command line, and if username is configured in the Certificate Profile, any certificate with or without a matching username will be accepted.
... View more
11-14-2017
10:01 AM
@Mick_Ball yes if I Certificate Profile == None then I can LDAP Auth just fine. Maybe the way to do this is to try turning off LDAP Auth and see if I can get Cert Auth working on its own, then turn LDAP back on.
... View more
11-13-2017
03:15 PM
I dug up the GlobalProtect logs on the client and found a message that the SSL service profile on the gateway was different from the root CA I was pushing from the portal. This is true, as it was using our comodo cert. I created a new cert for the gateway which is signed by my local CA, and did up a new SSL service profile, and now that error is gone. I can load any number of certificates onto the client Mac OS that are viewed as valid because they are signed by my CA. However, none of them ever get picked up by the GlobalConnect client and all I ever get on the Mac is a gateway error: No valid certificate found. So, I'm stuck back where I have been.
... View more
11-13-2017
12:38 PM
Some progress, maybe: In the Gateway config, on the Agent tab, there's an option to add a Trusted Root CA and check "Install in Local Root Certificate Store" which seems to help convince the Mac Keychain Access app that the certificate I am supplying is legit. Per this article, the CN needs to match the Gateway, so my certs now read: Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=vpn.example.com/name=user1/emailAddress=user1@example.com The client error now reads: Ganteway VPN-MTV: No valid certificate found. Please contact your IT administrator.
... View more
11-13-2017
10:46 AM
NOTE: the freeware pfsense firewall can configure a working VPN with user passwords and user certs (2FA) inside of 20 MINUTES. With Palo Alto Networks, I'm on WEEK 6. Where I am at: 1) I have GlobalProtect working with password auth. (Had to call tech support, who knew what steps were missing from the documentation.) 2) I want to have 2FA: so, I spun up a CA (easy-rsa) to provide a CA cert, and generate per-user certs. (pfSense will just do this for you in the GUI, but I did the process described here: https://openvpn.net/index.php/open-source/documentation/howto.html#pki) 3) I can get password + cert working with the unsupported Linux client. (https://github.com/dlenski/openconnect) 4) I can get password + cert working with the unsupported Linux client, using either my personal cert, or another user's personal cert. (WTF?) 5) We have tried and tried and tried again to "import" a personal cert on MacOS but anywhere we import a cert with the "Keychain Access" app GlobalProtect comes back with the same error: "The client certificate to establish the GlobalProtect connection was not found." Our client certs have Subject fields that look like this: User=user1: Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=user1/name=VPN/emailAddress=ops@example.com User=user2: Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=user2/name=VPN/emailAddress=ops@example.com Questions: A) How in the name of all that is good do you get a user cert imported on MacOS? B) My Certificate Profile is configured for Username Field: Subject (common-name) ... what should I have in there? C) Or, are my cert Subject's in a form that won't work for GlobalProtect: what should they look like? Thanks, -danny
... View more
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
08-08-2018
04:10 PM
|
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks