LDAP and User Directory

Check Point User DirectoryClosed Check Point Software Blade on a Management Server that integrates LDAP and other external user management servers with Check Point products and security solutions. integrates LDAP, and other external user management technologies, with the Check Point solution.

If you have a large user count, we recommend that you use an external user management database such as LDAP for enhanced Security Management ServerClosed Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server. performance.

You can choose to manage Domains on the Check Point users' database, or to implement an external LDAP server.

Note - User Directory requires a special license. If you have the Mobile AccessClosed Check Point Software Blade on a Security Gateway that provides a Remote Access VPN access for managed and unmanaged clients. Acronym: MAB. Software BladeClosed Specific security solution (module): (1) On a Security Gateway, each Software Blade inspects specific characteristics of the traffic (2) On a Management Server, each Software Blade enables different management capabilities., you have the User Directory license.

User Directory lets you configure:

User Directory and Identity Awareness

Identity AwarenessClosed Check Point Software Blade on a Security Gateway that enforces network access and audits data based on network location, the identity of the user, and the identity of the computer. Acronym: IDA. uses User Directory.

Identity Awareness lets you enforce network access and audit data, based on network location, the identity of the user, and the identity of the computer.

You can use Identity Awareness in the Access Control, Threat Prevention, and DLP RuleClosed Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session. Bases.

User Directory Considerations

Before you begin, plan your use of User Directory.

  • Decide whether you will use the User Directory servers for user management, CRL retrieval, user authentication, or all of those.

    See Working with LDAP Account Units.

  • Decide how many Account Units you will need.

    You can have one for each User Directory server, or you can divide branches of one User Directory server among different Account Units.

    See Account Units.

  • Decide whether you will use High Availability setup.

    See Account Units and High Availability.

  • Determine the order of priority among the User Directory servers for High Availability and querying purposes.

    See Setting High Availability Priority.

  • Assign users to different Account Units, branches, and sub-branches, so that users with common attributes (such as their role in the organization, permissions, an so on) are grouped together.

    See Managing Users on a User Directory Server.

The User Directory Schema

The User Directory default schema is a description of the structure of the data in a user directory.

It has user definitions defined for an LDAP server.

This schema does not have Security Management Server or Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. specific data, such as IKE-related attributes, authentication methods, or values for remote users.

You can use the default User Directory schema, if all users have the same authentication method and are defined according to a default template.

But if users in the database have different definitions, it is better to apply a Check Point schema to the LDAP server.

See Check Point Schema for LDAP.

Check Point Schema for LDAP

The Check Point Schema adds Security Management Server and Security Gateway specific data to the structure in the LDAP server.

Use the Check Point Schema to extend the definition of objects with user authentication functionality.

For example, an Object Class entitled fw1Person is part of the Check Point schema.

This Object Class has mandatory and optional attributes to add to the definition of the Person attribute.

Another example is fw1Template.This is a standaloneClosed Configuration in which the Security Gateway and the Security Management Server products are installed and configured on the same server. attribute that defines a template of user information.

Schema Checking

When schema checking is enabled, User Directory requires that every Check Point object class and its associated attributes is defined in the directory schema.

Before you work with User Directory, make sure that schema checking is disabled. Otherwise the integration will fail.

After the Check Point object classes and attributes are applied to the User Directory server's schema, you must enable schema checking again.

OID Proprietary Attributes

Each of the proprietary object classes and attributes (all of which begin with "fw1") has a proprietary Object Identifier (OID), listed below.

Object Class OIDs

object class




The OIDs for the proprietary attributes begin with the same prefix ("").

Only the value of "X" is different for each attribute.

See User Directory Schema Attributes.

User Directory Schema Attributes

Fetch User Information Effectively

User Directory servers organize groups and members through different means and relations. User Directory operations are performed by Check Point on users, groups of users, and user templates where the template is defined as a group entry and users are its members. The mode in which groups/templates and users are defined has a profound effect on the performance of some of the Check Point functionality when fetching user information. There are three different modes:

  • Defining a "Member" attribute per member, or "Member" user-to-group membership mode. In this case, each member of a specific group gets the 'Member" attribute, where the value of this attribute is the DN of that member.

  • Defining a "Memberof" attribute per group, or "MemberOf" user-to-group membership mode. In this case, each group gets the "Memberof" attribute per group, where the value of this attribute is the DN of a group entry. This is referred to as "MemberOf" user-to-group membership mode.

  • Defining a "Memberof" attribute per member and group, or "Both" user-to-group membership mode. In this case both members and groups are given the "Memberof" attribute.

The most effective mode is the "MemberOf" and "Both" modes where users' group membership information is available on the user itself and no additional User Directory queries are necessary.

Setting User-to-Group Membership Mode

Set the user-to-group membership mode in the profile objects for each User Directory server in the objects_5_0.C file.

  • To specify the user-to-group and template-to-group membership mode set the GroupMembership attribute to one of the following values: "Member", "MemberOf", "Both" accordingly.

  • To specify the user-to-template membership mode set the TemplateMembership attribute to one of the following values: "Member", "MemberOf" accordingly.

After successfully converting the database, set the User Directory server profile in the objects_5_0.C file to the proper membership setting and start the Security Management Server.

Make sure to install policy/user database on all Security Gateways to enable the new configuration.

Profile Attributes

Microsoft Active Directory

The Microsoft Windows 2000 advanced server (or later) includes a sophisticated User Directory server that can be adjusted to work as a user database for the Security Management Server.

By default, the Active Directory services are disabled. In order to enable the directory services:

  • run the dcpromo command from the Start > Run menu, or

  • run the Active Directory setup wizard using the System Configuration window.

The Active Directory has the following structure:

DC=qa, DC=checkpoint,DC=com







OU=Domain Controllers,DCROOT


Most of the user objects and group objects created by Windows 2000 tools are stored under the CN=Users, DCROOT branch, others under CN=Builtin, DCROOT branch, but these objects can be created under other branches as well.

The branch CN=Schema, CN=Configuration, DCROOT contains all schema definitions.

Check Point can take advantage of an existing Active Directory object as well as add new types. For users, the existing user can be used "as is" or be extended with fw1person as an auxiliary of "User" for full feature granularity. The existing Active Directory "Group" type is supported "as is". A User Directory template can be created by adding the fw1template object-class. This information is downloaded to the directory using the schema_microsoft_ad.ldif file (see Adding New Attributes to the Active Directory).


The number of queries performed on the directory server is significantly low with Active Directory. This is achieved by having a different object relations model. The Active Directory group-related information is stored inside the user object. Therefore, when fetching the user object no additional query is necessary to assign the user with the group. The same is true for users and templates.


SmartConsole allows the creation and management of existing and new objects. However, some specific Active Directory fields are not enabled in SmartConsole.


It is possible to work with the existing Active Directory objects without extending the schema. This is made possible by defining an Internal Template object and assigning it with the User Directory Account Unit defined on the Active Directory server.

For example, if you wish to enable all users with IKE+Hybrid based on the Active Directory passwords, create a new template with the IKE properties enabled and "Check Point password" as the authentication method.

Updating the Registry Settings

To modify the Active Directory schema, add a new registry DWORD key named Schema Update Allowed with the value different from zero under HKLM\System\CurrentControlSet\Services\NTDS\Parameters.

Delegating Control

Delegating control over the directory to a specific user or group is important since by default the Administrator is not allowed to modify the schema or even manage directory objects through User Directory protocol.

Extending the Active Directory Schema

Modify the file with the Active Directory schema, to use SmartConsole to configure the Active Directory users.

Adding New Attributes to the Active Directory

Below is the example in LDAP Data Interchange (LDIF) format that adds one attribute to the Microsoft Active Directory:


changetype: add

adminDisplayName: fw1auth-method



cn: fw1auth-method



instanceType: 4

isSingleValued: FALSE

LDAPDisplayName: fw1auth-method

name: fw1auth-method



ObjectClass: attributeSchema

oMSyntax: 20

rangeLower: 1

rangeUpper: 256

showInAdvancedViewOnly: TRUE

All Check Point attributes can be added in the same way.

The definitions of all attributes in LDIF format are contained in the schema_microsoft_ad.ldif file located in the $FWDIR/lib/ldap directory.

Before attempting to run the ldapmodify command, edit schema_microsoft_ad.ldif and replace all instances of DCROOT with the domain root of your organization. For example if your domain is support.checkpoint.com, replace DCROOT with dc=support,dc=checkpoint,dc=com.

After modifying the file, run the ldapmodify command to load the file into the directory. For example if you use the Administrator account of the dc=support,dc=checkpoint,dc=com domain the command syntax will be as follows:

Note - A shell script is available for UNIX gateways. The script is at: $FWDIR/lib/ldap/update_schema_microsoft_ad

ldapmodify -c -h support.checkpoint.com -D cn=administrator,cn=users,dc=support,dc=checkpoint,dc=com" -w SeCrEt -f $FWDIR/lib/ldap/schema_microsoft_ad.ldif