> Source: [sk92782](https://support.checkpoint.com/results/sk/sk92782)

# sk92782 - AD Forests - What is supported?

| Property | Value |
|----------|-------|
| Solution ID | sk92782 |
| Date Created | 2013-05-20 |
| Last Modified | 2019-05-21 |
| Technical Level | General |
| Products | Security Gateway |
| Versions | R82.10, R82, R81.20 |

## Symptoms

- * Rules associated to Microsoft Active Directory (AD) Universal Groups are not enforced. Universal Groups are defined on the forest level and can contain users or groups from any domain in the forest.  

* Rules are not enforced when the rule is associated to an AD user group that exists on a different domain than the domain of the logged on user.  

* Two LDAP Account Units defined for the same AD domain, may lead to group association of the user to work incorrectly (user will not be associated to a group chosen by the SmartDashboard user-picker).  

* Rules associated to AD groups on the same domain as the user's, but the nesting is through a Universal Group, a domain group on another domain, or a group on another Account Unit are not enforced (e.g., LDAP AU configured for domain1 and user has association as follows: domain1\\user -\> domain2\\group2 -\> domain1\\group1 - the Security Gateway will not see group2 or group1).

## Cause

1. Microsoft Domain Controllers do not always return AD Universal Groups on LDAP queries, especially if the group is out of the domain's scope.  

2. Check Point Security Gateway does not follow group associations to other Account Units/Domains.  

3. LDAP Groups are associated to a single Account Unit. Therefore, a user found on an Account Unit, will get group membership from that Account Unit only.  

4. Due to the above limitations, AD nested groups (where supported) cannot work, unless the complete user-to-acgroup association hierarchy is supported (according to 1-3).

Click [here](http://technet.microsoft.com/en-us/library/cc755692(WS.10).aspx "Group scope") to read more about the various group types.

## Solution

Avoid having more than one Account Unit with the same value in the **Domain** field under the LDAP Account Unit's **General** tab. Also, multiple LDAP Account Units for the same branches should be avoided.

In order to check your current configuration, using [GuiDBedit Tool](http://supportcontent.checkpoint.com/solutions?id=sk13009), for each of the following tables, validate correctness (as described after the table):

|-------------|----------------------|----------------------------------|
| Table Name  | Table Representation | Table Location in GuiDBedit Tool |
| ad_users    | Users                | Other - ad_users                 |
| ad_groups   | User Groups          | Other - ad_groups                |
| ad_branches | Organization Units   | Other - ad_branches              |

<br />

For each object (appearing in the panel on the right), check the following fields and what should be checked:

|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Field Name | What to Look Out For                                                                                                                                                                  |
| au         | 1. Check that this LDAP Account Unit is relevant to the gateways on which the group is being used. 2. Check that users and their groups are associated to the same LDAP Account Unit. |
| branch     | Check that the branch for this user/group is configured as a branch on the au (LDAP Account Unit)                                                                                     |

For user groups (objects in the **ad_groups** table (Other - ad_groups) and **external_group** objects in the **users** table (Users - users, objects whose *Class Name* column is *external_group*)) check:

1. That the defined group is not a Universal Group. If it is - do not use it, instead use a Local Domain user group.
2. Users that belong to the defined group are under the branches defined for the LDAP Account Unit (**au** field on this group).
3. That the hierarchy between the users and the defined group does not go through groups on other domains.

**Notes:**

* LDAP Nested groups is applicable for Identity Awareness starting from **R75.40** (if enabled - see relevant documentation).  

* If the LDAP Account Unit is configured to access a Global Catalog (on port 3268) and the Global Catalog is authoritative to the user's domain - then Universal Groups will be seen in the LDAP response (but not all domain local groups).  

* If the LDAP Account Unit is configured to access an LDS (a DC with the Active Directory Lightweight Directory Services role), then the LDS actually encapsulates all these groups in order for the LDAP client to see the full picture.

**Related solution:**

* [sk104248 - "Multiple account units are using the same domain name" warning during security policy installation](http://supportcontent.checkpoint.com/solutions?id=sk104248)

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content