topic Re: Use of computer ldap groups in source-user policy field on palo alto in General Topics

Use of computer ldap groups in source-user policy field on palo alto

dhirvin — Tue, 23 Jan 2018 11:29:49 GMT

We are attempting to use a computer based ldap group in the source-user field of a traffic policy on our palo alto 5020.

At the moment that policy is being ignored, and subsequent policies based just on the same source ip group are being acted on.

(if the source-user is set to any (removing group domain\wkstn_group) then the policy works)

We have been successfully using source-user fields based on used-id and user group membership.

Could you confirm whether or not it is possible to use computer group membership in the source user field

Re: Use of computer ldap groups in source-user policy field on palo alto

Mick_Ball — Tue, 23 Jan 2018 12:24:03 GMT

@dhirvin, hi.

i can't confirm your suspicians but perhaps somebody else can.

At a guess I would say "No" as the user ip mapping process relates to the user, not the device.

for globalprotect usage this can be resolved by HIP but thats probably no help to you.

Re: Use of computer ldap groups in source-user policy field on palo alto

Brandon_Wertz — Tue, 23 Jan 2018 14:30:10 GMT

Palo doesn't have a way currently to use computer based security groups for a "source host" policy enforcement.

Re: Use of computer ldap groups in source-user policy field on palo alto

Brandon_Wertz — Wed, 24 Jan 2018 14:46:06 GMT

That said if you're good with scripting and scanning AD you can do what we've done.

Create a script which dumps an AD security group
take these hostnames in NSLOOKUP and get their IP --> dump this to another file
Take this NSLOOKUP file and create a EDL (palo) object pointing to this NSLOOKUP file
Use the EDL file with the IPs of the hostnames which exist in the security group

Viola You've got a security policy which is based on security group membership!! (We do this for a few sensitive use cases at my company)

Re: Use of computer ldap groups in source-user policy field on palo alto

Mick_Ball — Wed, 24 Jan 2018 15:33:07 GMT

wow... clever stuff @Brandon_Wertz.

are you able to update this dynamically.. or do you just assume the devices will always get the same ip address.....

Mick.

Re: Use of computer ldap groups in source-user policy field on palo alto

Brandon_Wertz — Wed, 24 Jan 2018 15:55:22 GMT

We do assume the computers have different IPs. Our script runs on a specified interval and updates the "known IP" for the machine.

So when DNS gets updated our script runs, updates the IP address in the text file. The EDL update on the firewall happens on a specified interval and it too gets an updated record of the "computer object."

Re: Use of computer ldap groups in source-user policy field on palo alto

dhirvin — Wed, 24 Jan 2018 15:57:08 GMT

perhaps I wasn't explicit enough - we need the policy applied to Workstation PC's that are part of a particular domain group.

Re: Use of computer ldap groups in source-user policy field on palo alto

Mick_Ball — Wed, 24 Jan 2018 16:47:57 GMT

yep, gotcha...

the PA has no real concept of a user, its just a tag related to an IP address.

it gets this tag from the AD security policy on DC's or similar..

so...

ip 10.10.10.10 is normally tagged to user fred via AD security log.

with @Brandon_Wertz suggestion the tag is no longer obtained from the security log relating to the user.

it will get the tag from the new file created with hostnames...

so...

ip 10.10.10.0 is now tagged to freds_pc

so the PA policy will now see freds_pc, not fred. as long as freds_pc is allowed in the policy, either directly or by group membership then it will be allowed, or of course denied.

perhaps @Brandon_Wertz can explain better as i have never used this as an option but can see how it works. (i hope)

Mick.

Re: Use of computer ldap groups in source-user policy field on palo alto

Brandon_Wertz — Wed, 24 Jan 2018 18:21:13 GMT

@dhirvin wrote:
perhaps I wasn't explicit enough - we need the policy applied to Workstation PC's that are part of a particular domain group.

Maybe I confused you. What I described is exactly that.

Machine (call it PC A) which are a part of a computer group / container (call it "security team")

Create a script which queries "security team" computer container --> Creates a text file and dumps "PC A" into said file
Script reads text file does NSLOOKUP for PC A --> Creates a new text file with the IP address for PC A in this new file
Create EDL (palo object) which points to this second text file which has an IP address for a machine name
Use EDL in security policy as source / dest IP

Re: Use of computer ldap groups in source-user policy field on palo alto

Brandon_Wertz — Wed, 24 Jan 2018 18:32:38 GMT

@Mick_Ball wrote:
yep, gotcha...

the PA has no real concept of a user, its just a tag related to an IP address.
it gets this tag from the AD security policy on DC's or similar..

so...
ip 10.10.10.10 is normally tagged to user fred via AD security log.

with @Brandon_Wertz suggestion the tag is no longer obtained from the security log relating to the user.
it will get the tag from the new file created with hostnames...

so...

ip 10.10.10.0 is now tagged to freds_pc

so the PA policy will now see freds_pc, not fred. as long as freds_pc is allowed in the policy, either directly or by group membership then it will be allowed, or of course denied.

perhaps @Brandon_Wertz can explain better as i have never used this as an option but can see how it works. (i hope)

Mick.

Hopefully my further explination clears things up. We do use user-ID enforcement for policy, however that's used in different areas.

The process I'm describing for getting machine IPs in my scenario isn't tied to a particular user.

We querry the machine object in the script so regardless who may or may not be logged into the machine gets policy based upon the current IP of the machine name. (Just as you have pointed out)

Re: Use of computer ldap groups in source-user policy field on palo alto

Brandon_Wertz — Wed, 24 Jan 2018 18:45:30 GMT

Here are two screenshots.

One of the EDLs

Review of current security logs which take the intended security policy (Of note you can see one of the entries has an obfuscated user so you can see both "known" and "unkown" user match our intended security policy.