AppNote: NBM 3.8 VPN: Authenticating users with NMAS & LDAP
Novell Cool Solutions: AppNote
By Haripriya S
Digg This -
Posted: 15 Jan 2004
Table of Contents
- Benefits of NMAS and LDAP authentication
- Part 1 - NMAS Authentication
- 1.0 How does it work?
- 2.0 Dependencies
- 3.0 NMAS authentication - Control Flow
- 4.0 Benefits
- 5.0 Some Typical Scenarios
- 6.0 Configuration
- 7.0 Steps to Set up Graded Authentication
- Part 2 - LDAP Authentication
- 1.0 How does it work?
- 2.0 Dependencies
- 3.0 LDAP authentication - Control Flow
- 4.0 Understanding 'LDAP Authenticated Identity'
- 5.0 Benefits
- 6.0 Some Typical Scenarios
- 7.0 Configuration
The new Novell BorderManager 3.8 (NBM 3.8) Virtual Private Network (VPN) solution is a significant improvement from earlier versions of BorderManager. The new management console is based on iManager. VPN now features a host of new and exciting features. In addition to being standards compliant, it offers fine-grained policies and a range of authentication mechanisms. While some mechanisms, such as the certificate based authentication and pre-shared secrets are required by the IKE standards, others are meant to make users and administrators life much easier, without compromising on security. In this article we look at implementing two such mechanisms - authentication using NMAS, and remote LDAP authentication - in your enterprise.
- Identity Integration - The NMAS and LDAP methods integrate the user's VPN identity with his or her organizational identity. While the NMAS method integrates the VPN users' identity with the eDirectory identity, the LDAP method integrates the VPN identity with the identity on the corporate LDAP directory.
- Single-point provisioning - Identity integration also aids in achieving user provisioning at a single place. Instead of maintaining the user's VPN information and passwords separately, the administrator can add the user to the corporate eDirectory or LDAP directory. This will implement VPN access and traffic control automatically, without any additional steps.
- Fine-grained and group-based policies - Access can be given or denied based on department, location - literally any type of user grouping - something which is not possible with certificate based users. Exceptions are also possible, specific users can be allowed or denied access.
The BorderManager VPN allows a user to establish a client-to-site connection using any of the NMAS methods available on the client and the server. The administrator can configure the VPN client-to-site service with the allowed NMAS authentication. The user will then be able to provide his or her eDirectory user name and credential - password, token or biometric signature, or any combination of these -- and establish a client-to-site VPN connection.
Figure 1 NMAS Authentication for Client to Site
The NMAS authentication requires the following components on the client:
- NBM VPN Client - contains VPNLOGIN and IKEAPP
- NMAS Client
- NMAS Client methods (LCM) for the required methods
The NBM VPN client installation will install all the above components and the default client methods. If additional methods are required, they should be installed on the client. Novell client is not required. However if Novell client is installed before NMAS client installation, it should not be removed later.
The NMAS authentication also requires the following components on the VPN server:
- The NBM Server Components - vpninf, ike, authgw
- NMAS Server
Install NMAS server and NICI from the NBM companion CD.
A two-stage authentication is used to achieve client-to-site NMAS authentication. The first stage (Stage 1) of authentication uses the authentication gateway (authgw.nlm).
Subsequently IKE mode is started to complete the authentication and generate the keys required for IPsec.
VPNLogin on the client and AuthGW on the server establish a transport connection between. This transport is used by NMAS to send and receive NMAS messages during authentication. A virtual authentication path is established between the NMAS client and server, whereas the actual messages are sent and received over the wire by the VPNLogin and Authgw components.
- The user enters the username and starts an NMAS mode authentication.
- The VPNLogin and AuthGW establish a transport connection on TCP port 353. This connection is used for sending and receiving NMAS messages.
- VPNLogin on the client calls into the NMAS client with the sequence requested and the NMAS session begins.
- The NMAS message requests are generated by the NMAS client and reach the server through the authgw transport. AuthGW passes the message to NMAS server and gets a reply message. This reply message reaches the NMAS client through the authgw transport.
- NMAS returns a completion code to AuthGW along with each NMAS reply. AuthGW uses the code to determine the status of the NMAS authentication.
- If authentication is successful, AuthGW checks the policies to determine if the user and the mode of authentication are allowed for VPN. If access check succeeds, the credentials that are required for the next stage are generated.
- IKE main mode begins, using the credentials generated at the end of Stage 1 authentication.
- Once IKE authentication succeeds, the VPN connection is established, and the relevant policies are sent to the client. The relevant policies are selected based on the NMAS user who authenticated in Stage 1.
- The client starts enforcing the policies that were distributed by the server.
- Support for authentication methods - Organizations that require their users to use non-password based authentication methods like Smartcards, biometric tokens and so on can now use the same policy for their VPN users. The NBM VPN integrates with over 50 authentication methods, through NMAS.
- Graded Authentication Support - The administrator can enforce the use of specific grades of authentication for login and VPN connection establishment. For example, the administrator can mandate that only users whose login clearance is "password and token" can open a VPN session.
- Containers and Groups - NMAS authentication supports allowing or denying VPN users based on their sub-tree placement or group memberships in eDirectory. Users under a specific eDirectory container can be allowed or denied access. The same applies to users belonging to certain groups. Though dynamic groups are not supported.
This section views some typical scenarios where NMAS authentication will be applicable in an organization.
1. ACorp: A company with a Single eDirectory Tree containing users and groups
Jack is a network administrator of a large multi-national company engineering division located in US. The company has offices in different continents with thousands of users. The eDirectory tree is organized based on the country of location, branch, and finally on the department in that office. The user entries are located under the 'department' sub-trees. In addition to containing users under their respective locations and departments, they are also grouped into various groups based on their title, the projects that they are working on, and also on the basis of their department (which may be spread across various offices). The company uses these group memberships to control access to their classified and confidential information and other applications.
The user accounts in the company are maintained centrally, and are automatically created from an authentic HR database. Group memberships and application access policies are also assigned during user creation time.
As the network administrator for the engineering division in US, Jack is responsible for setting up client-to-site VPN access for the users in the department. Jack has access to read all the access policies and group memberships of the users, but cannot change them. But he has administrative privileges on the user accounts in his department. The users expect to use the same corporate eDirectory password that they use for their day-to-day work.
For his department Jack can implement client-to-site VPN using one or more BorderManager servers, with NMAS authentication. Since he knows that all the users are coming in with their eDirectory passwords, he sets up authentication rules, which allow NMAS users. Jack wants to give VPN access to his department (US Engg.) and also wants to give guest access to his intranet web-server to the engineering departments outside of US.
In addition the CEO automatically gets access to all information, and hence has to be given special access. Jack achieves this by setting up the following two authentication rules and three traffic rules.
The comfort of specifying access control based on the group, container or user name is apparent in the level of control that Jack is able to achieve. Also, the destination condition helps Jack in controlling access to particular hosts or networks for a specific set of users.
2. BCorp: Biometric-enabled corporation with users in eDirectory
Alice is the network administrator of Bcorp, a small company involved in high-security products. As per the company policy, all the users are required to authenticate using a combination of a password and token or password and biometric. The company provides proximity cards and fingerprint-readers to all the users. Alice is involved in setting up a client-to-site VPN for this company. She also wants to restrict VPN access to only users who have biometric access. In addition the organization does not want to allow telnet access to any of their servers from the outside.
Alice decides to use a single BorderManager VPN server for her client-to-site service. She sets up a single authentication rule allowing access to all users. She sets up an authentication rule allowing NMAS authentication, and sets the required login grade to 'biometric & password'. She sets the default clearances for her users to be biometric & password which gives them a session clearance of biometric & password on login. Alice also adds a traffic rule disabling telnet port for all users. The following are the rules added by Alice:
To use NMAS authentication, you need to perform the following steps:
- Configure the client-to-site general parameters.
- Configure the authentication rules using NMAS.
- If graded authentication is used, configure the user clearances in ConsoleOne.
- Configure the traffic rules for the NMAS users.
- The user can now establish a client-to-site connection using NMAS authentication.
1. Client-to-Site: General Parameters
Figure 2 General Parameters Page
Trusted Root: Create a trusted root container and select it or select an existing trusted root container. This is required by the configuration snap-in, even though certificate authentication may not be used.
Address Pool: Assign one or more IP address ranges or networks to be used by the VPN server while assigning IP addresses to the VPN clients.
2. Client-to-Site: Authentication Rules
User List: The user list should contain the eDirectory objects for which the authentication rule applies. The list can contain eDirectory user names, group names or container names.
- User: This rule applies to the specific eDirectory user when he tries to connect using the NMAS mode.
- Group: This rule applies to any eDirectory user who is a member of this group when he tries to connect using the NMAS mode.
- Container: This rule applies to any eDirectory user who is located under this eDirectory container, when he tries to connect using the NMAS mode. The user object need not be in the container itself, it can be anywhere in the sub-tree under that container.
Figure 3 Authentication Rules - Define User List
Authentication Condition: Authentication condition allows you to specify the mode of authentication allowed. To allow NMAS, the Allow NMAS Authentication checkbox should be enabled. In addition, the Allowed authentication grade should be set to the NMAS authentication clearance required. See the next step for a complete discussion of using authentication grades.
Figure 4 Authentication Rules - Authentication Condition for NMAS
3. Support for graded authentication:
NBM 3.8 supports controlling access to the VPN service based on the NMAS authentication clearance of the user. The Minimum Allowed Authentication Grade specifies the authentication grade required by the user session, for the user to establish a VPN connection. Given here are few definitions relevant to this discussion - detailed discussion of these terms are available in NMAS documentation.
Clearance: Clearances are assigned to users to represent the amount of trust you have in that user. A clearance has a Read label that specifies what a user can Read and a Write label that specifies what information a user can write to. There are two types of clearances: single-level and multi-level. In single-level clearances the read and write labels are the same. In multi-level clearances, the labels are different and the read label should dominate the write label.
Examples of clearance values: logged in, password & token, multi-level administrator
Session Clearance: This is the clearance that is assigned to a user session after an NMAS authentication. This will be used to decide whether the user session has access to read or write certain resources.
Default Clearance: This is the clearance assigned for a user by the administrator. If the grade of the authenticated sequence is sufficient, then the session clearance will be set to the default clearance. If the grade is not sufficient for the default clearance, then NMAS authentication will fail.
- Assume that the default clearance of user Ben is 'password'. The session clearances will be assigned as follows:
- If Ben logs in using the 'NDS' sequence (a 'password' grade sequence), the assigned session clearance is 'password'.
- If Ben logs in using the 'Universal Smart Card' sequence (a 'password & token' grade sequence), the assigned session clearance is 'password'.
- If Ben logs in using the 'simple password' sequence (a 'logged-in' grade sequence), then NMAS authentication will fail because the grade of the sequence is not sufficient for providing a default clearance of 'password'.
- If Ben logs in using the 'NDS' sequence (a 'password' grade sequence), the assigned session clearance is 'password multi-level'.
- If Ben logs in using the 'Universal Smart Card' sequence (a 'password & token' grade sequence), the assigned session clearance is 'password & token multi-level'.
- If Ben logs in using the 'simple password' sequence (a 'logged-in' grade sequence), the assigned session clearance is 'logged-in'.
Minimum Allowed Authentication Grade: This is a field in the VPN authentication rule page that stores a security label for the VPN service, and it indicates the minimum Read label an authenticated session clearance should possess, for a VPN session to be allowed for that user.
The following table represents the relationship between the assigned user session clearance, and the action that can be performed on a resource with a given security label. Considering the network security object label to be the VPN 'Minimum Allowed Authentication Grade', we can see from the following table that whenever the user session clearance results in 'R' or 'R & W' actions, the user will be given VPN access.
Figure 5 Session Clearance vs. Security Label - from NMAS documentation
Your organization uses Universal Smart Cards (a 'token & password' sequence) and Proximity Cards(a 'token' sequence) extensively and you want to enforce your users to use a minimum of a 'token' grade sequence for VPN. To achieve this, you need to follow these steps:
- Verify that sequences are available for the required grade. If not, create a sequence. In the above case the Universal Smart Card sequence is of grade 'token & password' and the NMAS proximity card sequence is of grade 'token'.
- Verify that the users requiring VPN have the necessary credentials and configuration completed for the 'token' grade sequences - in this case, verify that the Universal Smart Card configuration and Proximity configuration is done for the user objects requiring VPN access.
- Go to ConsoleOne and modify the default clearance of the VPN users to the required grade - 'token'.
- The user will be now able to connect to VPN using any of the 'Token' sequences or higher grade sequences, including the 'Universal Smart Card' and 'NMAS Proximity card' sequences. If the user tries to connect to VPN using a logged in, password or a biometric sequence, NMAS login will fail. Also, the user will not be able to perform a normal Novell login, using any sequence with a grade less than 'Token'.
Figure 6 Setting the NMAS default clearance for users
- 1. and 2. Repeat steps 1 and 2 from previous solution.
- 3. Set the default clearance of the user.
- a. Go to ConsoleOne and modify the default clearance of the users requiring VPN access to Multi-level Administrator.
- b. Go to ConsoleOne:
- Security Object > Security Policy > Clearances > Definition and create a new clearance with a read label equal to Token and a write label of logged in. This kind of clearance is called a multi-level clearance and it represents clearances (with read and write labels) which are different from each other. Add this as the default clearance for the user objects.
- 4. The user will now be able to connect to VPN using any of the 'token', 'token & password' or 'token & password & biometric' sequences including the 'NMAS Proximity Card' and 'Universal Smart Card' sequences. If the user tries to connect to VPN using a 'logged in' or 'password' grade sequence, access to VPN will be denied. However the user will be able to perform a successful Novell login, using any sequence, whatever the grade of the sequence.
The following table indicates the behavior of different login sequences with different login clearances, when the Minimum Authentication Grade is 'token'. The possible behaviors are:
- - NMAS Authentication Failed - This is because the method is not capable of providing the session clearance specified in the default user clearance, so the NMAS authentication failed.
- - VPN Access Check Failed - NMAS Authentication succeeded, but the session clearance that was assigned is not sufficient for the 'Minimum Allowed Authentication Grade'.
- - VPN connection successfully established. The authentication succeeded, and the session clearance that was assigned is sufficient to satisfy the 'Minimum Allowed Authentication Grade'.
Click on table for larger image
From the previous table it is clear that the user default clearance should match with the Minimum Allowed Authentication Grade for users to establish VPN connection (using methods of that grade). If you need to impose the grade only for VPN connection and allow normal Novell login with any method, the 'Default Clearance' can be set to 'multi-level Administrator' or any other multi-level clearance corresponding to the required login level.
Caution: The multi-level administrator clearance is not recommended by NMAS for normal users. It is recommened only for admin level users.
NBM 3.8 provides support for LDAP authentication of the user to a remote LDAP directory to establish a client-to-site VPN connection. LDAP authentication is achieved using a specially implemented NMAS method called NBMLDAP. It uses the same NMAS framework for authentication. In this method, the user selects the NMAS/LDAP mode of authentication, and provides his or her LDAP user distinguished name and password. The NBMLDAP server side method (LSM) authenticates this user to the remote LDAP server using an SSL connection.
The dependencies for the NMAS authentication also apply to LDAP authentication. In addition LDAP authentication requires the following components on the client:
- NBMLDAP method LCM
The NBM VPN client installation installs the NBMLDAP method by default.
The NMAS authentication also requires the following additional components on the VPN server:
- NBMLDAP method LSM
The LDAP Authentication is a special-case of NMAS authentication. It also follows the same two-stage authentication (used for NMAS). The first stage of authentication uses the authentication gateway and the NBMLDAP method to perform the remote LDAP Authentication. The second stage is exactly the same as in NMAS authentication, and uses the credentials generated in Stage 1 to complete the authentication and generate the keys required for IPsec.
LDAP Authentication requires special configuration in the LDAP configuration tab in the client-to-site service configuration page.
- The administrator configures the LDAP authentication tab in the client-to-site service page.
- The VPN gateway receives the change to configuration and writes the configuration to a configuration file used by the NBMLDAP method.
- The user enters the remote LDAP user name ('LDAP dn') and starts an LDAP mode authentication.
- VPNLogin and AuthGW establish a channel and VPNLogin sends a request for LDAP authentication to AuthGW, with the remote LDAP user name specified.
- AuthGW creates a unique temporary user in the local eDirectory tree, which corresponds to the remote LDAP user name and sends the local name back to VPNLogin.
- VPNLogin starts an NMAS authentication with the local eDirectory user name with the NBMLDAP method.
- The NMAS messages are sent and received by the AuthGW-VPNLogin transport.
- The NBMLDAP method LSM on the server gets invoked by NMAS and does the following:
- Read the LDAP configuration from the configuration file.
- Obtain the LDAP password from the user using the NBMLDAP LCM.
- Authenticate the LDAP user to the remote LDAP directory using an LDAP SSL connection.
- If authentication is successful, compare the group membership of the remote user in the LDAP directory with the LDAP user/group name list configured in the LDAP configuration tab.
- If group membership check is successful, store the matched user or group name in the local temporary user object as the LDAP identity.
- Return a completion code.
- If the authentication and group membership check are successful, AuthGW retrieves the relevant traffic rules based on the LDAP identity.
- AuthGW deletes the temporary user from the local eDirectory.
- AuthGW and VPNLogin generate the credentials required for Stage 2 (which is exactly the same as in NMAS authentication).
IKE authentication is performed and the steps are the same as in Stage 2 of NMAS authentication.
- IKE main mode begins, using the credentials generated at the end of Stage 1 authentication.
- Once IKE authentication succeeds and the VPN connection is established, the relevant policies are sent to the client. (The relevant policies are selected based on the NMAS user who authenticated in Stage 1).
- The client starts enforcing the policies that were distributed by the server.
At the time of authentication to the remote LDAP directory, the group memberships of the remote user are compared against the allowed LDAP User or Group List configured in the LDAP configuration tab. The first matching user or group name is designated as the LDAP authenticated identity for the remote user. This authenticated identity is further used to select the traffic rules that apply for the given LDAP user.
An LDAP user cn=user1,o=mycorp is a member of two groups cn=group1,o=mycorp and cn=group2,o=mycorp. The LDAP authentication tab specifies cn=group2,o=mycorp as the allowed list of 'LDAP user or group list' for VPN access. When authentication is complete the username and group memberships of cn=user1,o=mycorp are compared against this list, and cn=group2,o=mycorp is assigned as the LDAP authenticated identity.
Assume that the configured traffic rules are as in the following table:
In this case, the only traffic rule that will match for the VPN connection for the user cn=user1,o=mycorp is traffic rule 2, which is any to any discard rule. This is because, though cn=user1,o=mycorp is also a member of the remote group cn=group1,o=mycorp, the designated LDAP authenticated identity cn=group2,o=mycorp did not match any other traffic rule.
- Authentication to remote authoritative LDAP directory - The NBM VPN server can directly authenticate a user in the corporate LDAP directory, which maintains the corporate users in a single place. This removes the restriction of having to place the NBM server in the corporate eDirectory tree, in order to allow access to the users. It also avoids the hassle of having to make local copies of the corporate users locally, particularly in Branch offices.
- Decentralized administration - The corporate LDAP administrator and the BorderManager administrator can be distinct without having to assign rights to their directories to the other administrator. Since the corporate tree does not have to be changed to allow specific users access to LDAP authentication, the BorderManager administrator can just point the VPN server to the LDAP server and get client to site authentication working.
- Group-based access checks - The group membership of the user on the remote authoritative directory can be used to decide whether the user is allowed to establish a VPN connection or not. This provides further control on who is allowed to access the network through VPN. Control of traffic based on the remote user and group names is also possible.
- Works with any LDAP directory - The LDAP mode of authentication removes the constraint that users should be in eDirectory for VPN access. Users in any LDAP directory can directly authenticate to BorderManager VPN.
This section views some typical scenarios where NMAS authentication will be applicable in an organization.
1. DCorp: High-secure corporate with centralized LDAP directory and multiple branch offices
Dan is the network administrator with DCorp, a company with multiple branch offices connected through the internet. The users are enrolled by an automated provisioning system, which adds all the corporate users in an LDAP directory. In addition, customer and suppliers can enroll themselves in the corporate LDAP directory through a secure portal. The corporate administrator arranges the users in multiple LDAP groups, based on the combination of location and their relationship to the company - Supplier, Customer, Employee and so on. The corporate administrator works with the branch office administrators to setup policies, groups and other attributes which are relevant to branch offices, but mostly these are one-time jobs.
One reason for maintaining a single LDAP directory is the high security requirement in the company. In particular, any changes to access control in the form of group memberships or password changes for the user are expected to take effect on all further service requests immediately. This is one reason why secondary copies of the information are not used and no replication of user information is allowed.
The branch office administrators do not have control over the user accounts, but have the authority and responsibility to set up any branch office services. They work in tandem with the corporate administrator to setup additional groups and resource policies required by them. The management of these groups is a corporate activity. Dan is a branch office network administrator for the Denver branch and wants to set up a VPN service for remote employees in his branch. The company policy also specified that all services should use their corporate account and password for authentication and access control.
Dan wants all the employees in his branch to have access to VPN, but not customers or suppliers. He also wants to set up a split tunnel for his employees, so that they do not have to go through the encrypted tunnel for their internet access. In addition to this, Dan wants to give VPN access to a couple of special customers - cn=ckane,ou=customer,o=denver and cn=sbates,ou=customer,o=denver - to the branch office web pages.
Authentication of users using NMAS is not possible in this case, because Dan cannot set up his BorderManager server on the corporate directory, or replicate the corporate user directory on his local directory. Since the corporate accounts have to be mandatorily used for authentication and access control, Dan will need to go in for a client-to-site VPN service using LDAP authentication to the corporate LDAP server.
For this purpose, he needs the following information from the corporate administrator:
- LDAP server DNS name or address
- The SSL port of the LDAP server (default is 636)
- The trusted root certificate of the LDAP server
- The names of remote groups whose members are to be given VPN access.
Since the groups are already set up based on the location and the status of the users, Dan decides to give access to the cn=employees,o=denver group. He also imports the trusted root certificate of the remote LDAP server. He then sets up the LDAP and traffic rule configuration as follows.
The fact that Dan is able to control access to his local VPN using the corporate access rules, gives both Dan and the corporate administrator the control they require in enforcing the company policies for which they are responsible. Also, it helps the corporate administrator to enforce password changes or user deletions of corporate users to take effect in the Branch office accesses immediately. Since the LDAP authentication always happens over an SSL connection, the channel between the BorderManager server and the corporate LDAP is always secure.
Note: Currently LDAP authentication does not work with dynamic groups. Only static groups can be specified in LDAP configuration.
2. GCorp: Small company with users on a non-eDirectory LDAP server
Grace is the administrator of a small company located at a single location. She uses an iPlanet LDAP server to store the hundreds of employee accounts. She is implementing a VPN solution for the employees in the organization to dial-in from their homes.
Grace decides to use a single BorderManager VPN server for her client to site service, configured using LDAP authentication. She configures LDAP Authentication for any LDAP user present on the LDAP directory, and configures a single encrypt traffic rule for all her users.
To configure the LDAP authentication follow these steps:
- Export or copy the trusted root self-signed certificate of the LDAP server to a file.
- Import the LDAP trusted root certificate into a separate trusted root container in the NBM server tree.
- Configure the LDAP configuration tab in the client to site service configuration page and add the group names and user names for allowing VPN access.
- Configure the traffic rules with the LDAP group or user name list.
1. Exporting the LDAP server's trusted root certificate
Using ConsoleOne, locate the LDAP Server certificate in the LDAP server object > SSL Configuration. Open the properties page of the LDAP server certificate object, and view the trusted root certificate in Certificates > Trusted Root Certificate. Export the Trusted Root Certificate into a file.
Alternately, the trusted root certificate can be picked up from sys:\public\rootcert.der
2. Importing the LDAP trusted root object into a trusted root container
In ConsoleOne, create a new Trusted Root under the server container (or any other container where the server has read rights). Create a Trusted Root Object under the Trusted Root container, and import the TRO from the file created in the previous step.
3. Client to Site: LDAP Configuration
Go to the LDAP configuration tab in the client-to-site configuration page. Configure the following:
- LDAP server DNS name or IP address
- LDAP server SSL port
- Trusted Root Container with the LDAP server trusted root object
Click the Add icon for the LDAP Remote User or Group List. Enter the LDAP distinguished name (dn) of the remote group or user in LDAP format. (cn=user1,o=myorg). If any LDAP user in the directory is to be allowed, enter 'Any' in this text field.
Note: While configuring multiple groups in the LDAP Remote User or Group List, if the user belongs to more than one such group the LDAP authenticated identity assigned may be unpredictable. When assigning multiple groups in this list ensure that some members overlap. In case multiple overlapping groups are used in this list, the traffic rules should be the same for all those groups.
3. Client to Site: Traffic Rules
While configuring LDAP traffic rules based on the LDAP identities, the identities can be LDAP user name or LDAP group name. If a traffic control based on an LDAP group or user name is not desirable select All Users for the User List in the traffic rule.
To specify LDAP identity for traffic control, enable go to Define User and check Only User List' Click the Add icon in the LDAP Remote User or Group Name List and add the LDAP dn of the remote LDAP group or user name.
Note: Observe care while creating multiple traffic rules using LDAP group names, when they have overlapping members. Please see the previous step for the correct procedure to follow in such cases.
This article discussed the benefits, internals and provided configuration hints for two new authentication mechanisms supported by Novell BorderManager 3.8. Use these methods in your client-to-site VPN, and let us know the real world problems that you solve with these new methods. Novell recommends that you verify the setup on a simulated test network before you deploy them directly in a production environment.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com