Novell eDirectory Server Connector
This section of the documentation contains technical specification about the Novell eDirectory Server Connector that is implemented to link ASM Core and Novell eDirectory version 8.0.
It describes the details of the third-party application, that is, Novell eDirectory including:
The version for which the connector has been developed
The name of the .NET assembly file
Connection methodology
The resource and link types that can be discovered on the application
The attributes of each resource and link types that can be imported into the ASM Core Configuration Management Database (CMDB).
If not specified, version 8.0 of Novell eDirectory should be assumed as the adequate version.
You should familiarize yourself with the information in Installing Connectors before installing any connectors, and read the Integration topics for more information on how to configure them.
Use Case Scenario
Directory servers, such as Novell eDirectory, store information about an organization’s users in groups and organizational units. ASM Core person entities are defined as person records. These persons can act as Users, analysts, or both. Organizations that use ASM Core may want to synchronize these sources to import users from directory servers into ASM Core as persons.
The table below presents an integration scenario based on the Novell eDirectory Server Connector.
Scenario | An organization maintains a list of all its employees in Novell eDirectory. The groups are configured in Novell eDirectory based on the department to which an employee belongs. One such group in Novell eDirectory is the Help Desk group. |
Goal | The organization intends to import all users classified under the Help Desk group into ASM Core as analysts. |
Action | The Novell eDirectory Server Connector is installed, the source is created, the resource type mappings are set up, the eDirectory group is specified and the eDirectory users are imported into ASM Core as persons. |
Connector Description
The Novell eDirectory Server Connector is part of the base kit of ASM Core. As soon as ASM Core is installed, the connector is available for configuration and use from the Integration menu. Therefore, there is no need to proceed with its installation.
This connector must be scheduled.
The table below provides a description of the Novell eDirectory Server Connector.
Information fields | Name |
Connector | LDAP eDirectory v8.0 <-> ASM Core |
Third-party application | Novell eDirectory |
Version developed against | v8.0 |
Assembly | Infra.Connector.LDAP.NED.dll |
Connector class | NEDConnector |
Configuration file | Infra.Connector.LDAP.NED.icnf |
Connection methodology | LDAP v3, by using Microsoft .NET System.DirectoryServices library |
Connection Parameters
The table below provides a description of the Novell eDirectory Server connection parameters.
Parameters | Description |
LDAP Server Path | The full LDAP path of the directory server, incorporating:
This URL is only valid if Integrated Security is disabled for your system.
This URL is only valid if Integrated Security is disabled for your system.
Expanded examples: Server Bind LDAP://myldapserver.mydomain.com/dc=mydomain,dc=com Server-less Bind LDAP://dc=mydomain,dc=com Using custom port no 80389: LDAP://myldapserver.mydomain.com: 80389/dc=mydomain,dc=com |
User DN/ID | User DN/ID must be a distinguished name, for example, CN=User 1, DC=mydomain, and so on. If this is not provided, the connector will use the credentials of the executing accounts. In this case, it will use the credentials of web server and Integration service. Ensure that both these accounts have appropriate rights. |
Password | Provided |
Server Bind | Checkbox Select this option if the connection string provides a specific server for optimal performance. Do not select this option for server-less connection strings. |
Use SSL | Checkbox Indicates that communication should use SSL |
The Novell eDirectory Server Connector and other LDAP connectors permit users on one source to be members of groups on other sources, scheduled within the same integration schedule. When a group member is found, their distinguished name is used to ascertain to which source they belong to. Only sources with a defined root naming context are considered for selection. The user is associated with the source with the longest root naming context contained at the end of the user’s DN. Root Naming Assessment for more information.
The Update Date field in the information section of the person record shows the date of the last update in the ASM database and not the last date the user had modified in Novell eDirectory database.
Resolve Functionality
The Resolve functionality can be accessed through the Federated CMDB Integration Platform when setting up mappings between third-party resource fields and ASM Core fields.
Novell eDirectory allows specifying a manager value for every user. This section of the document describes how the Resolve functionality handles this particular eDirectory Manager field:
Background: One Novell eDirectory user possesses one Novell eDirectory Manager.
Expected operation: In the context of the Novell eDirectory Server Connector, the Resolve capability allows the importation of both user and its manager, and also the creation of a link between them. If the manager cannot be found or imported or if it is not mapped, the Resolve functionality would resort to a default user-defined value for the Manager field in the ASM Core person details.
The Manager field is not a default field in eDirectory. Administrators need to activate this eDirectory attributes in case the Resolve function is to be used during the importation process.
Miscellaneous
Although it is possible to customize the Novell eDirectory schema so that a unique user can have several managers, this aspect is not handled by the Resolve functionality.
Novell eDirectory Base Mapping
Person records in ASM Core must be created with a minimum set of fields populated. The table below lists the recommended base field mappings that administrators should configure for all person mappings from eDirectory. The left column values reflect the current field names as viewed in ASM Core.
ASM Core person field | Novell eDirectory user field |
Login ID | Login ID |
FQDN | User Principal Name |
Surname | Surname |
First Name | First Name |
Background | Description |
Email ID | |
Telephone | Telephone |
Job title | Job Title |
LDAP Authentication over SSL (LDAPS) to the Novell Directory Services (NDS) for ASM Core
ASM Core can communicate to LDAP servers by using the SSL protocol. For this communication to succeed, the following must be taken into account:
Ensure that the keys are certified, properly signed, and stored in the appropriate category within the certificate store of the operating system.
Some third-party tools may allow communication through SSL without the following additional configurations. However, ASM Core's reliance on this particular library forces the user to adhere to these steps.
If these conditions are not met, the connection will not be established without any clear indication of reason. The message Server is not operational will be displayed in the Eventlog.
On the eDirectory server
ASM Core uses a standard library of .NET, System.DirectoryServices. In order to use it, ensure that the correct root certificate is installed in the right place on the eDirectory server.
The root certificate can be applied to the TAB of the NDS.
Copy the certificate to the servers.
Install the root certificate. See Root Certificate Installation for IIS for more details.
Generating a new Trusted Root Certificate
Follow these steps to generate a new trusted root certificate.
Launch the Novell Console and navigate to MyWorld\NDS\<Domain Name>\Domain.
Right-click Domain and select New > Object.
From the New Object list select NDSKPI:Key Material. In the Create Server Certificate (Key Material) dialog box, specify the server that will own the certificate, the certificate name and the creation method. Enter the following details:
In the Certificate name field, enter a descriptive name.
In the Creation method section, select Custom.
Click Next.
In the Create Server Certificate dialog box, specify the certificate authority who would sign the certificate. Select the option Organizational certificate authority.
Click Next.
Specify an RSA key size and how it is to be used as shown below.
In the Key size field, select 2048.
In the Type section, select SSL.
Click Next.
In the Specify the certificate parameters dialog box, enter the validity period. In the Validity period, select Maximum. You may choose the maximum period available. The default is two years.
Click Next.
In the Edit Subject Alternative Name dialog box, enter the following:
Add Name > DNS Name: <FQDN to the server hosting Novell>
Add Name > IP Address: <IP Address to the server hosting Novell>
Click Next > Next > Finish. This completes the generation of the new trusted root certificate.
Exporting the Trusted Root Certificate
Follow these steps to export the trusted root certificate.
Navigate to the SSL Certificate in the Novell ConsoleOne dialog box MyWorld\NDS\<Domain Name>\Domain\<Certificate Name>
Right click and select the Certificates tab. Ensure that the Trusted Root Certificate tab is selected.
Click Export. This launches the Export Wizard. Click Next.
In the Export Certificate dialog box, enter the following:
In the Output format section, select File in binary DER format option.
In the Filename field, enter the file path and name.
Review the details and click Finish as shown below. This completes exporting the trusted root certificate.
Root Certificate Installation for IIS
To install the root certificate for Internet Information Service (IIS), take the following steps:
Click Windows Start > Run and type
mmc.Click File > Add/Remove Snap-in.
In the Add/Remove Snap-in window, click Add
In the Add Standalone Snap-in dialog box, select Certificates from the list of Available Standalone snap-ins and then click Add
In the Certificate Snap-in dialog box, select Computer Account and then click Next. The Select Computer dialog box appears.
In the Select Computer dialog box, select Local Computer and then click Finish.
Close the Add Standalone Snap-in dialog box and click OK in the Add/Remove Snap-in dialog box.
Right-click Trusted Root Certification Authorities and select All Tasks > Import . The Certificate Import Wizard appears.
In the Certificate Import Wizard, click Next as shown below.
Browse and select the root certificate that you intend to import, and then click Next.
After the import process is over, click Finish. The root certificate is now installed. Ensure that the root certificate appears under Trusted Root Certification Authorities.
Resource Types
The Novell eDirectory Server Connector allows for exposure and importation of users and their properties as follows:
User: The generic information on Novell eDirectory users is given below.
Information fields | Description |
Mapped to | objectClass=user objectCategory=person |
Description | Represents a user stored within Novell eDirectory |
Must be received by Group | True |
Group types
The Group concept is used to classify the Novell eDirectory users into different categories. For example, one group for development, another group for documentation and so on. These groups can be of two types: Group and OU (Organizational Unit) as given in the table below.
When importing eDirectory users, the particular group from which you intend to import the users must be specified.
Group type | Object class |
Group | objectClass=group |
OU | objectClass=organizationalunit |
Schema
The schema is the list of attributes that are available for each individual eDirectory user. The table below provides the list of schema and its description.
Name displayed | Data type | Mapped to eDirectory property |
Object GUID | string | GUID |
Common Name | string | cn |
Last Modified | dateTime | modifytimestamp |
Surname | string | sn |
First Name | string | givenName |
Description | string | description |
Login ID | string | uid |
User Distinguished Name | string | dn |
string | ||
Employee No | string | employeeNumber |
Postal Address | string | sa |
Postal Address Line 1 | string | sa1 |
Postal Address Line 2 | string | sa2 |
Postal Address Line 3 | string | sa3 |
Telephone | string | telephoneNumber |
Fax | string | facsimileTelephoneNumber |
State | string | s |
Country | string | co |
Post/Zip Code | string | postalCode |
Job Title | string | title |
Room No | string | roomNumber |
Locality | string | l |
City | string | city |
Location | string | siteLocation |
Cell | string | Mobile |
Department No | string | departmentNumber |
Office | string | physicalDeliveryOfficeName |
Company | string | company |
Cost Center | string | costCenter |
Cost Center Description | string | costCenterDescription |
Manager | entityReference | manager |
Link Types
No link types are defined for the Novell eDirectory Server Connector.
Resolve Functionality: Additional information
The Resolve functionality allows for a user-defined default value to be used in case no matching records are found when trying to resolve on one specific person field value. Several reasons can lead to an unsuccessful resolving attempt. Amongst the most common are:
They belong to a different domain and that domain is not configured — Novell eDirectory integration supports cross-domain references assuming all referenced domains are configured.
They do not belong to a mapped group.
They are excluded by user-configured mapping.
Imports are regulated. So, the corresponding user records are not automatically created until a user intervenes through Federated CMDB Admin.
Root Naming Assessment
Can groups and users who are members of the groups belong to different domains?
Yes. There are several requirements for this to work:
All domains that the target users and groups belong to must have a corresponding directory server defined in ASM Core.
All domains involved are required to be a child domain of a common parent or have a parent-child relationship.
For each member of a group, ASM Core the user with the directory server whose root naming context is the longest trailing substring of the user’s distinguished name. In other words, the user is identified by ASM Core as being located on the directory server with the longest naming context that ends the user’s distinguished name.
For example, assume that there are three directory servers configured:
LDAP://server1/dc=mydomain,dc=com
LDAP://server2/dc=sub1,dc=mydomain,dc=com
LDAP://server3/dc=sub2,dc=mydomain,dc=com
Against server 2, the following group is mapped:
Group1, DN: cn=Group1,dc=sub1,dc=mydomain,dc=com
This group has two members:
User1, DN: cn=User1,dc=sub1,dc=mydomain,dc=com
User2, DN: cn=User2,dc=sub2,dc=mydomain,dc=com
ASM Core associates User1 with server 2 because the server 2 root naming context is the longest naming context contained at the end of User1’s DN. Although the trailing part of server 3’s root naming context also concludes the user’s DN, it is not considered because not all of the naming context is included. Although all of server 1’s root naming context is found at the end of the user’s DN, server 2 is given preference because its root naming context is longer.
Similarly, User2 is associated with server 3 and not server 2 because there is no match, and not server 1 because server 3’s root naming context is longer.
Last updated