How to Configure Group-Mapping in a Multi-Domain Active Directory Domain Services (AD DS) Forest

Printer Friendly Page

Up to PAN-OS 6.1, for later OS versions, see this article

 

Overview

This document describes how to correctly configure group-mapping to avoid inconsistencies in username format for cross-domain users in a multi-domain Active Directory Domain Services (AD DS) forest. If fetching all objects (user or groups) from any other domain in the forest, use AD server defined as Global Catalog in group-mapping. The global catalog is a distributed data repository that contains a searchable, partial representation of every object in every domain members of the forest.

 

Important! If not configured properly, there can be issues where some users in group-mapping are formatted as fqdn-domain-name/username (dummy.example.com/username) instead of netbios/domain-name (dummydomain/username), leading to inconsistencies with ip-user-mapping fetched from User-ID Agent or by the agentless User-ID service.

 

Steps

  1. AD server configured as Global Catalog role (usually the root domain) needs to be configured under LDAP server profiles. Connect to this server on port 3268 (or 3269 for SSL).
    ad-screen-1.png
  2. As usual, configure the Domain field to have PAN-OS replace the domain name. Leave it blank otherwise.
    Note: Be aware that doing this on Global Catalog will replace domain name for ALL users and groups fetched from this server, including those from other domains (members of the forest). Only add a domain name into this field if keeping it blank causes problems. For example, if the domain is "acme.local" but "acme" is needed, then enter "acme" in the Domain field.

  3. Use this profile to configure the Group-Mapping (and configured included list if needed)

  4. If the Domain Name was not configured manually in step 2, it is mandatory to configure an additional group-mapping using another LDAP server profile, querying the same AD server on regular port 389 (or 636 for SSL). This operation is mandatory to correctly populate domain-map used to normalize user format as netbios_domain_name/username
    ad-screen-2.png
    This profile will only be using to fetch domain-map; configuring Domain field is not necessary and may be left blank. The AD server used here can be another Domain Controller of your forest and the partition container we query for domain-map is replicated through all Domain Controllers. Please see the note on Step 2.
    Screen Shot 2013-07-24 at 10.42.05.png
    If Active Directory contains a large number of users and groups, you are advised to configure some search filters for users and groups in the GM-AD setting. This is to mitigate the impact of LDAP query results on the Management-Plane resources for this Group-Mapping.

  5. As this Group-Mapping is only used to determine the domain-map, getting and handling the results for users and group is not necessary.
    Screen Shot 2013-07-05 at 09.46.52.png

 

In this example, search filters are configured with a 'Dummy' string that must be contained in the description field of users and groups to guarantee LDAP query results in 0.

 

See Also:

LDAP Group Mappings in a Mixed 6.x and 7.x Environment with Panorama  

 

owner: nbilly

Comments

Thanks! Especially the explanation in Step 2 was precious for us.

Step 2 was also key for me. I had created security policy using selected groups under "User"

However, it would not work until I changed the Domain field in the LDAP settings by removing a populated domain-name and leaving the field blank.

the search filter is used to compare a LDAP attribute, like description or something usefull like memberOf

memberOf=name_of_user_group

that could be used to authenticate user included in  "name_of_user_group"

The tech note says:

  • In step #2: "As usual, configure Domain field if you want PAN-OS to replace domain name. Leave it blank otherwise."
  • In step #4: "configuring Domain field is not necessary and may be left blank."

Result:

  • This did NOT work well for us.
  • We ended up with some users that has \domain\user and others that were just \user. (domain is missing.) This does some very unpleasant things to group memberships - they stopped working.

show user user-ids

User Name                       Vsys    Groups

------------------------------------------------------------------

\fred                      vsys1   cn=1ndcbsvlweb01-user,ou=turkwise,ou=xxx groups,dc=xxx,dc=lan

                                        cn=1l_travel,ou=user groups,ou=xxx groups,dc=xxx,dc=lan

                                        cn=1l_fipchat,ou=user groups,ou=xxx groups,dc=xxx,dc=lan

                                        cn=1l_salesforce,ou=user groups,ou=xxx groups,dc=xxx,dc=lan

show user group name xxx\globalprotect_super_users

short name:  xxx\globalprotect_super_users

source type: proxy

source:      GM_GC

[1     ] \v.contract       <-- domain missing on all members of the group

[2     ] \fred

[3     ] \isam

[4     ] \andre

show user ip-user-mapping all

IP              Vsys   From    User                             IdleTimeout(s) MaxTimeout(s)

--------------- ------ ------- -------------------------------- -------------- -------------

10.99.1.39      vsys1  UIA     xxx\lkoll                        3379           3379      

10.104.149.64    vsys1  UIA     xxx\tacauto                      3425           3425      

10.105.1.67      vsys1  UIA     xxx\ebrtan                       2649           2649      

Fix:

  • Specify the Domain field. Our AD Domain is "YYY.lan", so the Domain would be "YYY".
  • Worked MUCH better after that little change.

Other Info:

  • We are running Windows 2008R2 / 2012 / 2012R2 Domain controllers with a schema level of 2008R2
  • Using the Windows-based User-ID agents v6.0.1-2 (recently upgraded.)
  • Is User-ID agent support, both agent-less and with agent, coming any time soon for Windows 2012?
    • Windows 2008R2 shipped 5 years ago. Its getting a bit "long in the tooth".
    • Windows 2012 shipped 1.5 years ago.
    • Windows 2012R2 shipped in 4/2014.

If your AD sub domains do not conform to the DNS type naming convention (e.g. Root.Local -> City.Root.Local -> Dept.City.Root.Local) then using "DC=Root,DC=Local" as your Base DN may not work.
If your naming is something like: Root.Local -> City.Local -> Dept.Local, then you will need to use only “DC=Local” as your Base DN.

If you follow Step #5 above, and use search filters for Group Objects and User Objects on GM-AD, it doesn't work as expected. It fails, causes a large number of LDAP query retries (every 2-3 seconds), and causes lots of debug logs to be generated as well. (Verified broken in 6.0.10 and 6.1.7). I have an open Support case (#00307484) on a related LDAP issue, and this was found/addressed during diagnoistics of the original issue.

 

Support/Engineering came up with a pretty elegant workaround, which I thought is definitely worth sharing.

 

Visible Symptoms that Search Filters are Not Happy:

 

CLI> show user group-mapping statistics 

Name Vsys Groups Last-Action(secs) Next-Action(secs) 
--------------------------------------------------------------------------- 
GM_GC vsys1 27 0 secs ago(took 0 secs) In 300 secs 
GM_AD vsys1 0 0 secs ago(took 0 secs) In 2 secs 

 

If you have setup your Group Mapping per the instructions, and the text in RED above always stays in the 0-4 second range, you are very likely seeing the issue.

 

Elegant Workaround:

 

The workaround is pretty simple:

  • Don't use search filters on Group Objects and User Objects. 
  • Create an empty "dummy" group in AD and include only that one group in the Group Include List. 

 

Screenshots showing the changes are below - with domain name-specific items obscured:

 

Screenshot_1.png 

Screenshot_2.png

 

One Last Note - Update Intervals - Why 300 Seconds?:

 

You will see above that the update interval timer to 300 seconds, not the usual default of 60 seconds. We found that because of the size of our AD Domain, it was occasionally taking >60 seconds for the LDAP Group membership query process to complete and the next iteration of the query process would kick off before the prior one finished. On Support's recommendation, we kicked the update interval from 60 to 300 seconds and that problem is resolved.

 

Of course, nothing is perfect... Due to a bug (with fix coming), changing the update timers and commiting will cause the useridd process, the one that does the LDAP queries, to fail and stop talking to AD. The firewall will continue to run on whatever group membership info it has cached, but eventually will start aging out the entries.  

 

To see if the useridd process has failed, do the following below twice separated by ~10 seconds.

 

CLI> show user group-mapping statistics 

Name Vsys Groups Last-Action(secs) Next-Action(secs) 
--------------------------------------------------------------------------- 
GM_GC vsys1 27 20 secs ago(took 0 secs) In 280 secs 
GM_AD vsys1 0 30 secs ago(took 0 secs) In 270 secs 

 

<<<Wait 10 seconds here>>>

 

CLI> show user group-mapping statistics 

Name Vsys Groups Last-Action(secs) Next-Action(secs) 
--------------------------------------------------------------------------- 
GM_GC vsys1 27 30 secs ago(took 0 secs) In 270 secs 
GM_AD vsys1 0 40 secs ago(took 0 secs) In 260 secs

 

The timers in GREEN above should be counting down - by the amount of time (~10 seconds) between the two commands. If they are never getting to be less than 2-4 seconds than the update interval time (always staying between 296-300 seconds for this example), the process has failed.

 

Workaround from Support/Engineering: Issue the debug command below to restart the useridd process. On my firewalls, it takes about between 15 seconds for the process to restart and up to one update interval (300 seconds in this example) to start gathering updated group membership data from our AD.

 

CLI> debug software restart user-id

 

That's it. Hope this is useful to you!

As usual, a very technical article :D

Much appreciated!

obtained the relevant information (as per the below) and have updated the Base DN for the LDAP source we have configured for the two domain controllers that have a copy of the global catalogue (and using the Global Catalogue SSL LDAP port). The other LDAP source has been left as is using the original Base DN.


Since completing this the domain-map has successfully populated and the IP address to username mappings have been normalised and all users are showing the NetBIOS domain correctly for all users now.

 

Go to the Domain and do the following:

1-Start ; and search for ASDI Edit
2-In ASDI Edit , right click and connect to
3-From the Radio buttons available ,choose : Select a well know naming Context and change the drop down menu to Configuration , click OK
4-That will connect to the Domain in Configuration Context , now go to the folder CN=Partitions
5-Right click on it and choose properties
6-In attribute Editor look for the Attribute DistinguishedName
7-Note down the Value of this attribute as it is .

This is what is needed from AD side >>>>> No changes made on the AD

Now on the firewall clone the LDAP Profile we had

Keep everything as it is except for in the BASE field , enter the value you got from the steps above
Commit
You should now see an output when you do :

debug user-id dump domain-map

Would AD 'distribution list' group work? I know the AD 'security group' would work. Btw this is under group-mapping -> group include-list.

Was sent this artical to solve our problem using PAN 7.11 and the Domain field does not exist on 7.11 (specific to step 2) so this artical does not apply any more to current versions.  It would be nice if it was updated so it would.

 

We need the solution for the group mappings in multiple AD domains when creating specific rules in VPN policies due to domain names not matching short vs ldap.

FSkrotzki I don't know if anyone has gotten back to you but the domain portion has been moved to the Group Mapping settings in step 5.  It was not here before.  (Device -> User Identification -> Group Mapping Settings -> Group Mapping profile - there is now a Domain Settings portion)

 

Hope that is helpful, if this is not the same component PaloAlto please speak up.

 

Brian

Hi @BrianRa and @FSkrotzki

This article is only valid for PAN-OS 6.1, for newer versions (and the changes that were introduced to the GUI)  please see this article