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 tstokkeland
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About tstokkeland
08-18-2015
7Posts
0Likes
0Solutions
Aug 18, 2015Last Visited
User
Activity
User
Profile
Latest posts by tstokkeland
| Subject | Views | Posted |
|---|---|---|
| 2728 | 10-31-2012 05:02 AM | |
| 3790 | 09-26-2012 05:01 AM | |
| 3917 | 09-25-2012 05:34 AM | |
| 3917 | 09-25-2012 05:10 AM | |
| 2405 | 06-19-2012 12:38 PM | |
| 2405 | 06-19-2012 07:47 AM | |
| 2789 | 06-19-2012 06:57 AM |
User Badges
Community Statistics
| Member Since | 05-31-2012 05:42 AM |
| Date Last Visited | 08-18-2015 09:07 AM |
| Posts | 7 |
10-31-2012
05:02 AM
Pretty sure The VPN certificate issue is not a bug - there was a warning/release-note issued, i got an email, that mentioned the certificate must match the name of the URL, and some extra validations that the new versions of client or gateway will do, so if your cert is not created correctly it will probably cause an issue. https://live.paloaltonetworks.com/docs/DOC-2020 I am very curios, I still havent upgraded, but with the man-in-the-middle vulnerability noted a few days ago, i will want to upgrade sooner than later... how many out there are using 4.1.8 with ldap auth successfully? in other words, are the issues common for everyone or is it just a few that have issues, meaning the solutions in this thread took care of it for most? -- btw, here is the content of that email: Announcement : GlobalProtect 1.1.7 Release Notes Announcement created by panagent in Palo Alto Networks Live - View the announcement GlobalProtect 1.1.7 implements enhanced checks for CA Server Certificates chain-of-trust. This change will cause some existing configurations to become invalid and may result in remote users receiving an error when connecting to the portal, or will not be able to connect if the certificate issue is present on the gateway. Before deploying the GlobalProtect Agent 1.1.7 to users, ensure that the Portal and all Gateway server certificates are valid and that the certificate Common Name (CN) fields match the FQDN or IP address of the portal and/or gateway that uses the certificate. The SSL certificate that you use for the GlobalProtect portal/gateway should have a Common Name (CN) that matches what you configured in the portal settings. For example, if your certificate has the CN of gp.example.com, ensure that your portal configuration lists the gateway as gp.example.com and does not use an IP address and vice versa, otherwise when the GlobalProtect Agent tries to connect it will generate an error specifying that the certificate CN does not match. Additionally, when the certificate is created, the Subject Alternative Name (SAN) must be exactly the same as the certificate's CN. If the certificate uses the CN of the DNS name, ensure that the SAN also uses the DNS name and not the IP address. A mismatch will cause the GlobalProtect Agent to recognize that the SAN is not the same as the CN and will also produce the certificate error. If your certificates are generated by a public certificate authority, then this will be done correctly and you should not have any issues. Refer to the following tech note for details on configuring server certificates https://live.paloaltonetworks.com/docs/DOC-2020 . Announcement expires on November 25, 2012
... View more
09-26-2012
05:01 AM
pretty sure kerberos had an issue all along though - i was advised by TAC to use ldap/ad instead of kerb some time ago, and that fixed the issues i had then - these ldap issues now I only noticed in admin-auth, I didnt test on ssl-vpn auth before downgrading, but I dont use ldap in rules, I use user/groups but that is provided by the DC agents i believe, I dont think that was affected but I didnt test it all through
... View more
09-25-2012
05:34 AM
just more fyi - I downgraded my pa-2050 and ldap auth (for admin login) started working again - leaving my panorama at 4.1.8 for now in hopes of a fix coming soon
... View more
09-25-2012
05:10 AM
I am having the exact same issue on a PA-2050 and on panorama - I am downgrading for the time being...
... View more
06-19-2012
12:38 PM
Thank you - i have been fiddling with this all day - and discovered its not working right when doing the LDAP stuff from panorama, or at least, it works better from the firewall itself, the FQDN versus Wintendo-netbios network name was one of the issues, I had portal working but not the gateway, removal of fqdn fixed that.
... View more
06-19-2012
07:47 AM
more searching and digging and I found this post which lead me to the device/panorama setting, where a profile has to be chosen for the box. so this works as long as I add each individual user to the administrators list. Shouldnt this work by just adding a group? and I still have no good way of debugging this crap
... View more
06-19-2012
06:57 AM
There is a ton of various old and somewhat newer info on LDAP related info around, but I have not been able to find any good source on step by step and how to troubleshoot - a lot of the junk seems to reference user-id stuff, which I believe is not relevant, shouldnt I be able to configure an LDAP server profile, a authentication profile, and then use this for authentication (wether admin access or ssl vpn?). I have been unable to find any logs or info on how to test if my LDAP server profile is even working. I had kerberos authentication working just fine, but the bugs with Kerberos and groups makes it unusable, so I have to get LDAP configured, but so far I have not been able to. for my testing I am doing this in panorama, for the local admin logons to Panorama (because it is so much faster to commit with than a firewall): here is what I did - which I believe should work: created a user in the domain named pan-admin (for sake of troubleshooting I gave it domain admin rights) Created LDAP Server Profile Name: adtest Servers: Added two DC's by IP, port 389 Domain: mydom.local Type: Active-Directory Base: DC=mydom,DC=local (this pulled up by dropdown) Bind DN: DN=pan-admin,OU=Service Accounts,DC=mydom,DC=local Password: ** I unchecked SSL the rest is default. Created an Authentication Profile Name: adAuthAdmin Allow List: removed all, and added a single user like mydom\username and a group mydom\groupname by typing them in (I would think that just group should work, but for testing purposes I also added my speciifc user) Authentication: LDAP Server Profile: adtest Login Attribute: (left blank, dont really get what the hell this is) Under Administrators I added 2 users, one for the group (mydom\groupname) and also my individual user for testing, usint the "adAuthAdmin" profile and superuser... shouldnt that work? I cant even find out how to test if the LDAP Server profile is even working - logs show nothing at all - when trying a login the system log just shows User 'mydom\username' failed authentication. Reason: Authentication profile not found for the user From: 10.159.14.11.' ) I tried a lot of different things but I have no luck really - the DC's are 2003's - I have 2008R2's as well but figured there be less prone to issues using the old ones... btw - user-identification working fine with the agents and all that - I dont see how that is even relevant other than that it uses it for dropdowns on the firewalls (not in panorama since it doesnt have user-id. any help appreciate - I might open a ticket soon,...
... View more
Labels:
- Labels:
-
Troubleshooting
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
08-18-2015
09:07 AM
|
Latest Tags
No tags yet
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks