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

OID

fw1template

1.3.114.7.4.2.0.1

fw1person

1.3.114.7.4.2.0.2

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

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

See User Directory Schema Attributes.

User Directory Schema Attributes

The entry's name.

This is also referred to as "Common Name".

For users this can be different from the uid attribute, the name used to login to the Security Gateway.

This attribute is also used to build the User Directory entry's distinguished name, that is, it is the RDN of the DN.

The user's login name, that is, the name used to login to the Security Gateway.

This attribute is passed to the external authentication system in all authentication methods except for "Internal Password", and must be defined for all these authentication methods.

The login name is used by the Security Management Server to search the User Directory server(s).

For this reason, each user entry should have its own unique UID value.

It is also possible to login to the Security Gateway using the full DN.

The DN can be used when there is an ambiguity with this attribute or in "Internal Password" when this attribute may be missing.

The DN can also be used when the same user (with the same uid) is defined in more than one Account Unit on different User Directory servers.

Descriptive text about the user.

The default is "no value".

User's email address.

The default is "no value".

An entry can have zero or more values for this attribute.

  • In a template: The DN of user entries using this template. DNs that are not users (object classes that are not one of: "person", "organizationalPerson", "inetOrgPerson", or "fw1person") are ignored.

  • In a group: The DN of user.

Must be given if the authentication method (fw1auth-method) is "Internal Password". The value can be hashed using "crypt". In this case the syntax of this attribute is:

"{crypt}xxyyyyyyyyyyy"

where:

  • "xx" is the "salt"

  • "yyyyyyyyyyy" is the hashed password

It is possible (but not recommended) to store the password without hashing. However, if hashing is specified in the User Directory server, you should not specify hashing here, in order to prevent the password from being hashed twice. You should also use SSL in this case, to prevent sending an unencrypted password.

The Security Gateway never reads this attribute, though it does write it. Instead, the User Directory bind operation is used to verify a password.

One of these:

  • RADIUS

  • TACACS

  • SecurID

  • OS Password

  • Defender

This default value for this attribute is overridden by Default authentication scheme in the Authentication tab of the Account Unit window in SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on..

For example: a User Directory server can contain User Directory entries that are all of the object-class "person" even though the proprietary object-class "fw1person" was not added to the server's schema.

If Default authentication scheme in SmartConsole is "Internal Password", all the users will be authenticated using the password stored in the "userPassword" attribute.

"X" in OID

fw1person

fw1template

default

1

y

y

"undefined"

The name of the server that will do the authentication.

This field must be given if fw1auth-method is "RADIUS" or "TACACS".

For all other values of fw1auth-method, it is ignored. Its meaning is given below:

method

meaning

RADIUS

name of a RADIUS server, a group of RADIUS servers, or "Any"

TACACS

name of a TACACS server

"X" in OID

fw1template

2

y

The date on which the password was last modified.

The format is yyyymmdd (for example, 20 August 1998 is 19980820).

A password can be modified through the Security Gateway as a part of the authentication process.

"X" in OID

fw1person

fw1template

default

3

y

y

If no value is given, then the password has never been modified.

The last date on which the user can login to a Security Gateway, or "no value" if there is no expiration date.

The format is yyyymmdd (for example, 20 August 1998 is 19980820).

The default is "no value".

"X" in OID

fw1person

fw1template

default

8

y

y

"no value"

The time from which the user can login to a Security Gateway.

The format is hh:mm (for example, 8:15 AM is 08:15).

"X" in OID

fw1person

fw1template

default

9

y

y

"00:00"

The time until which the user can login to a Security Gateway.

The format is hh:mm (for example, 8:15 AM is 08:15).

"X" in OID

fw1person

fw1template

default

10

y

y

"23:59"

The days (of week) on which the user can login to a Security Gateway.

Can have the values "SUN","MON", and so on.

"X" in OID

fw1person

fw1template

default

11

y

y

all days of the week

The names of one or more network objects from which the user can run a client, or "Any" to remove this limitation, or "no value" if there is no such client.

The names should match the name of network objects defined in Security Management Server.

"X" in OID

fw1person

fw1template

default

12

y

y

"no value"

The names of one or more network objects which the user can access, or "Any" to remove this limitation, or "no value" if there is no such network object.

The names should match the name of network objects defined on the Security Management Server.

"X" in OID

fw1person

fw1template

default

13

y

y

"no value"

Not currently used.

"X" in OID

fw1person

fw1template

default

14

y

y

"no value"

The algorithm used to encrypt the session key in SecuRemote.

Can be "CLEAR", "FWZ1", "DES", or "Any".

"X" in OID

fw1person

fw1template

default

15

y

y

"Any"

The algorithm used to encrypt the data in SecuRemote.

Can be "CLEAR", "FWZ1", "DES", or "Any".

"X" in OID

fw1person

fw1template

default

16

y

y

"Any"

The algorithm used to sign the data in SecuRemote.

Can be "none" or "MD5".

"X" in OID

fw1person

fw1template

default

17

y

y

"none"

The number of minutes after which a SecuRemote user must re-authenticate himself or herself to the Security Gateway.

"X" in OID

fw1person

fw1template

18

y

y

The exception to generate on successful authentication via SecuRemote.

Can be "none", "cryptlog", or "cryptalert".

"X" in OID

fw1person

fw1template

default

19

y

y

"none"

This flag is used to resolve a problem related to group membership.

The group membership of a user is stored in the group entries to which it belongs, in the user entry itself, or in both entries.

Therefore there is no clear indication in the user entry if information from the template about group relationship should be used.

If this flag is "TRUE", then the user is taken to be a member of all the groups to which the template is a member.

This is in addition to all the groups in which the user is directly a member.

"X" in OID

fw1person

fw1template

default

20

y

y

"False"

The key encryption methods for SecuRemote users using IKE.

This can be one or more of: "DES", "3DES".

A user using IKE (formerly known as ISAMP) may have both methods defined.

"X" in OID

fw1person

fw1template

default

21

y

y

"DES", "3DES"

The allowed authentication methods for SecuRemote users using IKE, (formerly known as ISAMP).

This can be one or more of: "preshared", "signatures".

"X" in OID

fw1person

fw1template

default

22

y

y

"signatures"

The data integrity method for SecuRemote users using IKE, (formerly known as ISAMP).

This can be one or more of: "MD5", "SHA1".

A user using IKE must have both methods defined.

"X" in OID

fw1person

fw1template

default

23

y

y

"MD5", "SHA1"

The IPSec Transform method for SecuRemote users using IKE, (formerly known as ISAMP).

This can be one of: "AH", "ESP".

"X" in OID

fw1person

fw1template

default

24

y

y

"ESP"

The data integrity method for SecuRemote users using IKE, (formerly known as ISAMP).

This can be one of: "MD5", "SHA1".

"X" in OID

fw1person

fw1template

default

25

y

y

"SHA1"

The pre-shared secret for SecuRemote users using IKE, (formerly known as ISAMP).

The value can be calculated using the fw ikecrypt command line.

"X" in OID

fw1person

fw1template

26

y

y

fw1ISAKMP-DataEncMethod

The data encryption method for SecuRemote users using IKE, (formerly known as ISAMP).

"X" in OID

fw1person

fw1template

default

27

y

y

"DES"

The encryption method allowed for SecuRemote users.

This can be one or more of: "FWZ", "ISAKMP" (meaning IKE).

"X" in OID

fw1person

fw1template

default

28

y

y

"FWZ"

Defines when and by whom the password should and can be changed.

"X" in OID

fw1person

29

y

Number of allowed wrong passwords entered sequentially.

"X" in OID

fw1person

30

y

Time of the last login failure.

"X" in OID

fw1person

31

4

DN of the template that the user is a member of.

"X" in OID

fw1person

33

4

To add the propriety schema to your Netscape directory server, use the $FWDIR/lib/ldap/schema.ldif file.

Important - This deletes the object class definition from the schema and adds the updated one in its place.

We recommend that you back up the User Directory server before you run the command.

The ldif file:

  • Adds the new attributes to the schema

  • Deletes old definitions of fw1person and fw1template

  • Adds new definitions of fw1person and fw1template

To change the Netscape LDAP schema, run the ldapmodify command with the schema.ldif file.

Note - On some server versions, the delete objectclass operation can return an error, even if it was successful. Use ldapmodify with the -c (continuous) option.

The User Directory profile is a configurable LDAP policy that lets you define more exact User Directory requests and enhances communication with the server.

Profiles control most of the LDAP server-specific knowledge. You can manage diverse technical solutions, to integrate LDAP servers from different vendors.

Use User Directory profiles to make sure that the user management attributes of a Security Management Server are correct for its associated LDAP server.

For example, if you have a certified OPSEC User Directory server, apply the OPSEC_DS profile to get enhanced OPSEC-specific attributes.

LDAP servers have difference object repositories, schemas, and object relations.

  • The organization's user database may have unconventional object types and relations because of a specific application.

  • Some applications use the cn attribute in the User object's Relatively Distinguished Name (RDN) while others use uid.

  • In Microsoft Active Directory, the user attribute memberOf describes which group the user belongs to, while standard LDAP methods define the member attribute in the group object itself.

  • Different servers implement different storage formats for passwords.

  • Some servers are considered v3 but do not implement all v3 specifications. These servers cannot extend the schema.

  • Some LDAP servers already have built in support for certain user data, while others require a Check Point schema extended attribute.

    For example, Microsoft Active Directory has the accountExpires user attribute, but other servers require the Check Point attribute fw1expirationdate, which is part of the Check Point defined fw1person objectclass.

  • Some servers allow queries with non-defined types, while others do not.

These profiles are defined by default:

  • OPSEC_DS - the default profile for a standard OPSEC certified User Directory.

  • Netscape_DS - the profile for a Netscape Directory Server.

  • Novell_DS - the profile for a Novell Directory Server.

  • Microsoft_AD - the profile for Microsoft Active Directory.

Profiles have these major categories:

  • Common - Profile settings for reading and writing to the User Directory.

  • Read - Profile settings only for reading from the User Directory.

  • Write - Profile settings only for writing to the User Directory.

Some of these categories list the same entry with different values, to let the server behave according to type of operation. You can change certain parameters of the default profiles for finer granularity and performance tuning.

To apply a profile:

  1. Open the Account Unit.

  2. Select the profile.

To change a profile:

  1. Create a new profile.

  2. Copy the settings of a User Directory profile into the new profile.

  3. Change the values.

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

The unique username User Directory attribute (uid).

In addition, when fetching users by the username, this attribute is used for query.

Default

Other

  • uid (most servers)

  • SamAccountName (in Microsoft_AD)

One value allowed

This user password is User Directory attribute.

Default

Other

  • userPassword (most servers)

  • unicodePwd (in Microsoft_AD)

One value allowed

The object class for Check Point User Directory templates.

If you change the default value with another object-class, make sure to extend that objectclass schema definition with relevant attributes from fw1template.

default

Other

fw1template

Multiple values allowed

The account expiration date is User Directory attribute.

This could be a Check Point extended attribute or an existing attribute.

Default

Other

  • fw1expiration-date (most servers)

  • accountExpires (in Microsoft_AD)

One value allowed

Expiration date format.

This format will be applied to the value defined at ExpirationDateAttr.

Default

Other

CP format is yyyymmdd

One value allowed

The format of the password modified date is User Directory attribute.

This formation will be applied to the value defined at PsswdDateAttr.

Default

Other

  • CP (most servers) format is yyyymmdd

  • MS (in Microsoft_AD)

One value allowed

The password last modified date is User Directory attribute.

Default

Other

  • fw1pwdLastMod (most servers)

  • pwdLastSet (in Microsoft_AD)

One value allowed

User Directory attribute to store and read bad password authentication count.

Default

Other

fw1BadPwdCount

One value allowed

If 0, the sent password will not be encrypted.

If 1, the sent password will be encrypted with the algorithm specified in the DefaultCryptAlgorithm.

Default

Other

  • 0 for most servers

  • 1 for Netscape_DS

if not using encrypted password, SSL is recommended

One value allowed

The algorithm used to encrypt a password before updating the User Directory server with a new password.

Default

Other

  • Plain (for most servers)

  • Crypt (for Netscape_DS)

  • SHAI1

One value allowed

The text to prefix to the encrypted password when updating the User Directory server with a modified password.

Default

Other

{Crypt} (for Netscape_DS)

One value allowed

User Directory attribute to store and read the user phone number.

Default

Other

internationalisednumber

One value allowed

General purpose attribute translation map, to resolve problems related to peculiarities of different server types.

For example, an X.500 server does not allow the "-" character in an attribute name.

To enable the Check Point attributes containing "-", specify a translation entry: (e.g., "fw1-expiration =fw1expiration").

Default

Other

none

Multiple values allowed

All attribute names listed here will be removed from the default list of attributes included in read/write operations.

This is most useful in cases where these attributes are not supported by the User Directory server schema, which might fail the entire operation.

This is especially relevant when the User Directory server schema is not extended with the Check Point schema extension.

Default

Other

There are no values by default.

In case the User Directory server was not extended by the Check Point schema,

the best thing to do is to list here all the new Check Point schema attributes.

Multiple values allowed

Use this attribute to define which type of objects (objectclass) is queried when the object tree branches are displayed after the Account Unit is opened in SmartConsole.

Default

Other

  • Organization OrganizationalUnit Domain (most servers)

  • Container (extra for Microsoft_AD)

Multiple values allowed

If "One" is set, an "OR"ed query will be sent and every object that matches the criteria will be displayed as a branch.

If "All" is set, an "AND"ed query will be sent and only objects of all types will be displayed.

Default

Other

One

One value allowed

This attribute defines what objects should be displayed with an organization object icon.

A new object type specified here should also be in BranchObjectClass.

Default

Other

organization

Multiple values allowed

This attribute defines what objects should be displayed with an organization object icon.

A new object type specified here should also be in BranchObjectClass.

Default

Other

  • organizationalUnit (most servers)

  • Contained (added to Microsoft_AD)

Multiple values allowed

This attribute defines what objects should be displayed with a Domain object icon.

A new object type specified here should also be in BranchObjectClass.

Default

Other

Domain

Multiple values allowed

This attribute defines what objects should be read as user objects.

The user icon will be displayed on the tree for object types specified here.

Default

Other

  • User (in Microsoft_AD)

  • Person

OrganizationalPerson

InertOrgPerson

FW1 Person (most servers)

Multiple values allowed

If "One" is set, an "OR"ed query will be sent and every object that matches one of the types will be displayed as a user.

If "All" is set, an "AND"ed query will be sent and only objects of all types will be displayed.

Default

Other

One

One value allowed

This attribute defines what objects should be read as groups.

The group icon will be displayed on the tree for objects of types specified here.

Default

Other

Groupofnames

Groupofuniquenames (most servers)

Group

Groupofnames (in Microsoft_AD)

Multiple values allowed

If "One" is set, an "OR"ed query will be sent and every object that matches one of the types will be displayed as a user.

If "All" is set, an "AND"ed query will be sent and only objects of all types will be displayed.

Default

Other

One

One value allowed

Defines the relationship Mode between the group and its members (user or template objects) when reading group membership.

Default

Other

  • Member mode defines the member DN in the Group object (most servers)

  • MemberOf mode defines the group DN in the member object (in Microsoft_AD)

  • Modes define member DN in Group object and group DN in Member object.

One value allowed

Defines what User Directory attribute to use when reading group membership from the user or template object if GroupMembership mode is 'MemberOf' or 'Both' you may be required to extend the user/template object schema in order to use this attribute.

Default

Other

MemberOf

One value allowed

Defines the user to template membership mode when reading user template membership information.

Default

Other

  • Member mode defines the member DN in the Group object (most servers)

  • MemberOf mode defines the group DN in the member object (in Microsoft_AD)

One value allowed

Defines which attribute to use when reading the User members from the template object, as User DNs, if the TemplateMembership mode is Member.

Default

Other

member

Multiple values allowed

Defines which attribute to use when reading from the User object the template DN associated with the user, if the TemplateMembership mode is MemberOf.

Default

Other

member

Multiple values allowed

This value will be used as the attribute name in the Relatively Distinguished Name (RDN) when you create a new organizational unit in SmartConsole.

Default

Other

o

One value allowed

This value is used as the attribute name in the Relatively Distinguished Name (RDN) when you create a new organizational Unit in SmartConsole.

Default

Other

ou

One value allowed

This value is used as the attribute name in the Relatively Distinguished Name (RDN), when you create a new User object in SmartConsole.

Default

Other

cn

One value allowed

This value is used as the attribute name for the RDN, when you create a new Group object in SmartConsole.

Default

Other

cn

One value allowed

This value is used as the attribute name for the RDN, when you create a new Domain object in SmartConsole.

Default

Other

dc

One value allowed

This field is relevant when you create objects in SmartConsole.

The format of this field is Objectclass:name:value meaning that if the object created is of type ObjectClass then additional attributes will be included in the created object with name 'name' and value 'value'.

Default

Other

user:userAccountControl:66048

For Microsoft_AD This means that when a user object is created an extra attribute is included automatically: userAccountControl with the value 66048

Multiple values allowed

This field is used when you modify a group in SmartConsole.

The format of this field is ObjectClass:memberattr meaning that for each group objectclass there is a group membership attribute mapping.

List here all the possible mappings for this User Directory server profile.

When a group is modified, based on the group's objectclass the right group membership mapping is used.

Default

Other

groupOfNames:member

groupOfUniqueNames:uniqueMember

(All other servers)

Multiple values allowed

This determines which ObjectClass to use when creating/modifying an OrganizationalUnit object.

These values can be different from the read counterpart.

Default

Other

OrganizationalUnit

Multiple values allowed

This determines which ObjectClass to use when creating and/or modifying an Organization object.

These values can be different from the read counterpart.

Default

Other

Organization

Multiple values allowed

This determines which ObjectClass to use when creating and/or modifying a user object.

These values can be different from the read counterpart.

Default

Other

User (in Microsoft_AD)

person

organizationalPerson

inetOrgPerson

fw1Person

(All other servers)

Multiple values allowed

Determines which ObjectClass to use when creating and/or modifying a domain context object.

These values can be different from the read counterpart.

Default

Other

Domain

Multiple values allowed

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

CN=Configuration,DCROOT

CN=Schema,CN=Configuration,DCROOT

CN=System,DCROOT

CN=Users,DCROOT

CN=Builtin,DCROOT

CN=Computers,DCOOT

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

Performance

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.

Manageability

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

Enforcement

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.

  1. Display the Users and Computers Control console.

  2. Right-click on the domain name displayed in the left pane and choose Delegate control from the right-click menu.

    The Delegation of Control wizard window is displayed.

  3. Add an Administrator or another user from the System Administrators group to the list of users who can control the directory.

  4. Reboot the machine.

Extending the Active Directory Schema

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

  1. From the Security Gateway, go to the directory of the schema file: $FWDIR/lib/ldap.

  2. Copy schmea_microsoft_ad.ldif to the C:\ drive in the Active Directory server.

  3. From Active Directory server, with a text editor open the schema file.

  4. Find the value DOMAINNAME, and replace it with the name of your domain in LDIF format.

    For example, the domain sample.checkpoint.com in LDIF format is: DC=sample,DC=checkpoint,DC=com

  5. Make sure that there is a dash character - at the end of the modify section.

    This is an example of the modify section.

    dn: CN=User,CN-Schema,CN=Configuration,DC=sample,DC=checkpoint,DC=com

    changetype: modify

    add: auxiliaryClass

    auxiliaryClass: 1.3.114.7.3.2.0.2

    -

  6. Run:

    ldifde -i -f c:/schema_microsoft_ad.ldif

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:

dn:CN=fw1auth-method,CN=Schema,CN=Configuration,DCROOT

changetype: add

adminDisplayName: fw1auth-method

attributeID: 1.3.114.7.4.2.0.1

attributeSyntax: 2.5.5.4

cn: fw1auth-method

distinguishedName:

CN=fw1auth-method,CN=Schema,CN=Configuration,DCROOT

instanceType: 4

isSingleValued: FALSE

LDAPDisplayName: fw1auth-method

name: fw1auth-method

objectCategory:

CN=Attribute-Schema,CN=ConfigurationCN=Schema,CN=Configuration,DCROOT

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