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

[dhirvin]

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

[Mick_Ball]

@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.

[Brandon_Wertz]

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

[Brandon_Wertz]

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)

[Mick_Ball]

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.

[Brandon_Wertz]

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."

[dhirvin]

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

[Mick_Ball]

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.

[Brandon_Wertz]

---

@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 

[Brandon_Wertz]

---

@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)

[Brandon_Wertz]

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.