About ksauer507

Ok all connections to this site are from one machine, so we did a negate rule on the source from this machine.  So far it seems our random connection issues have been resolved.   Its an ok risk for this one machine to not be in a decryption policy.  In fact its a lot of financial data, we know what it is and its probably better its not tampered with. ... View more

I did have a VM of that installed but it lit up our vulnerability console like a Christmas tree.  When I updated Ubuntu to a newer release, that fixed the vulnerabilities but broke minemeld.  If its EoL I wonder if PA has any future plans for it, or better yet just build this right into PANOS, why require an external server to do all this legwork.  Maybe that's on the roadmap. ... View more

No, not fixed.  After a few hours it went back to detecting users as domain.com\username, out of nowhere, and because of that extra .com in the username, it doesn’t match any policies. For further discussion on our issue, which as stumped TAC support, please follow here: https://live.paloaltonetworks.com/t5/globalprotect-discussions/not-using-appid-but-gp-connections-are-denying-on-apps-for-10/td-p/468820 ... View more

Not fixed.  It was working beautifully for a few hours.  Everything was matching, then at one point the firewall out of nowhere started detecting users as domain.com\username , and because of that .com, not matching on any AD groups, therefore falling into our temporary all access safety net policy (which we really need to get rid of!).   What would cause the firewall go out of nowhere throw that additional .com back in the username?  Seems like you make a small change and commit the firewall, it will resolve it for a bit, but eventually break again all by itself.   I seem to be talking to myself here.  Is this forum visited often?  Or is it pretty much silence like Palo Alto support? ... View more

Ok in Azure claims we went back to user.userprincipalname, and in the Group Mapping > User and Group Attributes Primary Username is also matching as userPrincipalName. Even though this was a direct match, PAN support basically threw us out saying this was an Azure AD issue.  In fact after 4 days of rigorous round-the-clock testing and troubleshooting, even on PTO time... we think we solved it.   In User Identification, there's a certificate profile attached.  We went to that certificate profile and the third field down is User Domain.  It was set to our domain in this format: domain.com.  We basically threw a hail mary here and changed it to just domain..  After reconnecting we finally saw non-domain machines such as iPhone and mac test equipment finally match the user ID in username@domain.com format and hit on the actual policy we have tied to that AD group the user lives in.  We also see successful consistent user-id matching on domain-joined Windows machines as well.   Seems we are ok now, but we are still watching it!   ... View more

This is prelimiary but for the first time ever we are seeing Mac and IOS clients now finally match the proper user-id and access policy.  What we changed was go into the certificate profile for the cert we are using for User-ID and change the User Domain Name from domain.com to domain. In the help it does say netbios domain here so that obscure setting must have been what caused it.  Also on Windows machines, it seems after prelogon and login script runs, its correctly switches over to the domain user and attaches to the correct policy pretty consistently as of this writing.   PAN support was UNHELPFUL blaming Azure AD and take this issue over to the Azure AD team.  The claims in the SAML properties in Azure AD just have to match something you have in the group ID settings, and we chose userPrinicipalName, so in GP it looks like username@domain.colm.   ... View more

This may have partially been related to the timeout, but I don’t think that’s the whole issue.  Are users are randomly being detected as domain\username , which matches AD groups and users in policies, but then sometimes they are being detected as domain.com\username which does not match any policy so it’s denied.  Then I think it couldn’t send a HIP report (traffic denied) and caused that issue.  But amongst many other issues too.  We created a SAML transform in AzureAD and now the GP client shows domain\user instead of user@domain.com, and 95% of the user UD detections are correct on windows machines, but the first login user-ID gets domain.com\user from source vpn-client.  On a Mac it always detects as domain.com\user since they are not talking to DCs.  Weird because in the GP client the .com isn’t there in the settings UI in either GP 5.2.10 or the new GP 6.0.  For now we have a failsafe “all” users from vpn zone under our specific user based vpn zone.  This way macs can get on and windows users can auth to AD and DNS until they get a legitimate user.  Downside is until then, or if your using a machine not on our domain like a Mac, iPhone or vendor… we can’t control what they have access too.   I posted about it here:  https://live.paloaltonetworks.com/t5/globalprotect-discussions/not-using-appid-but-gp-connections-are-denying-on-apps-for-10/td-p/468820   Would love to “normalize” everything from the Global Protect Enterprise Application in Azure to the GP portal as domain\user, as this would actually match AD users and groups and then fall into the correct policies.  Also across operating systems (windows, mac, iOS, etc).   ... View more

By creating a claims transform in AzureAD to user.onpremisesamaccountname that seems to make 95% of user-id detected as domain\username now.  That’s also indicated in GP client settings in windows and Mac.   BUT we’re not out of the woods yet.  When you first connect on windows there’s two user-id entries in the monitor tab from source: vpn-client and GlobalProtect.  So initially there are hits to AD from domain.com\username which falls under a different access policy.  Once they hit any of our 4 AD servers, they update user-id with domain\username which now they can hit the appropriate policy.   On a Mac client that is not intergrated with AD, user-id always sees them as domain.com\username so then they will never fall into appropriate user groups.  So since macs not touching AD we still think there’s more to the MS Azure AD SAML configuration, or maybe some how to override GP client from throwing in that stupid .com in the domain.  ... View more

One of the things I've noticed is sometimes the fw will see the user as domain.com\username and sometimes as domain\username.  I found this thread and made changes so user and Group Attributes Primary Usernname is sAMAccountName and Alternate Username 1 is userPrincipalName, but it still randomly flip flops detecting the user. so we ignored app-id based on the user name with a temp rule and deleted our others, now things work.  Why doesn't the palo see what AzureAD is passing and normalize it with what we have in on prem AD? ... View more