Managing User Accounts

Authentication Methods for Users and Administrators

Check Point supports different methods of authenticating end users and administrators.

Security Gateways authenticate individual users. The Security Management Server authenticates administrators.

Users and Administrators authenticate using credentials. All the methods required a username and password.

Users and administrators can be stored in the Check Point User Database or on an LDAP server.

The following sections describe the supported authentication methods.

Check Point Password

Check Point password is a static password that is configured in SmartConsole. For administrators, the password is stored in the local database on the Security Management Server. For users, it is stored on the local database on the Security Gateway. No additional software is required.

Operating System Password

OS Password is stored on the operating system of the computer on which the Security Gateway (for users) or Security Management Server (for administrators) is installed. You can also use passwords that are stored in a Windows domain. No additional software is required.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is an external authentication method that provides security and scalability by separating the authentication function from the access server.

Using RADIUS, the Security Gateway forwards authentication requests by remote users to the RADIUS server. For administrators, the Security Management Server forwards the authentication requests. The RADIUS server, which stores user account information, does the authentication.

The RADIUS protocol uses UDP to communicate with the gateway or the Security Management Server.

RADIUS servers and RADIUS server group objects are defined in SmartConsole.

SecurID

SecurID requires users to both possess a token authenticator and to supply a PIN or password. Token authenticators generate one-time passwords that are synchronized to an RSA ACE/server and may come in the form of hardware or software. Hardware tokens are key-ring or credit card-sized devices, while software tokens reside on the PC or device from which the user wants to authenticate. All tokens generate a random, one-time use access code that changes approximately every minute. When a user attempts to authenticate to a protected resource, the one-time use code must be validated by the ACE/server.

Using SecurID, the Security Gateway forwards authentication requests by remote users to the ACE/server. For administrators, it is the Security Management Server that forwards the requests. ACE manages the database of RSA users and their assigned hard or soft tokens. The gateway or the Security Management Server act as an ACE/Agent 5.0 and direct all access requests to the RSA ACE/server for authentication. For additional information on agent configuration, refer to ACE/server documentation.

There are no specific parameters required for the SecurID authentication method.

TACACS

Terminal Access Controller Access Control System (TACACS) provides access control for routers, network access servers and other networked devices through one or more centralized servers.

TACACS is an external authentication method that provides verification services. Using TACACS, the Security Gateway forwards authentication requests by remote users to the TACACS server. For administrators, it is the Security Management Server that forwards the requests. The TACACS server, which stores user account information, authenticates users. The system supports physical card key devices or token cards and Kerberos secret key authentication. TACACS encrypts the user name, password, authentication services and accounting information of all authentication requests to ensure secure communication.

Configuring Authentication Methods for Users

These instructions show how to configure authentication methods for users. For administrators, see Configuring Authentication Methods for Administrators.

For background information about the authentication methods, see Authentication Methods for Users and Administrators.

Granting User Access Using RADIUS Server Groups

The Security Gateway lets you control access privileges for authenticated RADIUS users, based on the administrator's assignment of users to RADIUS groups. These groups are used in the Security Rule Base to restrict or give users access to specified resources. Users are unaware of the groups to which they belong.

To use RADIUS groups, you must define a return attribute in the RADIUS user profile of the RADIUS server. This attribute is returned to the Security Gateway and contains the group name (for example, RAD_<group to which the RADIUS users belong>) to which the users belong.

Use these RADIUS attributes (refer to RFC 2865):

• For SecurePlatform - attribute "Class" (25)
• For other operating systems, including Gaia, Windows, and IPSO-attribute "Vendor-Specific" (26)

Configuring a Security Gateway to use SecurID Authentication

Sample workflow for SecurID authentication configuration:

1. Configure gateways for SecurID authentication.
2. Define user groups.
3. Configure SecurID authentication settings for users.

   The procedure for doing this is different for Internal Users (that are defined in the internal User Database on the Security Management Server) and for External Users.

4. Complete the SecurID authentication configuration.

To configure a Security Gateway to use SecurID:

1. Generate the sdconf.rec file on the ACE/Server and copy it to:
   • /var/ace/sdconf.rec on UNIX, Linux or IPSO
   • %SystemRoot%\System32\sdconf.rec on 32-bit Windows
   • %SystemRoot%\SysWOW64\sdconf.rec on 64-bit Windows

   On a Virtual System, follow the instructions in sk97908.

2. In SmartConsole, go to the Gateways & Servers view, right-click a Security Gateway object and select Edit.
3. In the gateway property window that opens, select Other > Legacy Authentication.
4. In the Enabled Authentication Schemes section, select SecurID.
5. Click OK.

To define a user group:

1. In SmartConsole, open the Objects Bar (F11).
2. Click New > More > User > User Group.

   The New User Group window opens.

3. Enter the name of the group, for example SecurID_Users.

   Make sure the group is empty.

4. Click OK.
5. Publish the changes and install the policy.

To configure SecurID authentication settings for Internal Users:

Internal users are users that are defined in the internal User Database on the Security Management Server.

1. Create a new user. In SmartConsole, open the Objects Bar (F11).
2. Click New > More > User > User.

   The New User window opens.

3. Choose a template.
4. Click OK.
5. In the General page:
   • Enter a default Name. This name will be used to authenticate users on the ACE/Server.
   • Set the Expiration date.
6. In the Authentication page, from the Authentication Method drop-down list, select SecurID.
7. Click OK.

To configure SecurID authentication settings for External Users:

External users are users that are not defined in the internal Users Database on the Security Management Server.

1. In SmartConsole, click Manage & Settings > Blades.
2. In the Mobile Access section, click Configure in SmartDashboard.

   Legacy SmartDashboard opens.

3. In the bottom left Network Objects pane, and click Users.

   

4. Right-click on an empty space and select the applicable option:
   • If you support only one external authentication scheme, select New > External User Profile > Match all users.
   • If you support more than one external authentication scheme, select New > External User Profile > Match by domain.
5. Configure the External User Profile properties:
   1. General Properties page:
      • If selected Match all users, then configure:

      In the External User Profile name field, leave the default name generic*.

      In the Expiration Date field, set the applicable date.

      • If selected Match by domain, then configure:

      In the External User Profile name field, enter the applicable name. This name will be used to authenticate users on the ACE/Server.

      In the Expiration Date field, set the applicable date.

      In the Domain Name matching definitions section, configure the applicable settings.

   2. Authentication page:

      From the Authentication Scheme drop-down list, select SecurID.

   3. Click OK.
6. From the top toolbar, click Update (Ctrl + S).
7. Close the Legacy SmartDashboard.

To complete the SecurID authentication configuration:

1. Make sure that connections between the gateway and the ACE/Server are not NATed in the Address Translation Rule Base.

   On a Virtual System, follow the instructions in sk107281.

2. Save, verify, and install the policy in SmartConsole.

When a Security Gateway has multiple interfaces, the SecurID agent on the Security Gateway sometimes uses the wrong interface IP to decrypt the reply from the ACE/Server, and authentication fails.

To overcome this problem, place a new text file, named sdopts.rec in the same directory as sdconf.rec. The file should contain the CLIENT_IP=<ip> line, where <ip> is the primary IP address of the Security Gateway, as defined on the ACE/Server. This is the IP address of the interface to which the server is routed.

Configuring TACACS+ Authentication

To configure a Security Gateway to use TACACS+ authentication, you must set up the server and enable its use on the Security Gateway.

To define a TACACS+ server:

1. Define a TACACS Host object: Object Explorer (Ctrl+E) > New > Host
2. Enter a name and IP address.
3. Define a TACACS server: Object Explorer (Ctrl+E) > New > Server > More > TACACS.
4. Enter a name.
5. In Host, select the TACACS host.
6. Select the Type.

   Best Practice: The default is TACACS, but TACACS+ is recommended.

7. In Service, select the TACACSplus service (or TACACS UDP service if you selected TACACS type).
8. Enter a Secret key. (If you selected TACACS type, this is not available. If you selected TACACS+, it is required.)
9. Click OK.

To enable TACACS on the Security Gateway:

1. Right-click the gateway object and select Edit.
2. Click Other > Legacy Authentication.
3. In the Enabled Authentication Schemes section, click TACACS.
4. Click OK.

To enable TACACS authentication for users:

1. In the Object Explorer, click Users > User Templates.
2. Edit the Default user template.
3. In the Authentication page, Authentication method list, select TACACS.
4. When TACACS server shows, select the TACACS server you defined.
5. Click OK.

   When you create a new user account, TACACS is the default selected authentication.

User Database

Users defined in SmartConsole are saved to the User Database on the Security Management Server, together with the user authentication schemes and encryption keys. Then, the user database is installed on Security Gateways and Check Point hosts:

• On Security Gateways - When the policy is installed (Install Policy)
• On Check Point hosts with an active Management blade (such as Log Server) - When the database is installed (Install Database)

The user database does not contain information about users defined elsewhere than on the Security Management Server (such as users in external User Directory groups), but it does contain information about the external groups themselves (for example, on which Account Unit the external group is defined). Changes to external groups take effect only after the policy is installed, or the user database is downloaded from the management server.

Creating, Modifying, Removing User Accounts

To create a new user:

1. In the Object Bar (F11)tree, click New > More > User > User.

   The New User window opens.

2. Choose a template and click OK.
3. Configure required and optional settings in General Properties.
4. Select and configure Authentication.

   Important! If you do not select an authentication method, the user cannot log in or use network resources.

5. In Location, select objects from which this user can access or send data and traffic.
6. If the user has specified working days or hours, configure when the user can be authenticated for access.
7. Click OK.

To change an existing user:

1. In the object tree, click Users > Users.
2. Double-click a user.

   The User Properties window opens.

3. Change the properties as necessary.
4. Click OK.

User > General Properties

Required settings:

• User Name - A unique, case sensitive character string.

  If you generate a user certificate with a non-Check Point Certificate Authority, enter the Common Name (CN) component of the Distinguished Name (DN). For example, if the DN is: [CN = James, O = My Organization, C = My Country],
  enter James as the user name. If you use Common Names as user names, they must contain exactly one string with no spaces.

• Expiration Date - The date, after which the user is no longer authorized to access network resources and applications. By default, the date defined in the Default Expiration Settings shows as the expiration date.

Optional settings:

• Comment
• Email Address
• Mobile Phone Number

Configuring Authentication

Select an Authentication Scheme:

• SecurID
• Check Point Password - Enter the password string (between 4 and 8 characters) and confirm it
• OS Password
• RADIUS - Select a RADIUS server or a group of servers
• TACACS - Select a TACACS server

User > Location

In the Allowed locations section:

Source - Click Add, to add selected objects to this user's permitted resources. The user can get data and traffic from these objects.

Destination - Click Add, to add selected objects to this user's permitted destinations. The user can send data and traffic to these objects.

User > Time

From and To - Enter start time and end time of an expected workday. This user will not be authenticated if a login attempt is made on a time outside the given range.

Days in week or Daily - Select the days that the user can authenticate and access resources. This user will not be authenticated if a login attempt is made on an unselected day.

User > Certificates

Generate and register SIC certificates for user accounts. This authenticates the user in the Check Point system. Use certificates with required authentication for added access control.

To create a new certificate:

1. Open the User Properties window > Certificates page.
2. Click New.
3. Select key or p12 file:
   • Registration key for certificate enrollment - Select to send a registration key that activates the certificate. When prompted, select the number of days the user has to activate the certificate, before the registration key expires.
   • Certificate file (p12) - Select to create a .p12 certificate file with a private password for the user. When prompted, enter and confirm the certificate password.
4. Click OK.

If a user will not be in the system for some time (for example, going on an extended leave), you can revoke the certificate. This leaves the user account in the system, but it cannot be accessed until you renew the certificate.

To revoke a certificate, select the certificate and click Revoke.

User > Encryption

If the user will access resources from a remote location, traffic between the remote user and internal resources will be encrypted. Configure encryption settings for remote access users.

To configure encryption:

1. Open the User Properties window > Encryption page.
2. Select an encryption method for the user.
3. Click Edit.

   The encryption Properties window opens.

   The next steps are for IKE Phase 2. The options can be different for different methods.

4. Open the Authentication tab.
5. Select the authentication schemes:
   1. Password - The user authenticates with a pre-shared secret password. Enter and confirm the password.
   2. Public Key - The user authenticates with a public key contained in a certificate file.
6. Click OK.
7. Click OK.

Configuring Default Expiration Settings for Users

If a user account is about to expire, notifications show when you open the properties of the user in SmartConsole.

To configure the default expiration settings:

1. From the Menu, select Global Properties.

   The Global Properties window opens.

2. Click User Accounts.
3. Select Expire at or Expire after.
   • Expire at - Select the expiration date from the calendar control.
   • Expire after - Enter the number of days (from the day the account is made) before user accounts expire.
4. Select Show accounts expiration indication, and enter the number of days.

   Expiration warnings in the SmartConsole User object show this number of days before an account expires. During this time, if the user account is to be active for longer, you can edit the user account expiration configuration. This will avoid loss of working time.

Delete a User

To delete a user:

1. In the object tree, click Users > Users.
2. Right-click the account and select Delete.

   The confirmation window opens.

3. Click Yes.

Managing User Groups

User groups are collections of user accounts. Add the user group to the Source or Destination of a rule. You cannot add individual users to a rule.

You can also edit user groups, and delete user groups that are not used in the Rule Base.

Adding User Groups

To create a new user group:

1. In the Object Bar (F11), click New> More > User > User Group.

   The New User Group window opens.

2. Enter a name for the new group.
3. For each user or a group of users, click the [+] sign and select the object from the list.
4. Configure the optional settings:
   • Mailing List Address
   • Comment
   • Tag
   • Color
5. Click OK.

To add new users or other user groups to a group:

1. In the Object Bar (F11), select Object Categories > User >User Groups
2. Right click the User group and click Edit.

   The User Group window opens.

3. Click +
4. Select users or user groups.
5. Click OK.

LDAP and User Directory

Check Point User Directory 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 Server performance.

• Users can be managed externally by an LDAP server.
• The gateways can retrieve CRLs.
• The Security Management Server can use the LDAP data to authenticate users.
• User data from other applications gathered in the LDAP user database can be shared by different applications.

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 Access Software Blade, you have the User Directory license.

User Directory lets you configure:

• High Availability, to duplicate user data across multiple servers for backup.
• Multiple Account Units, for distributed databases.
• Define LDAP Account Units, for encrypted User Directory connections.
• Profiles, to support multiple LDAP vendors.

User Directory and Identity Awareness

Identity Awareness 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 Rule 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.
• 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.
• Decide whether you will use High Availability setup.
• Determine the order of priority among the User Directory servers for High Availability and querying purposes.
• Assign users to different Account Units, branches, and sub-branches, so that users with common attributes (such as their role in the organization, permissions, etc.) are grouped together.

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

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 standalone 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

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 Attributes for the value of "X".

User Directory Schema Attributes

cn

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.

uid

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.

description

Descriptive text about the user.

mail

User's email address.

member

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.

userPassword

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" and "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.

fw1authmethod

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

fw1authserver

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:

fw1pwdLastMod

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.

fw1expiration-date

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

fw1hour-range-from

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

fw1hour-range-to

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

fw1day

The days on which the user can login to a Security Gateway. Can have the values "SUN","MON", and so on.

fw1allowed-src

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.

fw1allowed-dst

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.

fw1allowed-vlan

Not currently used.

fw1SR-keym

The algorithm used to encrypt the session key in SecuRemote. Can be "CLEAR", "FWZ1", "DES" or "Any".

fw1SR-datam

The algorithm used to encrypt the data in SecuRemote. Can be "CLEAR", "FWZ1", "DES" or "Any".

fw1SR-mdm

The algorithm used to sign the data in SecuRemote. Can be "none" or "MD5".

fw1enc-fwz-expiration

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

fw1sr-auth-track

The exception to generate on successful authentication via SecuRemote. Can be "none", "cryptlog" or "cryptalert".

fw1groupTemplate

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.

fw1ISAKMP-EncMethod

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.

fw1ISAKMP-AuthMethods

The allowed authentication methods for SecuRemote users using IKE, (formerly known as ISAMP). This can be one or more of: "preshared", "signatures".

fw1ISAKMP-HashMethods

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.

fw1ISAKMP-Transform

The IPSec Transform method for SecuRemote users using IKE, (formerly known as ISAMP). This can be one of: "AH", "ESP".

fw1ISAKMP-DataIntegrityMethod

The data integrity method for SecuRemote users using IKE, (formerly known as ISAMP). This can be one of: "MD5", "SHA1".

fw1ISAKMP-SharedSecret

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

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

fw1ISAKMP-DataEncMethod

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

fw1enc-Methods

The encryption method allowed for SecuRemote users. This can be one or more of: "FWZ", "ISAKMP" (meaning IKE).

fw1userPwdPolicy

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

fw1badPwdCount

Number of allowed wrong passwords entered sequentially.

fw1lastLoginFailure

Time of the last login failure.

memberof template

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

Netscape LDAP Schema

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

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.

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

User Directory Profiles

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.

Default User Directory Profiles

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.

Modifying User Directory Profiles

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 objects_5_0.C.

• 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 objects_5_0.C to the proper membership setting and start the Security Management server. Make sure to install policy/user database on all gateways to enable the new configuration.

Profile Attributes

UserLoginAttr

The unique username User Directory attribute (uid). In addition, when fetching users by the username, this attribute is used for query.

UserPasswordAttr

This user password is User Directory attribute.

TemplateObjectClass

The object class for Check Point User Directory templates. If you change the default value with another objectclass, make sure to extend that objectclass schema definition with relevant attributes from fw1template.

ExpirationDateAttr

The account expiration date is User Directory attribute. This could be a Check Point extended attribute or an existing attribute.

ExpirationDateFormat

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

PsswdDateFormat

The format of the password modified date is User Directory attribute. This formation will be applied to the value defined at PsswdDateAttr.

PsswdDateAttr

The password last modified date is User Directory attribute.

BadPwdCountAttr

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

ClientSideCrypt

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

DefaultCryptAlgorith

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

CryptedPasswordPrefix

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

PhoneNumberAttr

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

AttributesTranslationMap

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

ListOfAttrsToAvoid

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.

BranchObjectClass

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.

BranchOCOperator

If One is set, an ORed query will be sent and every object that matches the criteria will be displayed as a branch. If All, an ANDed query will be sent and only objects of all types will be displayed.

OrganizationObjectClass

This attribute defines what objects should be displayed with an organization object icon. A new object type specified here should also be in BranchObjectClass.

OrgUnitObjectClass

This attribute defines what objects should be displayed with an organization object icon. A new object type specified here should also be in BranchObjectClass.

DomainObjectClass

This attribute defines what objects should be displayed with a Domain object icon. A new object type specified here should also be in BranchObjectClass.

UserObjectClass

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.

UserOCOperator

If 'one' is set, an ORed query will be sent and every object that matches one of the types will be displayed as a user. If 'all' and ANDed query will be sent and only objects of all types will be displayed.

GroupObjectClass

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.

GroupOCOperator

If 'one' is set an ORed query will be sent and every object that matches one of the types will be displayed as a user. If 'all' an ANDed query will be sent and only objects of all types will be displayed.
GroupMembership

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

UserMembershipAttr

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.

TemplateMembership

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

TemplateMembershipAttr

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

UserTemplateMembershipAttr

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

OrganizationRDN

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

OrgUnitRDN

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

UserRDN

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

GroupRDN

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

DomainRDN

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

AutomaticAttrs

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

GroupObjectClass

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.

OrgUnitObjectClass

This determines which ObjectClass to use when creating/modifying an OrganizationalUnit object. These values can be different from the read counterpart.

OrganizationObjectClass

This determines which ObjectClass to use when creating and/or modifying an Organization object. These values can be different from the read counterpart.

UserObjectClass

This determines which ObjectClass to use when creating and/or modifying a user object. These values can be different from the read counterpart.

DomainObjectClass

Determines which ObjectClass to use when creating and/or modifying a domain context object. These values can be different from the read counterpart.

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:

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

To delegate control over the directory:

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.

To extend the Active Directory schema:

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:

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

Retrieving Information from a User Directory Server

When a gateway requires user information for authentication, it goes through this process:

1. The gateway searches for the user in the internal users database.
2. If the specified user is not defined in the internal users database, the gateway queries the LDAP server defined in the Account Unit with the highest priority.
3. If the query against an LDAP server with the highest priority fails (for example, the connection is lost), the gateway queries the server with the next highest priority.

   If there is more than one Account Unit, the Account Units are queried concurrently. The results of the query are taken from the first Account Unit to meet the conditions, or from all the Account Units which meet the conditions.

4. If the query against all LDAP servers fails, the gateway matches the user against the generic external user profile.

Running User Directory Queries

Use queries to get User Directory user or group data. For best performance, query Account Units when there are open connections. Some connections are kept open by the gateways, to make sure the user belongs to a group that is permitted to do a specified operation.

To query User Directory:

1. In SmartConsole, go to Manage & Settings > Blades.
2. Click Configure in SmartDashboard.

   SmartDashboard opens.

3. In the Objects Tree, click Users.
4. Double-click the Account Unit to open a connection to the LDAP server.
5. Right-click the Account Unit and select Query Users/Group.

   The LDAP Query Search window opens.

   Click Advanced to select specified objects types, such as Users, groups, or templates.

6. Define the query.
7. To add more conditions, select or enter the values and click Add.

Query conditions:

• Attributes - Select a user attribute from the drop-down list, or enter an attribute.
• Operators - Select an operator from the drop-down list.
• Value - Enter a value to compare to the entry's attribute. Use the same type and format as the actual user attribute. For example, if Attribute is fw1expiration-date, then Value must be in the yyyymmdd syntax.
• Free Form - Enter your own query expression. See RFC 1558 for information about the syntax of User Directory (LDAP) query expressions.
• Add - Appends the condition to the query (in the text box to the right of Search Method).

Example of a Query

If you create a query where:

• Attributes = mail
• Contains
• Value = Andy

The server queries the User Directory with this filter:

Querying Multiple LDAP Servers

The Security Management server and the gateways can work with multiple LDAP servers concurrently. For example, if a gateway needs to find user information, and it does not know where the specified user is defined, it queries all the LDAP servers in the system. (Sometimes a gateway can find the location of a user by looking at the user DN, when working with certificates.)

Deploying User Directory

User Directory integrates the Security Management Server and an LDAP server and lets the Security Gateways use the LDAP information.

Enabling User Directory

In SmartConsole, enable the Security Management Server to manage users in the Account Unit.

Note - You cannot use the SmartConsole User Database when the User Directory LDAP server is enabled.

To enable User Directory on the Security Management Server:

1. From the Menu, select Global Properties > User Directory.

   The User Directory page opens.

2. Select Use User Directory for Security Gateways.
3. Configure login and password settings.
4. Click OK.
5. In the Gateways & Servers view (Ctrl+1), open the Security Management Server object for editing
6. On General Properties page, Management tab, select Network Policy Management and User Directory.
7. Click OK.
8. Install the policy.

Account Units

An Account Unit represents branches of user information on one or more LDAP servers. The Account Unit is the interface between the LDAP servers and the Security Management Server and Security Gateways.

You can have a number of Account Units representing one or more LDAP servers. Users are divided among the branches of one Account Unit, or between different Account Units.

Note - When you enable the Identity Awareness and Mobile Access Software Blades, SmartConsole opens a First Time Configuration Wizard. The Active Directory Integration window of this wizard lets you create a new AD Account Unit. After you complete the wizard, SmartConsole creates the AD object and Account Unit.

Working with LDAP Account Units

Use the LDAP Account Unit Properties window in SmartConsole to edit an existing Account Unit or to create a new one manually.

To edit an existing LDAP Account Unit:

1. In SmartConsole, open the Object Explorer (press the CTRL+E keys).
2. Select Servers > LDAP Account Units.
3. Right-click the LDAP Account Unit and select Edit.

   The LDAP Account Unit Properties window opens.

4. Edit the settings in these tabs:
   • General - Configure how the Security Management Server uses the Account Unit
   • Servers - Manage LDAP servers that are used by this Account Unit
   • Objects Management - Configure the LDAP server for the Security Management Server to query and the branches to use
   • Authentication - Configure the authentication scheme for the Account Unit
5. Click OK.
6. Install the Access Control Policy.

To create a new LDAP Account Unit:

1. In the Objects tab, click New > More > Server > LDAP Account unit.

   The LDAP Account Unit Properties window opens.

2. Configure the settings on these tabs:
   • General - Configure how the Security Management Server uses the Account Unit
   • Servers - Manage LDAP servers that are used by this Account Unit
   • Objects Management - Configure the LDAP server for the Security Management Server to query and the branches to use
   • Authentication - Configure the authentication scheme for the Account Unit
3. Click OK.
4. Install the Access Control Policy.

General Tab

These are the configuration fields in the General tab:

• Name - Name for the Account Unit
• Comment - Optional comment
• Color - Optional color associated with the Account Unit
• Profile - LDAP vendor
• Domain - Domain of the Active Directory servers, when the same user name is used in multiple Account Units (this value is also necessary for AD Query and SSO)
• Prefix - Prefix for non-Active Directory servers, when the same user name is used in multiple Account Units
• Account Unit usage - Select applicable options:
  • CRL retrieval - The Security Management Server manages how the CA sends information about revoked licenses to the Security Gateways
  • User Management - The Security Management Server uses the user information from this LDAP server (User Directory must be enabled on the Security Management Server)

    Note - LDAP SSO (Single Sign On) is only supported for Account Unit objects that use User Management.

  • Active Directory Query - This Active Directory server is used as an Identity Awareness source.

    Note - This option is only available if the Profile is set to Microsoft_AD.

• Enable Unicode support - Encoding for LDAP user information in non-English languages
• Active Directory SSO configuration - Click to configure Kerberos SSO for Active Directory - Domain Name, Account Name, Password, and Ticket encryption method

Servers Tab

You can add, edit, or delete LDAP server objects.

To configure an LDAP server for the Account Unit:

1. To add a new server, click Add. To edit an existing one, select it from the table and click Edit.

   The LDAP Server Properties window opens.

2. From the Host drop-down menu, select the server object.

   If necessary, create a new SmartConsole server object:

   1. Click New.
   2. In the New Host window opens, enter the settings for the LDAP server.
   3. Click OK.
3. Enter the login credentials and the Default priority.
4. Select access permissions for the Check Point Gateways:
   • Read data from this server
   • Write data to this server
5. In the Encryption tab, configure the optional SSL encryption settings. To learn about these settings, see the Help. Click ? or press F1 in the Encryption tab.
6. Click OK.

To remove an LDAP server from the Account Unit:

1. Select a server from the table.
2. Click Remove.

If all the configured servers use the same login credentials, you can modify those simultaneously.

To configure the login credentials for all the servers simultaneously:

1. Click Update Account Credentials.

   The Update Account to All Servers window opens.

2. Enter the login credentials.
3. Click OK.

Objects Management Tab

Configure the LDAP server for the Security Management Server to query and the branches to fetch.

Note - Make sure there is LDAP connectivity between the Security Management Server and the LDAP Server that holds the management directory.

To configure LDAP query parameters:

1. From the Manage objects on drop-down menu, select the LDAP server object.
2. Click Fetch branches.

   The Security Management Server queries and shows the LDAP branches.

3. Configure Branches in use:
   • To add a branch, click Add and in the LDAP Branch Definition window that opens, enter a new Branch Path
   • To edit a branch, click Edit and in the LDAP Branch Definition window that opens, modify the Branch Path
   • To delete a branch, select it and click Delete
4. Select Prompt for password when opening this Account Unit, if necessary (optional).
5. Configure the number of Return entries that are stored in the LDAP database (the default is 500).

Authentication Tab

These are the configuration fields in the Authentication tab:

• Use common group path for queries - Select to use one path for all the LDAP group objects (only one query is necessary for the group objects)
• Allowed authentication schemes - Select one or more authentication schemes allowed to authenticate users in this Account Unit - Check Point Password, SecurID, RADIUS, OS Password, or TACACS
• Users' default values - The default settings for new LDAP users:
  • User template - Template that you created
  • Default authentication scheme - one of the authentication schemes selected in the Allowed authentication schemes section
• Limit login failures (optional):
  • Lock user's account after - Number of login failures, after which the account gets locked
  • Unlock user's account after - Number of seconds, after which the locked account becomes unlocked
• IKE pre-shared secret encryption key - Pre-shared secret key for IKE users in this Account Unit

Modifying the LDAP Server

1. On the LDAP Account Unit Properties > Servers tab, double-click a server.

   The LDAP Server Properties window opens.

2. On the General tab, you can change:
   • Port of the LDAP server
   • Login DN
   • Password
   • Priority of the LDAP server, if there are multiple servers
   • Security Gateway permissions on the LDAP server
3. On the Encryption tab, you can change the encryption settings between Security Management Server / Security Gateways and LDAP server.

   If the connections are encrypted, enter the encryption port and strength settings.

   Note - User Directory connections can be authenticated by client certificates from a Certificate Authority (CA). To use certificates, the LDAP server must be configured with SSL strong authentication.

Account Units and High Availability

With User Directory replications for High Availability, one Account Unit represents all the replicated User Directory servers. For example, two User Directory server replications can be defined on one Account Unit, and two Security Gateways can use the same Account unit.

Setting High Availability Priority

With multiple replications, define the priority of each LDAP server in the Account Unit. Then you can define a server list on the Security Gateways.

Select one LDAP server for the Security Management server to connect to. The Security Management server can work with one LDAP server replication. All other replications must be synchronized for standby.

To set priority on the Account Unit:

1. Open the LDAP Account Unit Properties window.
2. Open the Servers tab.
3. Add the LDAP servers of this Account Unit in the order of the priority that you want.

Authenticating with Certificates

The Security Management Server and Security Gateways can use certificates to secure communication with LDAP servers. If you do not configure certificates, the management server, Security Gateways, and LDAP servers communicate without authentication.

To configure User Directory to use certificates:

1. On each Account Unit, to which you want to authenticate with a certificate, set the ldap_use_cert_auth attribute to true:
   1. Connect with GuiDBedit Tool (see sk13009) to Security Management Server.
   2. In the left pane, browse to Table > Managed Objects > servers.
   3. In the right pane, select the Account Unit object.
   4. In the bottom pane, search for the ldap_use_cert_auth attribute, and set it to true.
   5. Save the changes and close GuiDBedit.
2. Log in to SmartConsole.
3. Add a CA object:
   1. From the Objects Bar (F11), click New > More > Server > More > Trusted CA.

      The Certificate Authority Properties window opens.

   2. In Certificate Authority Type, select External Check Point CA.
   3. Set the other options of the CA.
4. For all necessary network objects (such as Security Management Server, Security Gateway, Policy Server) that require certificate-based User Directory connections:
   1. On the IPSec VPN page of the network object properties, click Add in the Repository of Certificates Available list.

      Note - a management-only server does not have an IPSec VPN page. The User Directory on a management-only server cannot be configured to authenticate to an LDAP server using certificates.

   2. In the Certificate Properties window, select the defined CA.
5. Test connectivity between the Security Management Server and the LDAP Server.

Managing Users on a User Directory Server

In SmartConsole, users and user groups in the Account Unit show in the same tree structure as on the LDAP server.

• To see User Directory users, open Users and Administrators. The LDAP Groups folder holds the structure and accounts of the server.
• You can change the User Directory templates. Users associated with this template get the changes immediately. If you change user definitions manually in SmartConsole, the changes are immediate on the server.

Distributing Users in Multiple Servers

The users of an organization can be distributed across several LDAP servers. Each LDAP server must be represented by a separate Account Unit.

Managing LDAP Information

User Directory lets you use SmartDashboard to manage information about users and OUs (Organizational Units) that are stored on the LDAP server.

To manage LDAP information from SmartDashboard:

1. In SmartConsole, go to Manage & Settings > Blades.
2. Click Configure in SmartDashboard.

   SmartDashboard opens.

3. From the object tree, select Servers and OPSEC.
4. Double-click the Account Unit.

   The LDAP domain is shown.

5. Double-click the LDAP branch.

   The Security Management Server queries the LDAP server and SmartDashboard shows the LDAP objects.

6. Expand the Objects List pane.
7. Double-click the LDAP object.

   The Objects List pane shows the user information.

8. Right-click a user and select Edit.

   The LDAP User Properties window opens.

9. Edit the user information and settings and then click OK.

LDAP Groups for the User Directory

Create LDAP groups for the User Directory. These groups classify users according to type and can be used in Policy rules. You can add users to groups, or you can create dynamic filters.

To create LDAP groups for User Directory:

1. In SmartConsole, open Object Categories > New > More > Users > LDAP group.
2. In the New LDAP Group window that opens, select the Account Unit for the User Directory group.
3. Define Group's Scope - select one of these:
   • All Account-Unit's Users - All users in the group
   • Only Sub Tree - Users in the specified branch
   • Only Group in branch - Users in the branch with the specified DN prefix
4. Apply an advanced LDAP filter:
   1. Click Apply filter for dynamic group.
   2. Enter the filter criteria.
5. Click OK.

Examples

• If the User objects for managers in your organization have the object class "myOrgManager", define the Managers group with the filter: objectclass=myOrgManagers
• If users in your organization have an e-mail address ending with us.org.com, you can define the US group with the filter: mail=*us.org.com

Access Roles

Access role objects let you configure network access according to:

• Networks
• Users and user groups
• Computers and computer groups
• Remote access clients - will be supported with R80.x gateways

After you activate the Identity Awareness Software Blade, you can create access role objects and use them in the Source and Destination columns of Access Control Policy rules.

Adding Access Roles

Important: Before you add Active Directory users, machines, or groups to an access role, make sure there is LDAP connectivity between the Security Management Server and the AD Server that holds the management directory. The management directory is defined on the Objects Management tab in the Properties window of the LDAP Account Unit.

To create an access role:

1. In the object tree, click New> More > Users > Access Role.

   The New Access Role window opens.

2. Enter a Name for the access role.
3. Enter a Comment (optional).
4. Select a Color for the object (optional).
5. In the Networks pane, select one of these:
   • Any network
   • Specific networks - For each network, click and select the network from the list
6. In the Users pane, select one of these:
   • Any user
   • All identified users - includes any user identified by a supported authentication method (internal users, Active Directory users, or LDAP users).
   • Specific users/groups - For each user or user group, click and select the user or the group from the list
7. In the Machines pane, select one of these:
   • Any machine
   • All identified machines - includes machines identified by a supported authentication method (Active Directory).
   • Specific machines - For each machine, click and select the machine from the list
8. In the Remote Access Clients pane, select the clients for remote access.
9. Click OK.

Identity Awareness engine automatically recognizes changes to LDAP group membership and updates identity information, including access roles. For more, see the R80.20 Identity Awareness Administration Guide.

Authentication Rules

To make an authentication rule:

1. Add users to user groups.
2. Define an access role for networks, users and user groups, and computers and computer groups.
3. Make the authentication rules with the access roles in the Source.