This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Cookie Policy. Click Preferences to customize your cookie settings.
About TomLunaENS
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About TomLunaENS
03-03-2023
2Posts
10Likes
1Solution
Mar 03, 2023Last Visited
User
Activity
User
Profile
Latest posts by TomLunaENS
| Subject | Views | Posted |
|---|---|---|
| 26714 | 04-01-2020 10:51 AM | |
| 26963 | 04-01-2020 10:09 AM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 1 Like | 04-01-2020 10:51 AM | |
| 9 Likes | 04-01-2020 10:09 AM |
User Badges
Community Statistics
| Member Since | 08-09-2017 01:13 PM |
| Date Last Visited | 03-03-2023 01:41 PM |
| Posts | 2 |
| Total Likes Received | 10 |
04-01-2020
10:51 AM
1 Kudo
Thanks for responding. The security implications would pertain to the potentially increased attack surface in case the service account was compromised. The PaloAlto documentation has some steps to remove unneeded privileges from the account (always a good idea). I just wanted to make clear that adding the user to the additional group may open the server to additional attack vectors which I have not attempted to investigate.
... View more
04-01-2020
10:09 AM
9 Kudos
Hi all. Running in a Windows domain with Server 2019 DC's. I set up the firewall to use the PAN-OS Integrated User-ID agent using Kerberos and WinRM-http using the TechDoc for guidance, and was also running into the "Access Denied" error (HTTP 500: s:Senderw:AccessDeniedAccess is denied. Access is denied.). After some troubleshooting on the server, I determined that the service account was authenticating successfully using Kerberos, but was failing when submitting the WQL query to pull the user/IP data. An error was encountered while processing an operation. Error Code: 5 Error String:<f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="5" Machine="dc.mydomain.com"><f:Message>Access is denied. </f:Message></f:WSManFault> In the end, I figured out that the service account needs to belong to the 'Remote Management Users' group in AD to allow WinRM connections from the firewall to query WMI. This is because the service account (as configured per the TechDoc) is not an administrator on the domain, and by default PowerShell Remoting requires admin privileges. There could be negative security implications to granting the service account this level of access. I have not looked into this issue yet, but additional restrictions may be needed to ensure that this account can't be abused. Thanks!
... View more
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks