custom groups using ldap-filter/query to use with GlobalProtect

[TommieVanHove]

Hello. 

I'm currently working on a setup involving Global protect for teleworking. 

the company has users who are allowed to connect remotely with their id, and users who aren't. 

the decision for this is based on a user-attribute: msNPAllowDialin (of type boolean)

-->

if set to allow --> useer should be able to logon to GP portal/gateway

if set to deny --> user is not allowed to connect remotely

This seems to be possible to implement via custom group under user identification. 

with an ldap filter (msNPAllowDialin=true)

however I can't seem to get it to work and can't find much documentation how to troubleshoot this on a palo alto. (without access to teh AD environment)

I'm fairly certain the issue is with the custom group. 

ldap test when I have all or a specific group configured in allow list: both my testusers( 1 with the attribute to allow, the other with deny) can logon. 

both via test command cli. or via GP portal. 

however as soon as i change the allow list to the custom group I configured( teleworkers) both CLI test and gp login fail. 

cli command states this is because the user is not in the allowlist. --> custom group issue. 

my question: 

does anybody have experience with this? or perhaps a great resource where I can brush up on how to configure these custom groups? 

if not I'm also looking for cli commands that can aid me in troubleshooting this apart from testing ldap authentication.

as currently I'm not even sure if I can use the msNPAllowDialin attribute --> are some attributes not usable in ldap filter and is this one of them? 

And yes I have played a bit with the ldap filter: so trying TRUE, true, etc I've already done. 
unless AD uses other values for boolean? 

any help would be greatly appreciated. thanks in advance

[Mick_Ball]

i have never created a custom group but will have a play soon as need to set something similar...

msNPAllowDialin is a std user attribute and should work OK,

as a first test I would cli..

show user group list   (to ensure group listing is recognised)

show user group name " your custom group from above output" (to see if it has any recognised members)

see what output you get and post back

[Mick_Ball]

Just an update...

the custom group with attributes works fine, i have tested with the user attributes sn and department. I cannot get it to work with msnpdialin. You may be correct in your assumption but i will test further on monday as i can remove ldap/ssl on test lab and capture palo packets vs openldap search.

[TommieVanHove]

and an update from my part as well.

I did some extra tests myself(after letting the problem rest for a while)

and strangely if I create a custom group with following filter:

(msNPAllowDialin=*)

I get a few users in the group. including my 2 testusers.

however when I try

(msNPAllowDialin=true)

I get an empty group.

starting to think I may need to ask the ppl managing the AD to give me some more info.
as according to my logic creating a filter with (msNPAllowDialin=*) should basically give me a list of ALL users

as the attribute only has 3 possible values: Not Set, True, False

[Mick_Ball]

Hmmmm... nicely diagnosed....

not sure if the wildcard actually means “any” in this case, the boolean attributes are wierd.. i do know that some of them that are not set require the use of a null string “” to complete the search...

I have also noted that the true or false is stored in upper case but tried that aswell.

Talk soon..

[Mick_Ball · Accepted solution]

hi @TommieVan

it seems the query is case sensitive.

on my ldap browser I searched for:-

"(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))"

this returned all users correctly

I then tried:-

(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=True))

this returned no users at all..

I also tried FALSE and False with the same results.

Also ... the "*" wildcard returned both TRUE and FALSE but not Not-Set, so be warned...

so.. I captured the LDAP query from the palo and it converts to lowercase as below.

so this is your problem,

below is a dump of my custom group settings and wireshark capture for "FALSE"

as you can see the Gweneth Paltro has converted to lower case.

[TommieVanHove]

good to know the * filter only returns users with attribute set. 

according to various documenation about msNPAllowDialin if the attribute is not configured teh value should either be:

Not Set --> unlickely as that would fall under *

or an empty stirng: " " --> might be this one. 

any way long story short: with the current palo alto it will not be possible to create custom groups based on user attributes that are case sensitive. as palo does a "to lowercase" on it's query. 

I believe all Boolean type attributes are case sensitive in AD( and these are I believe the only ones that are case sensitive). 

so note: building custom groups based on Boolean attributes will not be possible in palo alto. 

[Mick_Ball]

Perhaps report it as a bug @TommieVanHove

[TommieVanHove]

I was planning to. 

Thank you for checking and the support as well. 

my plan is to report this to paloalto. 

but for our custoemr the fastest solution will be to make a change on AD