Comtarsia Logon Client 2006
Installation, basic and extended configuration of the
Comtarsia Logon Client 2006
for various LDAP directory servers
Version: 18.104.22.168, 04-Jul-2006
This manual will lead through the installation of the Comtarsia Logon Client 2006, and subsequently will describe a configuration in few simple steps for a relaxed basic LDAP implementation.
An extended configuration guide for more optional LDAP functions is included in the second part of the manual; server specific configuration for server specific settings, short glossary and finally a reference list follows.
The “Quickstart” is intended to give the instructions for setting up the Comtarsia Logon Client 2006 for minimum LDAP functionalities, such as a user/password authentication in a user management of an LDAP directory server.
The chapter “Optional LDAP attributes” will give more detailed explanation and configuration proposal for the optimal use of the whole range of LDAP functionalities of the Comtarsia Logon Client, such as the possibility of assigning home directory, profile path and various resources to the user.
In the chapter “Server specific configuration” several setup options are described, custom-tailored to each particular server type, though with special attention to the LDAP server schema extension with the Comtarsia LDAP schema file.
The successful integration of the Comtarsia schema file into the LDAP server is the most significant step to enable LDAP functionalities.
Here is also to be found a cookbook for SSL configuration, as well as certificate maintenance.
Run Logon Client InstallShield setup file CLC_2006-4.1.x.x.exe
After the installation process with InstallShield, the Comtarsia Logon Client 2006 Configurator will be started.
The last step will be to make a minimum LDAP setup on the Configurator. (Please see Quickstart for an LDAP Logon
In case of a purchased copy of Comtarsia Logon Client 2006 for production purposes, the own specific License Key can be loaded, in order to replace the demo key for testing purposes.
(Under Licensing/“Load other licensekey”)
The Logon Client for testing purposes will be operative until the end of the demo License Key validity.
After restart Logon Client will be available and ready for use.
Also minimum SSL configuration is described.
Further configuration options of above please see in the respective chapter for the particular server type in the “Server specific configuration”.
· Microsoft Windows 2000/XP workstation
· Comtarsia Logon Client installed.
Installation guide please see under “Installation with InstallShield”
Following servers (LDAP Version 2 and 3) are currently supported:
ü Sun One Directory Server
ü Netscape Directory Server
ü IBM RACF Directory Server
ü Lotus Domino
ü Novell eDirectory
ü IBM Directory Server 3.x/4.x
ü IBM Directory Server 5.1
Set Logon Client run mode to “LDAP”.
Change it here to “2” if your server runs LDAP Version 2.
Most LDAP servers act optimally with this option enabled.
ü User DN Prefix “cn=” (as shown below) or “uid=“
ü User DN Suffix “,ou=Office_1,ou=Departement_1”
Note: entry begins with “,” !
ü Base DN of the LDAP tree, e.g. “o=Company” (as shown below) or “dc=companyname, dc=com”
The complete UserDN will be composed as follows:
UserDN = UserDN Prefix+Username+UserDN Suffix+BaseDN
Enter the hostname or IP of your LDAP server and press “Add Server” in order to add server to the list.
IMPORTANT: only SERVER NAME is to set and to add here!!!
For basic configuration it is NOT necessary to enable “Use this server settings” checkbox, and not necessary to fill any fields below server name.
The computer must reboot after installation.
If only configuration changes were made, reboot is NOT required.
The Logon Client dialog will appear. Enter user name and password. Select “LDAP LOGON” as domain and press OK.
Instead of pressing “OK” after entering user name, password and domain, you can also select “Advanced LDAP Logon”. This opens another dialog which allows to temporarily overwrite some of the values of the above mentioned LDAP configuration settings.
It can make life easy, if you would like to test a setup different to your current configuration, but these settings will not be saved and are only valid for a single logon.
Already acquired a taste for LDAP?
The following chapter describes a more advanced configuration and use of the Comtarsia Logon Client 2006 for LDAP logon.
Please note, that following features are not mandatory for a simple LDAP logon, and they can be applied without having extended the LDAP server’s schema file with the Comtarsia schema extension.
Comtarsia Logon Client 2006 supports LDAP user group objects of type
· objectClass=„groupOfNames“ (OID: 22.214.171.124)
· objectClass=„groupOfUniqueNames“ (OID: 126.96.36.199).
(Future versions will allow you to freely select object class in order to handle special cases.)
This classes have multi value attribute “member” or „uniqueMember“, these hold the UserDN-s of each group member.
The user has to be entered into the attribute field with his full User-DN.
At an LDAP logon with Comtarsia Logon Client 2006 also the LDAP server side group memberships are scanned.
A user, identified as member of the particular LDAP group, becomes member of the corresponding local system group.
(i.e. if LDAP group name=local system group name).
Example: If the user is member of group „Marketing“ on the LDAP server he will also become member of the local „Marketing“ group if it exists. No further configuration is necessary.
By enabling Group Mapping / “Use manual Groupmapping” in the CLC Configurator, there are further options to transfer memberships from LDAP to local system groups.
Please see them below.
LDAP groups „WSADMIN“ and „PUSERS“ are mapped (depending on the local operating system language) to the equivalent local groups, in English version Power User/Administrators, see “Individual Groupmapping”.
Example: If the LDAP user is member of group “WSADMIN” on the LDAP server, he becomes member of the local administrators group.
NOTE: these groups can be freely named.
Under “Add Groupmapping” it is possible to map any LDAP group to local groups; the membership of the respective user will be taken over from the LDAP server group to the local group.
To keep the setup procedure simple, if the requested local group is not yet set up, the Logon Client will ask whether to create it.
The maximum supported number of groups per user is 251.
This is now the suitable time to say more about how the Logon Client discovers the LDAP BaseDN, and which settings are important to be considered.
- If LDAP BaseDN is set in the registry, it will be used.
- If the LDAP server supports LDAP version 3 and the LDAP version is set to „3“ in the registry, the Logon Client tries to discover the BaseDN via LDAP query.
Note: Most LDAP servers support more than one single BaseDN. The administrator has to make sure, that the BaseDN used by the Logon Client gets returned as first entry.
This can be easily checked for example with an LDAP browser.
- If no BaseDN was found, it will be constructed (split up) out of the local computer’s full qualified hostname.
e.g.: domain = „company.com“
BaseDN = „dc = company, dc= com“
The Comtarsia LDAP schema-extension allows beyond the essential user/password authentication and group memberships the use of further LDAP features at an LDAP logon.
(For basic configuration please see
For the currently supported LDAP server types and the according Comtarsia schema-extension installation manuals please see under
After a successful schema file extension and completed Comtarsia Logon Client configuration, the following values are automatically queried off the LDAP server by the Comtarsia Logon Client 2006:
1. Directories and printer shares
2. Profile path and home directory
3. Network applications
The object class CLCShare defines in the Comtarsia schema-extension the directory and printer shares on the LDAP server.
Both share types can be assigned to LDAP users (object type CLCPerson) by assigning the attribute CLCShareName, and filling the name of the respective share into the field.
Assignments are automatically queried off by Comtarsia Logon Client at LDAP logon time and are connected according to the specifications to the user’s workstation.
A maximum of 25 directory shares as well as 9 printer shares (LPT1 – LPT9) are supported.
LDAP object class: CLCShare.
In order to create a directory share, create new object, and assign following attributes:
CLCShareName: the name of the directory share
CLCShareDescription: share description
CLCShareServer: the resource server name
CLCShareRemotePath: the path on the remote server
CLCShareType: 1(stands for directory share)
In order to assign a directory share to the user, the CLCShareName attribute has to be added to the user object, and the name of the directory share (but not the full DN of the share!) has to be entered into the field.
if the share (for example: “Datas1”) should be assigned to the next available drive letter, only the name of the share has to be entered into the CLCShareName field, but not the full DN of the share object!
if a certain drive letter is requested, append the drive letter to the share name: “Datas1/G” as for the drive letter G.
This screenshot shows the definition of a directory share on the LDAP server:
Below the assignment of a directory share to a user:
LDAP object class: CLCShare.
In order to create a network printer share, create a new object, and assign following attributes:
CLCShareName or cn: the printers’s share name
CLCShareDescription: printer description
CLCShareType: 2 (stands for printer share)
CLCShareRemoteDevice: - either the share name of the printer (“Printer13”), or
- the printer’s complete object name
(“Apple LaserWriter 16/640 PS”).
The printer driver only needs to be installed on the server.
In order to assign a network printer share to the user, the CLCShareName attribute has to be added to the user object, and the name of the printer share (but not the full DN of the share!) has to be entered into the field.
In order to create a printer share assigned on the LPT port, create a new object, and assign the following attributes:
CLCShareName or cn: the printers’s share name
CLCShareDescription: printer description
CLCShareType: 2 (stands for printer share)
CLCShareRemoteDevice: the share name of the printer (“Printer13”)
In order to assign a printer share on an LPT port to the user, the CLCShareName attribute has to be added to the user object, the printer share name (but not the full DN of the share) entered, followed by “/” and the LPT port, e.g. “Printer13/LPT3”
The printer driver has to be installed on the client workstation.
The basic difference between the two possibilities is the fact, that for Windows applications the network printer will be necessary, in case of DOS applications a printer on a LPT port has to be assigned.
As further practical feature of the Comtarsia Logon Client 2006, home directory and profile path can be assigned to the user during logon, with or without specifying a drive letter for the home directory, or setting up the home directory and the profile path separately.
The home directory string is to be entered into the “CLCProfilePath” attribute field of the “CLCPerson” object.
This attribute will be read automatically at logon.
The Comtarsia Logon Client 2006 supports the following interpretations of the home directory string:
The next available drive letter is assigned to the UNC Path
The profile path is set to \\COMTW2K\HOME\USER1\PROFILE.
Drive letter H: is assigned to UNC path \\COMTW2K\HOME\USER1.
The profile path is set to H:\COMTW2K\HOME\USER1\PROFILE.
Refers to a user directory
The user profile directory is now on
you like the user and profile directories to reside on different shares you
have to separate paths in the field CLCProfilePath with "!".
Note: If you are using Samba as resource server, path separation is strongly recommended.
The Comtarsia Logon Client provides a functionality to make use of LDAP application definitions, i.e. it offers the possibility to create shortcuts automatically for the required applications on the workstation.
This is also processed during logon.
This function is supported by the Comtarsia Logon Client beginning with version 188.8.131.52.
LDAP object class: “CLCNetworkApplication“.
In order to create a network application, create a new object, and assign following attributes:
CLCNetworkApplicationDescription: network application description
CLCNetworkApplicationCommand: the application command
CLCNetworkApplicationProgramPosition: program file location
CLCNetworkApplicationCommandParameters: optional parameters
CLCNetworkApplicationWorkingDirectory: working directory
Please see below an overview of the used LDAP attributes and their relevance to build a shortcut on a Windows desktop:
LDAP attributes Windows Shortcut
cn (only LDAP relevance)
CLCNetworkApplicationDescription Description of shortcut
Name of shortcut (*.lnk)
CLCNetworkApplicationCommand Target, the executable file/applikation
(may be an absolute path with drive letter, or UNC path)
(may be an absolute path with drive letter, or UNC path)
Optional (can remain unassigned)
CLCNetworkApplicationWorkingDirectory Start in
This function is modelled after the OS/2 „Workspace on demand“ feature, but it is fully functional on other server types as well.
During logon all available applications are queried off the server and previous shortcuts matching the filter (defined in the CLC Configurator) will be automatically deleted. This function is only relevant in case the PC has not been shut down properly, normally not necessary.
Shortcuts are then (re)created according to the filter and the various CLC Configurator settings. Please see below.
If a .lnk file is present on the resource server just this lnk-file will be copied to the client workstation. Other present shortcuts stay untouched as long as the name does not collide with the filter.
Directories defined in “NWAFolderNamePath“ and “NWAFolderName“ are created with administrator privileges and therefore can be located in places which are usually non-writable to regular users (e.g. %ALLUSERSPROFILE%).
The following figure shows a configured network application on the LDAP server.
There are two basic solutions of storing the icons for the network applications.
- either the program folder contains the application AND the icon (named as the application itself, e.g. “application.exe” and “applicationname.ico“), then this icon will be used for the application shortcut.
- or all icons have an common folder for all applications, the folder has to be defined by “NWADefaultIconPath“ when configuring the Logon Client. The Logon Client will look up for the “applicationname.ico“ here as next, if in the program folder was not found.
In case the “applicationname.ico“ does not exist, the icon defined by “NWADefaultIcon” will be used instead, for example “default.ico” – which is to be stored in the folder defined by “NWADefaultIconPath“.
All required icons are copied from the resource server into a directory on the local computer (defined by “NWAIconPath”).
If a shortcut by the name of “applicationname.lnk” is present in the program directory, it will be used and all other application specific parameters will be ignored.
In order to assign the network application to the user, the CLCNetworkApplication attribute has to be added to the user object, and the name of the network application (but not the full DN of the network application!) has to be entered into the field.
If this attribute included in the users object is set to „1“ the user is forced to change his password at the next logon. Afterwards the attribute is reset to „0“ by the Logon Client. A logon of the user without changing his password is not permitted. This action has priority over optional policy messages like a password expire warning.
The user needs write permissions to this attribute in his LDAP object.
The Logon-Client takes care of the extended LDAP Functions. Importing the scheme-file is not necessary for these functions.
If a user needs local administrator-rights on one or more specific workstations, it can be configured via the options “HwAdminGroup” and “HwAdminAttribute”.
The registry key:
defines which LDAP-attribute of the user object contains a list of workstation names on which the user can be local administrator.
In the LDAP attribute of the user object, which is configured as “HwAdminAttribute”, contains a list of workstation names on which the user needs local administrator rights (i.g. Developer ->Developerworkstation)
Additionally the user has to be member of the “HwAdminGroup”.
“hwadminattribute” = “workstations”
“hwadmingroup” = “hwadmin”
If the user now logs on to a workstation, which name appears in the LDAP attribute, and the user is member of the LDAP-group “hwadmin”, the user is going to be local administrator.
The registry key:
defines, which LDAP-group the user has to be member off, so it is going to be HwAdmin.
„hwadmingroup“ = „hwadmin“
If a user logs on the workstation, it is checked, that the user appears in the group “hwadmin”. If the workstation name appears additionally in the “HwAdminAttribute”, the user is going to be local administrator.
The “LocationModus” enables the user to log on at specific locations only.
A LDAP user object can contain primary as well as alternative locations, on which a logon is permitted.
Additionally one can export a LDAP attribute of the location object as environment variable, which for example in “Logon-Scripts”, can be reused on many different purposes.
Considering the sub domain of the FQDN of the workstation a “LocationCode” is determined, which is used to find the “Location-Object” in LDAP.
ws1.vie.comtarsia.com ŕ “vie”
In this case the LDAP search query to determine the Location-Object would appear as follows:
Additionally the [LocationBasedEnvironment] variables are exported as environment variables.
To design this function as flexible as possible, one has to configure a lot of parameters.
“EnableLocation” = DWORD:0
With “EnableLocation” = DWORD:1 the “Location-Mode” can be activated.
“LocationAllowedAttributes” = „“
Indicates which LDAP attribute of the user object is defined, at which location the user can log on.
“LocationAllowedAttributes” = „ANPrimaer, ANAlternativ“
“LocationObjectClass” = REG_SZ: „”
Indicates the object class of the LDAP-Location object.
“LocationObjectClass” = „ANSubsiddiary“
“LocationObjectCode” = REG_SZ: „ANCode“
Indicates the LDAP attribute of the LocationObject, which contains the location code, i.g. “vien”.
“LocationObjectAttribute” = REG_SZ „L“
Indicates in which LDAP attribute of the LocationObject the location name is stated, e.g. “Wien”.
“LocationBasedEnvironment” = REG_MULTI_SZ: „“
With this setting the values of attributes of the the LocationObjects can be exported as environment variables.
“LocationBasedEnvironment” = „L“
At logon of the user the Logon Client tries to read the LDAP attribute “L” out of the location object and exports the content of the attribute as environment variable “L”.
If necessary a mapping can be carried out, e.g.:
“LocationBasedEnvironment” = „L=Location“
In this case the content of the LDAP attribute “L” is exported as environment variable “Location”.
Please see: AttributeBasedEnvironment
The variable %VALID_LOCATION% is always then set, if a location check has taken place. If the current user is valid for the logon on the current location, then the variable contains the value „1“. If a location check has not taken place, for example because of a local logon, then this variable is not set.
The Comtarsia LDAP schema-extension is delivered with the Comtarsia Logon Client 2006 software package. It is intended to be included into the directory server’s schema files (instructions please see below).
After a successful server start with the extended LDAP schema beyond a simple user authentication the whole range of LDAP logon functionalities of the Logon Client will be available: the possibility to assign directory and printer shares, network applications, home directory, profile path, etc.
For this purpose the user needs the CLCPerson object class assigned, and the CLCShare / CLCNetworkApplication with the corresponding CLC-attributes herewith also has to be available. With extended schema they can be well managed in the directory server, enabling all Comtarsia Logon Client 2006 functions (instructions please see below).
There are two versions of the Comtarsia schema file:
- One version is intended for a completely new server setup, creating all the users earliest to this point.
The user object is created here with a structural object class, named “CLCPerson”. This is derived from “inetorgperson” in the current version, but it is freely modifiable if necessary to another (even user defined) object class, as long as object class “top” will be inherited at the end.
The CLC-attributes can be assigned to the CLC Person on the directory server.
- The other version is for LDAP servers with users already established and in use/production, it enables them to additionally obtain the possibility to use Comtarsia Logon Client functionalities.
The users will get assigned an auxiliary object class named “CLCPerson”, consequently the CLC-attributes are free to be assigned to them.
The directory server has to be stopped.
The schema-extension file is to be stored into the servers respective ...\config\schema folder.
The server can be started again.
(using schema-extension with structural „CLCPerson“ object class)
In order to create a new user, click on the required container (for example: People ) choose “New”
Select “Other” from the list => CLCPerson
Fill fields with user data.
Click “Advanced Properties” => “Add attribute”
Select the CLC-attributes from the list, add them, and fill the fields with the corresponding values.
(using the schema-extension with auxiliary „CLCPerson“ object class)
If there are users already in regular use/production on the LDAP server, the schema-extension offers the possibility to add an auxiliary object class to the user, in order to be able to grant him CLC-attributes.
Auxiliary object class name: CLCPerson.
Attributes: CLCShareName, CLCProfilePath, CLCNetworkApplication
Select the user => „Advanced Properties“ in the Directory.
Click on the „Object class“ => „Add value“.
Select „CLCPerson“ from the list, and add.
Now all attributes are enabled to be assigned to the user.
Select „Add Attribute“, add CLCShareName, CLCProfilePath and CLCNetworkApplication, fill attributes fields with corresponding values.
Assuming that the CLC LDAP objects (directory and printer shares, network applications, etc.) are already created, all users configured as described above are fully able to get those assigned and able to use them after logon with Comtarsia Logon Client.
The warning from the Netscape directory server, that the user password is expired becomes available during logon. The Comtarsia Logon Client is able to act accordingly and prompts the user in order to change his password before it actually expires.
This chapter describes the minimal configuration required for IBM Directory Server 5.1 to work with Comtarsia Logon Client. For further information regarding IBM directory server please refer to the IBM online help as well as the references given at the end of this document.
With the tool /usr/bin/ldapxcfg, under the section “Manage schema files” the Comtarsia schema can be attached to the “Current schema files” in the Directory Server.
It is advisable to store this file in the server’s schema file folder. (e.g. when running the server on Linux: /etc/ldapschema/comtarsia.schema.ibmds)
As next the Directory Server has to be restarted, including the Comtarsia schema file as described above. The following object classes (and its relevant attributes) will appear on the Web Administration Tool GUI under “Schema Management/Manage Object classes”
· CLCNetworkApplication: Structural
· CLCPerson: Auxiliary
· CLCShare: Structural
In order to be able to assign CLC attributes to users, the “CLCPerson” auxiliary object class has to be added to the user’s object classes. To take it into account, that users were created before Comtarsia schema was added to the LDAP server, respectively there will be new users created after setting up the additional schema, the solution can be different.
EXISTING user can be directly edited under “Manage Entries”=> Add auxiliary class.
Under “Other attributes” are the CLC attributes now available to be assigned.
In case many users have to be updated, there is a reasonable opportunity of creating a new user template with CLC attributes included. In the respective realm, where the user belongs, the former template can be simply replaced with the new one.
“CLC Person” auxiliary object class will be in this case added to the new template. (See “Create new user template”), and is now available to assign the existing users.
When creating a new system, new realms will be created based on new templates. New users will be created immediately with CLC attributes in the new realm.
Add “CLC Person” auxiliary class to the template.
The next steps are following:
· the “Naming attribute” has to be changed to “cn” to follow this example
· in the “Required” tab the “userPassword” has to be included
· a new “Tab” is created, named “Comtarsia”. This tab contains the CLC-specific attributes. These can be added to the tab as shown below.
New realms will be created based on this new template, or as mentioned before, formerly created realms can be updated with it.
In both cases the CLC attributes are immediately available on the tab “Comtarsia”.
Shares are to be created under “Directory Management/Add an entry/Structural object class”.
Select “CLCShare” structural object class and fill in the “Required” and optionally the “Other” attributes.
Network Applications are to be created under “Directory Management/Add an entry/Structural object class”.
Select “CLCNetworkApplication” structural object class and fill in the “Required” and optionally the “Other” attributes.
To assign users the relevant Shares/Network Applications, the user’s corresponding CLC attributes have to be filled in.
For existent user, select under “/Users and Groups/Manage users” the intended user. At “Edit user” fill in attributes on the recently created tab named “Comtarsia”.(Presuming that the new template with tab “Comtarsia” is the assigned template at this particular realm.)
For new user assign attributes directly when creating it. (For more information please see
Comtarsia Logon Client supports fully the password policy configuration of the IBM Directory Server.
All relevant notifications from the LDAP server (user password has to be changed, password is expired, user account is locked, etc.) become available during logon. Logon Client is able to analyse these and to act accordingly (e.g. prompts the user in order to change his password.).
Password validation is also supported, the user is notified about wrong password syntaxes at password change, according to the server configuration.
Additional information about LDAP Password Policy please see IETF Internet draft at .
The main specific settings on the Logon Client Configurator for IBM 5.1 Directory Server are as follows:
Hence this full User DN is created:
The next screenshot shows a user in its location in the /Directory Management/Manage entries, according to the previously configured location.
The next step is to set the LDAP server name in the Logon Client Configurator as shown below.
With these configurations the Comtarsia Logon Client is ready for a successful logon on an LDAP server.
SSL configuration of IBM Directory Server 5.1 please see
SSL configuration is not required for a testing scenario with Comtarsia Logon Client. However for production it is highly recommended to make use of it.
Installation of Linux Red Hat 7.3 is assumed to be completed.
Install all Directory Server relevant .rpm-s.
Install the client:
rpm -ihv ldap-clientd-5.1-1.i386.rpm
Install the server:
rpm -ihv ldap-serverd-5.1-1.i386.rpm
If the product has been successfully installed, the following is displayed:
Install the language-dependent messages or documents by typing the following at a command prompt:
rpm -ihv ldap-msg-xxx-5.1-1.i386.rpm
rpm -ihv ldap-html-xxx-5.1-1.i386.rpm
To start directory server: ibmslapd
To install the Web Administration Tool with SSL enabled:
Type the following at a command prompt:
rpm -ihv ldap-webadmind-5.1-1.i386.rpm
To start/stop webserver:
The GUI for server administration is now available under
For this manual’s SSL configurations was GSKit 5.0 used.
Install gskbas-5.0-4.rpm. To start: gsk5ikm.
Lotus Domino Release 5
Comtarsia Logon Client 2006 Build <= 184.108.40.206
Installation and Configuration of Lotus Domino 6 for use with Comtarsia Logon Client Version 2006
This chapter describes the minimal configuration required for Domino server to work with Comtarsia Logon Client 2006. For further information regarding Lotus Domino please refer to the Notes client online help as well as the references given at the end of this document.
SSL configuration is not required for a testing scenario with Comtarsia Logon Client. However for production it is strongly recommended to make use of it.
The following configuration steps are required for changing a Domino password via LDAP.
ATTENTION: In Domino Release 6 password changes via LDAP need a few minutes before they get active, at Domino Release 6.5 password changes are immediately active.
To be able to access Domino services via SSL a SSL certificate has to be installed on the server. The simplest method is generating a „Self-Signed Certificate“.
1. Open „Server Certificate Admin Database“ (certsrv.nsf) and choose the option “Create key ring with self signed certificate” to create a “Self Signed Certificate”.
2. Now open Domino Administrator
3. Now you have to configure the key file name:
Configuration->Server->Current Server Document->Ports->Internet Ports->SSL key file name
4. In the document Server->Current Server Document->Ports->Internet Ports->Directory you have to set “SSL Port Status” to “enabled” and “SSL Name and Password” to “yes”.
Further information on Domino SSL configuration can be found in [3, 4]
This step is optional and not essential if the Domino Server is only used for authentication/ password change/ group assignment
Via the Comtarsia templates attributes like network drives, assignments and network applications can be easily administrated in a usual Domino manner for all workstations.
Comtarsia specific design elements are available for web administration starting with Domino Release 6
In the template file „clcnames.ntf“ contains the Comtarsia specific design elements.
· Create the roles „CLCCreator“ and „CLCModifier“ in the ACL of the „names.nsf“ and assign them to the „Admin“ user the “Localdomainservers“ group.
In order to organize the Domino objects hierarchically in the LDAP directory, the domain has to be stated in the fullname-attribute.
In user and group objects the hierarchic name as well as the flat name has to be stated in the fullname-attribute.
IMPORTANT: The hierarchic name must be in first place in the fullname-attribute.
Screenshot of a user with DN “cn=Dom User2,o=comtarsia”:
Screenshot of a group with DN “cn=dgroup2,o=comtarsia”:
At share or network application projects it is only necessary to fill in the hierarchic name in the fullname-attribute.
Screenshots of a CLCShare object with DN “cn=office,o=comtarsia”:
Screenshots of a CLCNetworkApplication object with DN: “cn=msword,o=comtarsia”:
A logon with the Comtarsia Logon client to the Domino LDAP server can be done with a ShortName or with a FullName.
A LDAP BaseDN can only be used if the user as well as the groups are created hierarchically.
In this case, the user name must be contained full hierarchically in the field FullName, for example
For a sign on with Domino ShortName there are two opportunities:
UserDN: uid=SHORTNAME or
For further information for configuration of Lotus Domino for support of the ShortName-Logon please see the reference list at the end of this manual.
The password being used is defined in the “internet password” field in the person’s document.
Logon Client configuration:
- Option AppendBaseDN is deactivated
- The field UserDNPrefix should be set by a ShortName logon to “uid=”, by a FullName logon to „cn=“
- LDAP Server type is “Domino”
- LDAPEnableSSL is set accordingly to the Domino configuration.
Now the Comtarsia Logon Client can authenticate to the Domino LDAP server.
- openssl-0.9.6c-29 (only for ssl support)
You can check if these packages are installed with the following commands:
ngc4321:/home/stefan # rpm -q -a | grep openldap
ngc4321:/home/stefan # rpm -q -a | grep openssl
These packages can be installed with “yast” or directly with “rpm” if required.
The OpenLDAP configuration files are found under /etc/openldap.
LDAP client tools reside in /usr/bin.
The LDAP server (slapd) lies in directory /usr/lib/openldap.
BASE dc=comtarsia, dc=com
Access Control, each user may modify his entry, read others
and read the userPassword anonymous (for auth):
access to *
by self write
by users read
by anonymous auth
ldfb database definitions:
SSL: For using SSL the following lines have to be appended at the end of slapd.conf file.
openssl req -new -x509 -nodes -out server.pem -keyout server.pem -days 365
In the following dialog “Common Name” should be the name of the LDAP server.
ngc4321:/etc/openldap # openssl req -new -x509 -nodes -out server.pem -keyout server.pem -days 365
Using configuration from /usr/share/ssl/openssl.cnf
Generating a 1024 bit RSA private key
writing new private key to 'privkey.pem'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:AT
State or Province Name (full name) [Some-State]:Vienna
Locality Name (eg, city) :Vienna
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Comtarsia
Organizational Unit Name (eg, section) :SD
Common Name (eg, YOUR name) :ngc4321.comtarsia.com
Email Address :email@example.com
without SSL: /etc/init.d/ldap start
with SSL: cd /usr/lib/openssl
./slapd -h "ldap:/// ldaps:///"
or ./slapd -d 9 -h "ldap:/// ldaps:///" for debugging output
Now the OpenLDAP server is configured completely and all that is left is to import LDAP data. We recommend to use a LDAP GUI for administration, e.g.
(requires JAVA JRE 1.4)
Log in as manager (cn=Manager,dc=comtarsia,dc=com; passowrd=secret) and import the following LDIF file:
dn: cn=Manager, dc=comtarsia,dc=com
dn: cn=user1, dc=comtarsia,dc=com
You can also import the LDIF file from the command prompt (see "man ldapadd"). To add additional users import an LDIF file looking like this:
dn: cn=user1, dc=comtarsia,dc=com
Now login with user accounts is also possible, which should have permission to modify their own attributes (e.g. userPassword); if this is not the case the ACL in sldapd.conf is not set correctly.
Comtarsia Logon Client supports LDAP beginning with release 3.0. To insure confidentiality of the transmitted data (user passwords, user permission data etc.) between Logon Client and LDAP server it is possible to make use of SSL encryption.
SSL (Secure Socket Layer) was originally developed by Netscape. In the meantime many notable software vendors began to support this protocol for data encryption and digital signatures.
SSL is based on asymmetric encryption (private key / public key) and usage of X.509 certificates on server and/or client.
Hereby the following combinations are possible:
a) Server uses a so-called Self Signed Certificate. Clients do not use a certificate.
b) Server uses a CA (Certificate Authority) Signed Certificate. The client has to have at least the CA certificate to be able to validate the authenticity of the server certificate. (Server Authentication)
c) Server uses a CA Signed Certificate. Clients use a Self Signed Certificate and additionally require the CA certificate (for validating the server certificate).
d) Client as well as Server has CA Signed Certificates. In this case the Client also has to have the CA certificate so that the Server can validate the authenticity of the Client certificate. (This is called Client Authentication.)
The following vendors use proprietary standards and formats for creating and storing certificates and PKI (Public Key Infrastructure) keys.
RSA (Rhivest, Shamir, Adelman): supports PKCS#n standards. They developed the asymmetric RSA encryption schema which is named after them.
Netscape: Supports PKCS#11 – Cryptographic Token Interface Standard, PKCS#7 for saving of certificates and for certificate revocation lists, PKCS#12 for interchange of certificates and PKI keys, keyX.db and certX.db as permanent storage for certificates and PKI keys in the file system (key and/or certificate store). For asymmetric encryption the RSA method is supported.
Available tools: certutil, signtool, …
OpenSSL: supports these formats: PKCS#7, PKCS#12, X509.
RSA as well as Diffie-Hellman (DH) are used as asymmetric methods. For signing DSA (Digital Signature Algorithm) is supported. As encoding type for certificates in OpenSSL are available the DER format, the PEM format (base64 encoded version of DER) and the NET format.
Available Tools: openssl x509, openssl pkcs7, openssl crl2pkcs7, openssl pkcs12, openssl genrsa, …
Sun Java Secure Socket Extensions (JSSE): supports PKCS#7 (PEM encoded) for the import of signed certificates into the Java Key Store.
Available Tools: keytools, java signer – a program for signing of Java Archives (.jar),…
Microsoft Cryptographic Service Provider: does not support PKCS#11! Uses a proprietary method for accessing key and certificate stores. Creation of client certificates is done by Microsoft Certificate Services. A Certificate Request has to be submitted on a specific web page of the Internet Information Server (IIS) of the certification provider. This page also triggers the generation of private/public key pairs in the key store. The signed CSR can be loaded as PKCS#7. Microsoft also supports the PKCS#12 format for import/export of client and server certificates from and to the Microsoft Key Store.
RSA and Diffie-Hellman are both supported for use as PKI encryption method.
The used encoding type of the MS-CSP is the PKCS#7 DER format.
Microsoft is maintaining a certificate store by the name of „MY“ for each user in the user profile. Additionally there are system wide certificate stores for each workstation (and service). Certificates and keys are saved as files in the file system as well as in the registry.
Available tools: certutil, certificate snap in for Management Console (mmc), certificate management in IE, MS Certificate Services (for Windows 2000 Server).
(The list above does not claim to be complete.)
For a maximum of conformity and compatibility with the target operating system for Comtarsia Logon Client (Windows), to enable potential synergy effects (reuse of client certificates of other applications) and to be able to employ smart cards the decision was made to use the Microsoft Cryptographic Service Provider for the Comtarsia Logon Client.
However to reduce vendor dependance it is planned to provide automatic functions for importing, exporting and interchanging of common certificate and key formats in the Logon Client.
The goal is to use formats PKCS#7 and PKCS#11 which are supported by RSA, Netscape, OpenSSL, Sun JSSE as well as Microsoft as mentioned above.
Thought has been given to develop a add-on product (with graphical user interface) which allows to directly access key and certificate stores of other vendors (e.g. Netscapes certX.db and keyX.db) in order to be able to exchange certificates and keys with the Microsoft Certificate Store and for example to make preperations for automatic software distribution easier.
Above documentation only mentions usage of asymmetric keys. To keep things simple we did not mention that asymmetric encryption only is used for the exchange of symmetric keys (so-called “session keys”), which are the ones really used to encrypt transmitted data.
The reason for the usage of asymmetric keys is, it is much more processing intensive for encryption and decryption.
As mentioned before Logon Client uses the Microsoft SSL stack.
Microsoft’s architectural model implements this functionality by means of the so-called CryptAPI, which similar to PKCS#11 consists of an abstract definition of interfaces and functions. Function calls to the CryptAPI are forwarded to a “Cryptographic Service Provider (CSP)” which performs encrypting and decrypting as well as all SSL relevant functions. This is a module by itself.
By default Windows 2000 comes with “Microsoft Base Cryptographic Provider” installed. This only supports symmetric key lenghts of 40 or 56 Bits (DES) because US export restrictions forbade sale of US products with stronger encryption to foreign countries.
This restriction has fallen and therefore it is recommended to update by means of Windows Update to “Microsoft Enhanced Cryptographic Provider” or “Microsoft Strong Cryptographic Provider” .
Logon Client does support all three providers and if multiple CSPs are installed it always chooses the one allowing for the maximum level of data security.
The following prerequisites are necessary to use SSL encryption:
SSL must have been activated and a server certificate been installed on the respective LDAP Server. This can either be a Self Signed Certificate or a CA Signed Certificate (see Introduction a) or b)).
Additionally a Self Signed or CA Signed Certificate may be installed on the client (see Introduction c) or d)).
Certificates and matching private keys (for all but the CA certificate) must be loaded into the clients or servers so-called Certificate Store. On the client you can use the provided program import_key.exe, which is explained below. On the server the installation is done as documented by the vendor (an example HowTo for OpenLDAP is to be found in the supplied documentation)
A description of how to create a Certificate Authority follows below.
OpenSSL was chosen as software to create a Test Certificate Authority because it can be seen as standard software for it is protected by GNU Public License and freely available on the Internet. Beside this there are lots of documentation available in the Internet and OpenSSL is executable under Unix (Linux) as well as Windows (by means of cygwin, see
After OpenSSL has been installed the configuration file openssl.cnf is located in subdirectory /usr/ssl.
Well-made documentation for OpenSSL Version 0.9.2b can be found at http://www.dfn-pca.de/certify/ssl/handbuch/ossl092/ossl092.html.
openssl req -out ca.pem -new -x509
-creates CA file "ca.pem" and CA key "privkey.pem"
openssl crl2pkcs7 -nocrl -certfile ca.pem -out ca.p7b -inform PEM -outform DER
openssl genrsa -out server.key 1024
openssl req -key server.key -new -out server.req
openssl x509 -req -in server.req -CA CA.pem -CAkey privkey.pem -CAserial file.srl -out server.pem
-file "file.srl" contains a 2-digit number e.g.: "00"
openssl genrsa -out client.key 1024
openssl req -key client.key -new -out client.req
openssl x509 -req -in client.req -CA CA.pem -CAkey privkey.pem -CAserial file.srl -out client.pem
-file "file.srl" contains a 2-digit number e.g.: "00"
openssl pkcs12 -export -in client.pem -inkey client.key -keyex -CAfile ca.pem -name "client" -out client.pfx
openssl.exe x509 -text -noout -sha1 -fingerprint -in clien.pem
You can import the client certificate, the matching private key and the CA certificate (if existing) into the client key store with import_key.
USAGE: import_key -s<format_option> [-v] [<options>]
-s<format_option> Switch between PKCS7 and PKCS12 format
-v Use verbose mode
PKCS7 format options (-sPKCS7):
-f<pkcs#7_file> PKCS#7 certificate file
-k<keyfile> PEM format private key (not encrypted)
-C Certificate only.
-A Add certificate to the CA store
PKCS12 format options (-sPKCS12):
-f<pkcs#12_file> PKCS#12 certificate and key file.
-p<pkcs#12_password> PKCS#12 password.
to import a pkcs#12 certificate and key into the user store:
import_key -sPKCS12 -v -fclient.pfx -psecret
to import a pkcs#7 certificate and a PEM encoded key into the user store:
import_key -sPKCS7 -v -fclient.p7b -kclient.key
to import a pkcs#7 certificate without a key into the user store
import_key -sPKCS7 -v -C -fserver.p7b
to import a pkcs#7 certificate without a key into the system store (CA)
import_key -sPKCS7 -v -A -fca.pem
Formats PKCS#12 for certificate and key and PKCS#7 for certificate and PEM only for key (without password encryption) are supported for import.
e.g.: import_key –sPKCS12 –fMyClientCert.pfx –pSECRET
import_key –sPKCS7 –fMyClientCert.p7b -kMyPrivateKey.pem
You have to use PKCS#7 to import Certifcate Authority certificates.
z.B.: import_key –sPKCS7 –fMyCACert.p7b –A
Logon Client has the following security options:
0: No SSL encryption
1: Self Signed Server certificate accepted, no client certificate present.
2: CA Signed Server certificate required, no client certificate present.
3: CA Signed Server certificate required, Self Signed or CA Signed client certificate present.
Logon Client uses to following algorithm to locate certificates in the certificate store:
The client certificate is being searched for in the respective user’s “My-“ certificate store. First it tries to find a certificate which ‘Subject Name’ is the same as the current user’s user name. If this fails, the first certificate is used which is in the user certificate store.
The CA certificate (if used) has to be located in the “Root“ User Certificate Store (only accessible by the current user) or in the “Root“ System Certificate Store (accessible by all users on this machine). CA certificates which are imported with import_key.exe using option –A are stored in the “Root” System Certificate Store.
 Domino Short-Names:
 Default Domain Document:
 Setting up SSL on a Domino server:
 Setting up Notes and Internet clients for SSL authentication:
 Customizing the LDAP service configuration:
 Domino Directory Services:
 Password Policy
 SSL configuration
strings of numbers, allocated in a hierarchical manner, used for a variety of protocols. All LDAP object have a unique OID. Definition of OIDs comes from ITU-T recommendation X.208.
Resource Access Control Facility - is the IBM security management product for its mainframe operating systems, OS/390 (MVS) and VM.
Request for Comments - is an Internet formal document or standard that is the result of committee drafting and subsequent review by interested parties. Some RFCs are informational in nature. Of those that are intended to become Internet standards, the final version of the RFC becomes the standard and no further comments or changes are permitted. Change can occur, however, through subsequent RFCs that supercede or elaborate on all or parts of previous RFCs. The University of Southern California maintains a searchable index of all Requests for Comments from the Internet Engineering Task Force (IETF).
Lightweight Directory Access Protocol - is a proposed open standard for accessing global or local directory services over a network and/or the Internet. The word Protocol is the key word in the definition, LDAP is NOT hardware or software. It is a protocol that defines how a client and server will communicate with one another.
The Lightweight Directory Access Protocol is
defined in a series
Some of the more important RFC numbers are RFC 1777
for LDAPv2 and
Secure Sockets Layer, is the standard security technology for creating an encrypted link between a client and a server. This link ensures that all data passed between the server and client remains private and integral. SSL is an industry standard. In order to be able to generate an SSL link, a server requires an SSL Certificate.
Transport Layer Security protocol. The TLS protocol provides communication privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol.
 The providers mentioned are RSA Full Providers, which are used by LDAP Logon Client.
|All product and company names mentioned herein are the trademarks of their respective owners. (c) 2001-2016 Comtarsia IT Services GmbH. | Print | Impressum|