Doubts with USER-ID and LDAP Server integration.
Hello good evening, as always thanks for the collaboration.
I have the following question I have had to configure User ID and LDAP Server to integrate Palo Alto with AD, usually without agent.
Now I have the following doubt, normally I have integrated it for Global Protect profiles and to recognize AD user in the Log Traffic for traceability issues, logs, reports, etc...
Now I have some doubts regarding the following use.
To be able to define users in a policy, well I already have the USER-ID for it.
-Now my precise doubt is to be able to use Groups in the policies and to build the security policies in Base or based on groups and not users, it is strictly necessary, as in the case for example of the profile of Global Protect to use Group Mapping to map the group example a Group called: " Allow VPN GP ", and thus at AD level all the users that exist in that group will be able to integrate, to add, and to remove etc users of that group for the access to GP, with that all clear.
-Now the doubt is, to be able to define Active Directory Groups at Security Policy level, is it necessary to map each one of those AD groups? each one of the groups that I need to put in the security policies must be mapped at Group Mapping level? or simply with the USER-ID configuration I could already use both explicit users, as well as explicit groups without having to map them or is Group Mapping mandatory?
I remain attentive to your comments.
Thanks for the collaboration
Best regards
In group mapping you can elect to add individual groups or not set a filter at all. For small deployments it can be ok to not define any groups although I recommend to always select the groups you need to decrease unnesmcessary overhead Ip-user mapping is somewhat independent of group mapping as it simply learns the usernames by globalprotect or userid agent/agentless Both of these mechanisms come together if you define a security policy by group as the firewall has a list of members for that group and userid simply provides a match/nomatch The mechanism can be compared to adding a.subnetmask in the rule and an incoming connection either being in that subnet, or not