SilkRoad Eprise Version: Eprise 2006 v 6.0. A Practical Guide to LDAP

Transcription

1 SilkRoad Eprise Version: Eprise 2006 v 6.0 A Practical Guide to LDAP

2 SilkRoad technology, inc. PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. In no event shall SilkRoad be liable for any loss of profits, loss of business, loss of use of data, interruption of business, or for indirect, special, incidental, or consequential damages of any kind, even if SilkRoad has been advised of the possibility of such damages arising from this publication. SilkRoad may revise this publication from time to time without notice. Some states or jurisdictions do not allow disclaimer of express or implied warranties in certain transactions; therefore, this statement may not apply to you. Copyright 2005 SilkRoad technology, inc. All rights reserved. Participant Server, Eprise, and Integration Agent are trademarks or registered trademarks of SilkRoad technology, inc. in the United States and other countries. Sun, and other Sun products referenced herein are trademarks or registered trademarks of Sun Microsystems, Inc. Microsoft, Windows and other Microsoft products referenced herein are trademarks or registered trademarks of Microsoft Corporation. UNIX is a registered trademark of The Open Group. Solaris, Sun, Sun Microsystems, SunOS, and Sun UltraSparc are trademarks or registered trademarks of Sun Microsystems, Inc. Microsoft, Windows, Windows NT, and any additional Microsoft products referenced herein are trademarks or registered trademarks of Microsoft Corporation. Netscape, Netscape Navigator, Netscape Communicator, Netscape Application Server, and Netscape Enterprise Server are trademarks or registered trademarks of Netscape Communications Company. UNIX is a registered trademark of The Open Group. Any other trademarks and product names used herein may be the trademarks of their respective owners. You may not download or otherwise export or reexport this Program, its Documentation, or any underlying information or technology except in full compliance with all United States and other applicable laws and regulations, including without limitations the United States Export Administration Act, the Trading with the Enemy Act, the International Emergency Economic Powers Act and any regulations thereunder. Any transfer of technical data outside the United States by any means, including the Internet, is an export control requirement under U.S. law. In particular, but without limitation, none of the Program, its Documentation, or underlying information of technology may be downloaded or otherwise exported or reexported (i) into (or to a national or resident, wherever located, of) Cuba, Libya, North Korea, Iran, Iraq, Sudan, Syria, or any other country to which the U.S. prohibits exports of goods or technical data; or (ii) to anyone on the U.S. Treasury Departments Specially Designated Nationals List or the Table of Denial Orders issued by the Department of Commerce. By downloading or using the Program or its Documentation, you are agreeing to the foregoing and you are representing and warranting that you are not located in, under the control of, or a national or resident of any such country or on any such list or table. In addition, if the Program or Documentation is identified as Domestic Only or Not-for-Export (for example, on the box, media, in the installation process, during the download process, or in the Documentation), then except for export to Canada for use in Canada by Canadian citizens, the Program, Documentation, and any underlying information or technology may not be exported outside the United States or to any foreign entity or foreign person as defined by U.S. Government regulations, including without limitation, anyone who is not a citizen, national, or lawful permanent resident of the United States. By using this Program and Documentation, you are agreeing to the foregoing and you are representing and warranting that you are not a foreign person or under the control of a foreign person. A Practical Guide to LDAP Document Version: November 2005 Product Version: Eprise 2006 v 6.0 Technical Support SilkRoad technology, inc. Web: Phone: Headquarters SilkRoad technology, inc. 111 North Chestnut Street - Suite 200 Winston-Salem, NC Phone:

3 About Who Should Read This Book iv Additional Information v Conventions for Path Names vi Overview Securing Your Eprise Site Through LDAP Security Explained Authentication Authorization Advantages of using LDAP Getting Started with Your Directory Server External Tools for Connection and Configuration Information Connecting via a 3rd party LDAP browser. 4 Using the LDIF File for a Configuration Model 6 Developing an Approach Step One: Establishing a test connection Connection Parameters Setting Up Your Test Connection Debugging your Test Connection Authenticating Users Setting Up Your Configuration Configuration File Overview Step Two: Determining your Best Connection Method(s) DN Templates User Search Support of NDS Style Credentials Simple Connection Tests Connecting through an SSL Port Connecting to Active Directory Global Catalog Server Using the Blowfish Encryption Algorithm Steps to Configure Example Understanding Authorization to Content Setting Up Your Configuration Attribute Mapping - Configuration File Overview Mapping Attributes to Preferences Method One: Implicit Attribute Mapping.29 Method Two: Explicit Attribute Mapping 30 Mapping Rules Method One: Implicit Role Mapping Through DN Components Method Two: Implicit Role Mapping through LDAP Groups Method Three: Explicit Mapping of LDAP Roles to Eprise Roles Excluding and Restricting LDAP Roles...36 Order of Assignment Internally and Externally Defined Users and Roles Standard, External and Hybrid Users Hard and Soft Roles A Straight Forward Approach to Using LDAP A Hybrid Approach Member Users in the Directory Server...42 Control and Enroll users also defined in Eprise Hybrid Users Debugging the Authentication Method Using Netegrity s SiteMinder with Eprise Integration Modes Using the LDAP Authentication Method LDAP Integration Setting Up your Configuration Configuration File Overview Appendix Privileged Connections and Using EENCRYPT 56 Working Example: Using LDAP for a Single Login ID and Password Configuration of the LDAP.CFG Step by Step Login Site Administrator s Guide iii

4 About Who Should Read This Book This Practical Guide for Using LDAP is designed to familiarize you with the options and functionality available to you with Eprise and your directory server. This guide is written for two sets of Eprise web developers. The first set is those who have already developed their Eprise site and have a new directive of incorporating LDAP into their security model. The second set is those investigating the possibilities of implementing LDAP security with Eprise from the start. This document assumes you understand the fundamentals of LDAP, its advantages and what it is used for. This document assumes that as an Eprise Web developer, you are not an expert on your directory server implementation, you did not set it up, and you do not maintain it. The organization of this document is outlined below. In addition using the following list, you can use the table of contents at the front and jump reference links to locate specific topics within the document. About this Guide This is a brief overview of how to use this document. Securing your Eprise Site through LDAP To help explain the terms and language used throughout this document, this chapter provides an overview of the various components of Eprise security. Getting Started with your Directory Server Familiarizing yourself with the schema of your directory server configuration is an important aspect of taking advantage of all the features available to you. This chapter walks you through familiarizing yourself with you directory server and establishing a test connection through Eprise. Authenticating Users Since LDAP is a protocol and the protocol does not depend on the underlying structure of the directory server, the utilized features and attributes of the directory server are based on your implementation. This chapter describes how to determine your A Practical Guide to LDAP iv

5 Chapter iii: About best connection method. This chapter also acts as a reference guide for all available authentication options. Authorization to Content Securing your site consists of not only letting the correct people log in but presenting the correct content to a validated user. This chapter explains the available features allowing you to use your directory server configuration to drive the user s access your site. This chapter also acts as a reference guide for all available authorization options. Internally and Externally Defined Users and Roles Authenticating users is at a user level. You enable LDAP support for Eprise at a site level yet Eprise allows you to control the authentication at a user level. This chapter explains internally and externally defined users and roles providing a guide to empower you to use choose the best options for your site. A Straight Forward Approach to using LDAP This chapter outlines a hybrid approach to leveraging Eprise security and your directory server. This approach is being successfully used by our customers today. This chapter also includes a description of confirming the authentication type used for your users. Using Netegrity s SiteMinder with Eprise The authentication and authorization capabilities of LDAP are also available through a third party security tool by Netegrity called SiteMinder. The configuration can be done in conjunction with your LDAP configuration or similar mappings can be defined in the SSOAuth.cfg file. This chapter describes the configuration of integrating Eprise with SiteMinder. Appendix This chapter contains a reference guide for using the encryption tool for privileged logins to the directory server. The appendix also contains a working example of using a limited LDAP configuration for authentication. This example is to provide a jump-start for you if you would like to use your directory server for login and passwords only (in other words no role assigned through the LDAP). Additional Information Up to date information and additional Eprise and EpriseDocs tips are available on the Web site ( with a valid login ID. Site Administrator s Guide v

6 Chapter iii: About Conventions for Path Names Eprise LDAP features referenced in this document run on Eprise 2004 and higher on Windows 2003, Sun Solaris and Microsoft Windows 2000 operating systems. However, the conventions for path names in these systems are different. When a generic example or path name appears in this book, the Windows convention of back slashes (\) is used. To use the example or locate the file in a Solaris environment, change the back slashes to forward slashes (/). For example, two Eprise logs are located in the eprise\log directory on a Windows machine. On a Solaris system, you would look for the logs in the eprise/log directory. Site Administrator s Guide vi

7 Overview Securing Your Eprise Site Through LDAP Eprise takes advantage of user administration, user properties and user groupings of third party directory servers through a flexible LDAP implementation. LDAP ( Light Directory Access Protocol ) is an industry standard protocol allowing multiple applications to seamlessly leverage centralized user directories. A template driven LDAP configuration allows Eprise to take advantage of any particular directory server implementation. The purpose of this document is to provide information regarding how to configure Eprise to correctly read and leverage the attributes set in your directory server. If your company has not yet implemented a directory server, this document can be used as a starting point to understand the relationship between the participants of the Eprise site and the users defined in the directory server. You may use this document to formulate standards regarding the values assigned to the LDAP attributes. Security Explained Eprise security has a dual purpose of determining who a user is (authentication), what the user s privileges to the content are (authorization), and what the user s preferences are. Who is determined by validating the user s credentials against an established account. What privileges are granted drives the access to the content. Authentication Validating a user s credentials against an established account determines who a user is. A user is authenticated (or validated) to an account if the user provides the correct user id and password combination and the account is active. There are additional properties of an Eprise user account such as first name, last name, A Practical Guide to LDAP1

8 Chapter 1: Overview address, etc., but these properties are not relevant to a user s authentication. The account the user is authenticated against may exist in an external source such as a directory server, or internally to Eprise as an Eprise account or both.! Tip: Authenticating a user is composed of the login id, password and account status. Authorization A user s preferences and privileges determine what they experience after being authenticated. Eprise manages a user s access to content through roles. The permissions (allowing users to view, modify, or manage content) are assigned through applying roles to content. A user s membership in a role drives their permissions. The Eprise LDAP configuration allows you to leverage your directory server to assign a user s membership to Eprise roles. The roles can be created in Eprise or in the directory server.! Tip: Authorization to content is applied by assigning a member to a role. Permissions are assigned to content by assigning roles. Advantages of using LDAP Eprise takes advantage of user creation, user attribute properties, and user groupings defined in the directory server. Taking advantage of the LDAP configuration in Eprise allows Eprise to provide direct benefits to both the Eprise site administrator and Eprise site user. The maintenance of users and their role assignments in large organizations can be a formable task. Taking advantage of users defined in a centralized directory can significantly reduce user administration. One occurrence of user information in a directory service helps insure the creation and accuracy of user accounts and user properties. Eprise allows mappings and searches to leverage a centralized definition of a user. Taking advantage of users defined in a centralized directory can also significantly improve the security of the Eprise site. Consider the account activation status. If an organization has a well defined procedure to update an employee s account activation status based on an employee termination, that account deactivation would immediately translate into an authentication failure to your Eprise site. For your LDAP implementation, you may choose to define some users in Eprise as well as in your directory server. In this case, the user will still be authenticated against the directory server. More information regarding this powerful hybrid technique is explained in this document. By using your directory server to authenticate users to the Eprise site, the obvious advantage is the use of their common password. A centralized password is a direct benefit to your users. Forgetting passwords is a primary nuisance for site security. A Practical Guide to LDAP2

9 Chapter 1: Overview Eprise allows a mapping of any defined LDAP user attribute to an Eprise preference. Taking advantage of externally (and predefined) preferences, such as language or location directly benefits your users experience on your site. A Practical Guide to LDAP3

10 Getting Started with Your Directory Server The first step to using your directory server is to decide how you are going to use it. Eprise uses the LDAP.cfg file to drive the connection criteria and rules for user role assignment. The first step is to understand your LDAP structure and the second step is to configure your LDAP.cfg file. External Tools for Connection and Configuration Information Various LDAP browsers are available for free download allowing you to analyze your directory server configuration. The connection criteria necessary for the LDAP browsers is the same criteria required for the LDAP.cfg file. Connecting and browsing your configuration will help you to determine how to configure Eprise. The screen shots in this document use the free LDAP browser by Softerra LLC available from Connecting via a 3rd party LDAP browser The purpose of starting out with a 3 rd party browser is to collect the required information about your directory server and to understand the privileges associated with the connection. The same criteria will be used in the LDAP.cfg file. Note: If you are trying to test a connection to your SSL port of your directory server, see Connecting through an SSL Port in Chapter 3. Directory Servers use a distinguished name ( DN ) to uniquely identify an entry at the hierarchical level of the directory. The DN uniquely identifies the entry through a path of names that follow the entry back to the root of the tree. For example, each user is identified by the User DN. Each group is identified by the Group DN. The User DN credential (along with the password) is used to authenticate an LDAP user. By viewing the user s and their DN s with a 3 rd party browser, you can familiarize yourself with the attributes of the DN s in your directory server. Understanding the attributes of the DN is an essential part of getting the most leverage from you Eprise LDAP configuration. The browser connection criteria will require you to enter the host, port and probably the base DN. The standard non-secure port for LDAP is 389. If you create your connection profile by leaving the Base DN empty, you will see the entire tree structure of your directory server. If you are familiar with the Base DN attributes A Practical Guide to LDAP 4

11 Chapter 2:Getting Started with Your Directory Server and values that will pertain to your users, then enter the appropriate values. You have an option to use an anonymous bind to connect to the server. The limitations of the anonymous bind are imposed by the directory server administrator. If you are unfamiliar with the privileges of the anonymous bind you should take this opportunity to set up two profiles. Set up one profile that connects as an anonymous bind and one profile that connects as a privileged user. In the diagram below there are three connection profiles. One is connected for an anonymous user called eprise-burl-anon. The second one is connected as a privileged account called eprise-burluser. Each time Eprise connects to the directory server, it establishes an anonymous connection. This connection is used to authenticate the entered user credentials and read the user s attributes. A privileged connection may also be used, but is used by Eprise only for the user search and group search features. If one of the search features is enabled, and a privileged user is defined, a privileged user connection is also established. The user search support and group search support is explained later in this document. You can see in the example below, the anonymous user does not have the rights to see the all users and groups a privileged user can. This identifies the need to define a privileged user for the search connection. If you can not see the users through the anonymous connection, Eprise will not be able to locate the users in a user or group search. The privileged user connection is described with the user search in Chapter 3. A Practical Guide to LDAP 5

12 Chapter 2:Getting Started with Your Directory Server Note the eprise-burl-anon connection shows only the CN attribute. The eprise-burl-user connection (defined with a privileged user in the profile) shows all the possible CN and OU attributes. This example would require a privileged connection to search the SilkRoad base DN where my target Eprise users reside. Using the LDIF File for a Configuration Model After familiarizing yourself with the directory server criteria required for connection, you will need to examine the user DN and user attributes defined in your installation. The user DN will be passed to the directory server for authentication. Using the LDAP browser, navigate through the directory tree to locate a familiar user. A Practical Guide to LDAP 6

13 Chapter 2:Getting Started with Your Directory Server The properties in the user DN vary based on the directory server. The values in the properties vary based on how the LDAP administrator entered the users. Your LDAP administrator may have also created user-defined attributes for users or groups. A useful tool for examining your schema is the LDIF export file. The LDIF Export file will provide an easy way to analyze the properties and assigned values for each user and group. Export a few sample users to LDIF files. Also create LDIF files to use as a model to construct the group configuration. In the LDAP.cfg file you will define the rules to dynamically build the user DN. The LDAP.cfg file also accepts rules to map LDAP groups to roles. It is important to get a clear understanding of composition of the user DN s and how the users are grouped. This will translate into well defined authentication and authorization in Eprise. Here are two abbreviated LDIF examples of users. Example 1: A user in ADS. version: 1 dn: CN=Joanna M. Postle,OU=SilkRoad,DC=divine,DC=com memberof: CN=Domain Users,CN=Users,DC=divine,DC=com samaccountname: jpostle Note the dn is composed of CN, OU, DC and DC. samaccountname is a unique identifier available in ADS. Example 2: A user in Sun One DS. version: 1 dn: uid=clowe,ou=people, dc=divine,dc=com uid: CLowe givenname: Christina Note the dn is composed of uid, ou, dc and dc. Uid is a unique identifier available in Sun One and Netscape DS. Finding the unique identifiers available in your installation is an important tool for conducting user searches. User searches are a configuration option to locate a user DN based on the unique identifier. This unique identifier is a good candidate for the login id. A Practical Guide to LDAP 7

14 Chapter 2:Getting Started with Your Directory Server Developing an Approach After reviewing the LDIF files you should have an idea of the directory server configuration. The next useful step is to establish a test connection. The test connection is an over-simplified method of confirming your server connection criteria. After you have established a test connection, the next step is to properly configure your authentication options. After properly authenticating the user, you can configure your authorization options. Step One: Establishing a test connection As noted above, Eprise allows you to dynamically build the user DN to authenticate through the directory server. The rules for dynamically building the user DN are defined in Chapter 3. The recommended approach for getting connected to your directory server is to start with a simple test connection. The simple connection outlined below will verify correct entry of basic server information and connection privileges. After successfully connecting in a simple scenario, modify your LDAP.cfg to accurately reflect your actual user DN construction. Each of the configuration options is explained in full in the next chapter. Connection LDAP.ServerConfig.default.SSLport=636 The LDAP.ServerConfig parameters are the connection parameters to your directory server. As with any type of 3 rd party connection, these values are essential values. Some important items to note are: Eprise 2004 requires you to name the ServerConfig default. Current support allows one connection to a directory server at a time. Each additional ServerConfig parameter should also include.default. in the naming convention in support of the default connection. Ιf you are using an SSL connection, the server name must exactly match the name in your certificate. See Chapter 3 for further information regarding a secure port. A Practical Guide to LDAP 8

15 Chapter 2:Getting Started with Your Directory Server Setting Up Your Test Connection From working with the LDAP browser you know two important configuration requirements. One is how a DN is composed. The second is the limitations imposed on an anonymous user on your directory server which applies to searching for a DN. Eprise provides an easy way to establish a test connection by allowing you to enter the full DN. After testing the base server configuration information, you will no longer log in with a full DN. Although logging in with a full User DN is not a practical way for a user to log in, it is a useful approach to debug the connection to the directory server in your development environment. To establish a minimum connection you will: a b c d e Turn on LDAP support Turn on support for entering a DN as a user id Turn off the other DNmap support options Configure your connection parameters (server ip address or name, port, and user id and password) Attempt to log in by typing a user DN and password to an active LDAP account. A Practical Guide to LDAP 9

16 Chapter 2:Getting Started with Your Directory Server Copy the existing LDAP.cfg file to LDAP.cfg.bak. In the LDAP.cfg file, set the following values (and only these values): LDAP.SupportLDAP=1 LDAP.DNmap.SupportDNAsEntered=1 LDAP.DNmap.SupportDNTemplates=0 LDAP.DNmap.SupportNDSFormat=0 LDAP.DNmap.SupportSearchForUser=0 LDAP.ServerConfig.name=default LDAP.ServerConfig.default.port=YourLDAPPortNumber LDAP.ServerConfig.default.server= YourServerNameorIP LDAP.ServerConfig.default.SSL=0 LDAP.ServerConfig.default.port=YourLDAPPortNumber LDAP.ServerConfig.default.SSLport=636 Use the same server name and port number that you used in the 3 rd party LDAP browser tool. If your directory server uses a only a secure port then change the default.ssl value to 2. After setting up the test options, test the LDAP connection by trying to log into a page. When you are challenged enter a full DN. Accountinfo is a simple test page created for test purposes. You can create your own accountinfo page by following the example provided in Chapter 3. A Practical Guide to LDAP 10

17 Chapter 2:Getting Started with Your Directory Server Debugging your Test Connection LDAP Support is not exclusive. You can still log in to any Eprise account while LDAP Support is on. If you where not able to authenticate, log in to Eprise as your admin account. Go to the Help -> About box. Half way down the page, a table of enabled features is listed. If you have properly turned on the LDAP Support (LDAP.SupportLDAP=1), you will see LDAP listed. If this LDAP attribute is not listed, Eprise has not read the SupportLDAP attribute from the LDAP.cfg file. You are probably not picking up the intended LDAP.cfg LDAP.SupportLDAP=1 Suggestions: 1 Did you rename your original LDAP.cfg file to something with a.cfg extension? All.cfg files are parsed, you must rename the backup to something other than.cfg. 2 Did you restart w3svc? Configuration variables are part of the public namespace. Your must stop and start your web service to flush the cache. If you have the LDAP attribute listed, then Eprise is parsing your intended LDAP.cfg file. Follow the LDAP link. Review the Authentication Settings. Confirm the SupportDNAsEntered is on. If you continue to be stumped after reviewing the settings read by Eprise, try again with a more verbose logging level. The log will be able to point you in the correct direction for debugging. Change the log level to 4 in the notify.cfg file. Restart the web server and then review the eprise.log. Search for occurrences of LDAP in the log. A Practical Guide to LDAP 11

18 Chapter 2:Getting Started with Your Directory Server After obtaining your test connection you are ready to make some adjustments to correctly mirror a typical login id (one where the full User DN is not entered!) A Practical Guide to LDAP 12

19 Authenticating Users Setting Up Your Configuration In order to connect as a typical user, you must understand the various connection parameters for the authenticating the user. A user will not enter a User DN as the test example did. A user will enter a login id and the User DN will be derived based on the rules of the LDAP.cfg file. Configuration File Overview The LDAP.cfg file contains 5 main sections: 1 Support of LDAP 2 LDAP DN Mapping 3 DN Templates 4 Attribute Mapping a Preference Mapping b c d Role Mapping LDAP Users Locating Users LDAP Groups 5 Privileged Account Information Section 1 Support of LDAP A toggle of Eprise s LDAP support. The default is 0. LDAPSupport was enabled for the test configuration (described in the previous chapter) and should stay enabled. Section 2 LDAP DN Mapping "toggle of functionality signifying how the user DN will be located in the directory server tree. The enabled method defines how the User DN will be derived. A Practical Guide to LDAP 13

20 Chapter 3:Authenticating Users Section 3 DN Templates If LDAP.DNmap.SupportDNTemplates is turned on, this section defines the formats of the templates applied to create the User DN. Section 4 Attribute Mapping This section maps the LDAP defined attributes to Eprise attributes. Eprise attributes that can be read from the directory server include preferences and roles. The roles can be explicitly mapped from LDAP user attributes (properties) or they can be mapped from LDAP groups. Preferences and roles are described in the authentication section of this document. Search criteria attributes are also defined in this section. Search criteria is used to locate a user DN if some other LDAP attribute is supplied as the login id. The user search criteria are described later in this chapter. The group search criteria are described in Chapter 4 (Implicit Role Mapping through LDAP Groups). Section 5 Privileged Account Information The default connection Eprise uses to connect to the directory server uses an anonymous bind. Based on the permissions on the anonymous bind in your installation, you may require a privileged connection to perform searches. This section configures the privileged connection. This connection is used only with the LDAP.DNmap.SupportSearchForUser and the LDAP.group.SupportGroups features enabled. The privileged connection is described later in this chapter. Step Two: Determining your Best Connection Method(s) In order to authenticate a user in the directory server, Eprise must pass the User DN. Eprise uses the LDAP DN Mapping section to construct the User DN. There are 4 different methods available to configure. The functionality of each method is enabled or disabled and the rules of the construction are defined in this section. The four supported connection scenarios are summarized in the table below. You must determine the Eprise log in naming convention (for example first letter of the first name + last name or address). Next you can use the scenario s listed below to use the Eprise log in to configure Eprise to derive the User DN. A Practical Guide to LDAP 14

21 Chapter 3:Authenticating Users Scenario Use Method to enable Login ID = User DN Login ID exists somewhere in the User DN Login ID does not exists anywhere in attribute definition OR in the User DN Login ID exists somewhere in attribute definition but not within the User DN All elements of the Login ID exist in the DN using the NDS style dot notation Test connection (only), the user must enter the full User DN if Login ID is some subset of the DN string, use a template construct the User DN based on the entry Create a hybrid user. Use the Login ID to log into Eprise, use a template construct the User DN around the Authentication Type string defined for that user* Enable the user search by passing an attribute variable to find the necessary User DN Useful if your User DN follows the Novel Directory Service User DN format with credentials of cn, ou,o LDAP.DNmap.SupportDNAsEntered LDAP.DNmap.SupportDNTemplates LDAP.DNmap.SupportDNTemplates LDAP.DNmap.SupportSearchForUser LDAP.DNmap.SupportNDSFormat Each of these scenarios is described in this document. Consider the sample User DN s in the LDIF files you exported. Review the format of the login id, then determine which one or combination of the DN Mapping options you will need to enable. You may use one or all of the available options.!!note: Enabling more options than apply to your directory server configuration will have an impact on LDAP.DNmap.SupportNDSFormat=0 These values where set for the test connection. Each of these attributes drives the construction of the user DN. For the test connection, the User DN was not constructed you entered the A Practical Guide to LDAP 15

22 Chapter 3:Authenticating Users entire User DN. This is practical for a test connection, but an unlikely log in scenario. Setting LDAP.DNmap.SupportDNTemplates to 1 enables the rules constructed in the DN Templates section to be applied. If the LDAP.DNmap.SupportDNTemplates is turned on, the rules for the templates are defined in the DN Templates section. DN LDAP.ServerConfig.default.DN_template=uid=<$client.fo rm.verloginid>,ou=people,dc=divine,dc=com The default configuration was set up for your test connection. Note the server connection must be referenced as default. The LDAP.ServerConfig.default.DN_template parameter configures the template substitution. Using the two LDIF files examples two common substitution situations are outlined. The Eprise login id is part of the LDAP DN. dn: uid=clowe,ou=people, dc=divine,dc=com This is a straight forward in the LDAP.cfg file. A simple substitution of the <$client.form.verloginid> tag into the user DN. The LDAP.cfg file is as follows:!note: In these examples the preferred Eprise login id s are the first letter of the first name with the last LDAP.ServerConfig.default.DN_template=uid=<$client.fo rm.verloginid>,ou=people,dc=divine,dc=com A Practical Guide to LDAP 16

23 Chapter 3:Authenticating Users To search across multiple ou s, separate the criteria with the LDAP.Separator value. The default installation uses a ;. For example, to search the People ou and a Groups ou the DN_template would look like this: LDAP.ServerConfig.default.DN_template= uid=<$client.form.verloginid>,ou=groups,dc=divine,dc= com;uid=<$client.form.verloginid>,ou=people,dc=divine,dc=com Eprise will construct the DN with both criteria and try each scenario until it has a Successful authentication The Eprise user id is not part of the LDAP DN. dn: CN=Joanna M. Postle,OU=SilkRoad,DC=divine,DC=com In this case, you should consider using the SupportSearchForUser method instead of the DN Template. You should use the DN Template for this situation if the login id does not exist in any searchable LDAP attribute. Specifically, in reviewing the LDIF file, the login id is not present anywhere. An alternate authentication option for this scenario is LDAP.DNMap.SupportSearchForUser. If you must configure Eprise to an existing directory server configuration, using no existing LDAP attribute or DN component to map directly to Eprise provides a way. You may create a hybrid user an Eprise user account that also exists as an LDAP user. Eprise provides a field to enable the link between the two accounts. The approach is as follows: a b c Create an Eprise user account for the LDAP user. Assign the UserID to be the Eprise log in id. Use a password of password it will not be used for authentication. On the Advanced Tab Choose LDAP for the Authentication Type. In the DN field enter the substitution string. You must include some distinguishing LDAP attribute id in the value. A Practical Guide to LDAP 17

24 Chapter 3:Authenticating Users In this case, the CN=Joanna M. Postle is the substitution string. LDAP.ServerConfig.default.DN_template=<$client.accoun t.authparam>,ou=silkroad,dc=divine,dc=com Eprise will authenticate this user using the constructed User DN, password and account status defined in LDAP. Even though you are duplicating the user account in Eprise, you are still leveraging you directory server because you are using the centralized user password, account activation status, all of the user defined preferences and the user groups established in the directory server. User Search User search provides a method of searching the LDAP directory structure for a user. This method is useful if the User DN does not contain an attribute that directly maps to the Eprise login id value. In this example, the Eprise login id for is the user s address. The address is not part of the LDAP User DN. The address is a part an existing attribute in the user definition. Here is an example LDIF file export for such a user: version: 1 dn: uid=jjones,ou=people, dc=divine,dc=com uid: JJones givenname: Jenny A Practical Guide to LDAP 18

25 Chapter 3:Authenticating Users objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson sn: Jones cn: Jenny Jones mail: In the LDAP.cfg file, turn on the SupportSearchForUser and then configure the search criteria. LDAP.DNmap.SupportSearchForUser=1 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;; ; LDAP Users - Locating Users. LDAP server dependent LDAP.user.FilterTemplates=(mail=<$client.form.VerLogi nid>) In this example, the LDAP attribute name to be searched on is called mail. You can search any class object name in the subtree. You may test your search by using the Search function in your LDAP browser. If the attribute is located in the browser, Eprise will also locate the corresponding DN (matching the Search DN to the LDAP.user.SubTree value). An important note regarding the SupportSearchForUser feature is the scope of the connection to the directory server. By default, Eprise establishes an anonymous bind to connect to the directory server. If an anonymous user does not have the rights to view the necessary sub-trees to locate your users, you must define a privileged user in the LDAP.cfg LDAP.ServerConfig.PrivilegedUser.DN=CN=Administrator, OU=SilkRoad,DC=divine,DC=com ;@!validate@ wcc200.dll A Practical Guide to LDAP 19

26 Chapter 3:Authenticating Users LDAP.ServerConfig.PrivilegedUser.Password=MyPassword wcc200.dll If you require a privileged user to search necessary the sub tree to locate your users, enter the user DN and password here. As explained earlier in this documentation, it is advised that you test this connection by creating a profile in your LDAP browser. You may test your privileged connection and user search with the DN and password in clear text. Important Notes: 1 In your configuration file, you should encrypt the privileged userid and password. A utility called eencrypt.exe is provided to encrypt these values. See the Appendix for instructions on using the eencrypt utility to encrypt your privileged User DN and password. 2 You must include a ; ; to comment out the validation since the default file includes the encryption validation. Comment out the ;@!validate@ wcc200.dll in order to pass clear text. If you intend to connect via an anonymous user you may leave these parameters LDAP.ServerConfig.PrivilegedUser.DN= ;@!validate@ LDAP.ServerConfig.PrivilegedUser.Password= ;@!validate@ wcc200.dll Support of NDS Style Credentials The NDS Style credentials refer specifically to the Novel Directory Service style construction of the User DN. This feature should only be turned on if the attributes in the User DN are as follows: cn=first,ou=mid1,ou=mid2[ ],o.last Eprise will construct this specific format based a parsing the entered login id. The delimiting character is a.. For example, if the user enters jjones.people.silkroadtech the follow DN will be constructed: cn=jjones,ou=people,o=silkroadtech A Practical Guide to LDAP 20

27 Chapter 3:Authenticating Users For example, if the user enters jjones.technicalsupport.people.silkroadtech, the following DN will be constructed: cn=jjones, ou=technicalsupport,ou=people,o=silkroadtech Setting LDAP.DNmap.SupportNDSFormat to 1 enables the parsing of the login id and construction of the DN. This option does not have any dependencies on rules defined anywhere else in the LDAP.cfg LDAP.DNmap.SupportNDSFormat=1 Simple Connection Tests A simple approach to understand the best connection configuration for your directory server implementation is to turn on and test the DN Map method that encompasses the majority of your users. Useful Hints: 1 Begin by turning on one LDAP.DNmap.xxx at a time. 2 Use log level 4 in notify.cfg to review the construction of the DN in eprise.log if you are not authenticated. Search for the string CAuthLDAP:: to examine the composition of the DN. The DNmap option will be indicated after the :: in the label. 3 This test is directed at authentication. If you get a 403 error, you have been authenticated; follow the next section for information on authorizing the users based on their LDAP configuration. 4 Create a page in Eprise displaying simple configuration information to run your tests. The following example is one used throughout this document called accountinfo. Use a freeform element with the following html: LoginID: <$client.account.loginid><br> UserID: <$client.account.userid><br> Roles: <$client.role.roles><br> Pref Language: <$client.pref.language><br> Account.AuthParam: <$client.account.authparam><br> Given Name in LDAP: <$client.account.ldap_givenname><br> Sn: <$client.account.ldap_sn><br> A Practical Guide to LDAP 21

28 Chapter 3:Authenticating Users You may log into this page to see your log in id and role assignment. This test page will be useful for exploring the authorization options outlined later in this document. 5 If you have created hybrid users users that exist as an Eprise account and an LDAP account, your can verify that you are logged in as an LDAP user by examining the <$client.account.userid>. The <$client.account.userid> contains the Eprise UserID. This is a positive number for Eprise accounts, including hybrid users. If you log in as an LDAP user, <$client.account.userid> is a negative number. 6 Keep in mind that Eprise try each enabled feature as a connection attempt. After enabling the option that encompasses the majority of your users, enable and configure the option(s) to include all of your users. 7 You may enable all DNmap features simultaneously, but this will have a performance impact and it is not likely your directory server schema will require all the DNmap features. Connecting through an SSL Port If your directory server is configured to support a secure connection, the Eprise LDAP support also supports a connection through an SSL port. Similar to setting up a non-secure test connection, it is useful to test your SSL connection through a 3 rd party tool to confirm your certificate is properly installed. Some useful references are as follows: Description How to Enable LDAP over SSL with a Third- Party Certification Authority HOW TO: Enable Secure Socket Layer (SSL) Communication over LDAP for Windows 2000 Domain Controllers Link How to Configure the Address Book to Query Users Contained in Active Directory After you have confirmed you can successfully establish an SSL connection to your directory server through a 3 rd party tool, you A Practical Guide to LDAP 22

29 Chapter 3:Authenticating Users can establish an SSL connection through Eprise. This is easily done by populating two additional configuration options in the LDAP.cfg file. The first configuration option is to turn on SSL support. This is done at the server level with the following command: LDAP.ServerConfig.default.ssl=1 ServerConfig.default.ssl has three possible values: Value Meaning 0 SSL is not required (default or if invalid entry detected) 1 Use SSL if available (will try and connect via SSL and if fails will switch to cleartext) 2 SSL is required If option 1 is enabled, then a non-secure port and an SSL port must be provided. The second configuration option is to declare the SSL port. The SSL port is set with the following LDAP.ServerConfig.default.SSLport=636 A key point for an SSL connection is the server name in the LDAP.cfg file must be an exact match on the server name in the certificate. For example, the server name must be a fully qualified server name (computer name + domain name vs. just the computer name). Stipulating the server by using an IP address will fail for an SSL LDAP.ServerConfig.default.SSLport=636 In the above example, the user will be authenticated through the directory server on ldap-eng.silkroadtech.com. Another thing to note in this example, LDAP.ServerConfig.default.SSL is set to 1. This tells Eprise to try the two ports listed. If a valid certificate is present, then Eprise will connect through port 636 (the pre-defined SSL A Practical Guide to LDAP 23

30 Chapter 3:Authenticating Users port in the server). If a valid certificate is not present, then Eprise will connect through port 389 (the pre-defined non-secure port). In the above example, LDAP.ServerConfig.default.SSL is set to 2, then Eprise would attempt to connect through port 636. If the certificate was no longer valid, no attempt to connect through the non-secure port would be established and the connection would fail. The users would fail to log in and the inability to connect to port 636 would be reflected in the Eprise.log. Connecting to Active Directory Global Catalog Server If you are connecting to an AD Global Catalog server, your authentication method will vary from the standard ADS rules outlined for locating users in your directory server. 1 The default port is The default SSL port is If you are want to implicitly map AD groups to Eprise roles, the Global Catalog server defines groups differently. The Global Catalog server will not include the group membership in the member definition. The group membership will be included in the group definition. Follow the rules outlined in Option Two: The group membership is defined only in the group definition. of Chapter 4. An example configuration (along with the other criteria) is as follows : LDAP.group.GroupNameInUserObject=0 And then use: LDAP.group.FilterTemplate=(member=%s) member= exists in the group definition.!see Chapter 4 Understanding Authorization to Content for the configuration of implicit group to role mapping. A Practical Guide to LDAP 24

31 Chapter 3:Authenticating Users Using the Blowfish Encryption Algorithm Eprise 6.0 supports Blowfish encryption with LDAP authentication. The SSOAuth.cfg file is used to configure Eprise to use 3rd party values from the http header or cookie. To use Eprise with the blowfish encryption method, the following settings are available for you to add to the SSOAuth cfg file:!note: These SSOAuth variables are not included in the default SSOAuth.cfg file. SSOAuth.UseCookieInsteadOfHeader Set to 1 to use a cookie instead of the http header for the session settings SSOAuth.BlowFishKey set to the encrypted blowfish key. See the details below. SSOAuth.BlowFishMode Set to the Blowfish mode being used. This can be ECB for Electronic Code Book, CBC for Cipher Block Chaining and CFB for Cipher Feedback. SSOAuth.BlowFishPKCS Optionally set to 1 to indicate that the PKCS #7 technique documented by RSA should be used to pad the block The other relevant settings for (existing variables) in the ssoauth.cfg file SSOAuth.SessionKey=SESSIONID Steps to Configure Use the following steps to configure Eprise to use Blowfish encryption: 1 Add the following configuration variable to your SSOAuth.cfg file to use SSOAuth.UseCookieInsteadOfHeader=1 2 You can test using just this setting, but the header with the DN needs to be URL encoded if it is being passed as a cookie: For example, if the User DN is: A Practical Guide to LDAP 25

32 Chapter 3:Authenticating Users CN=Adam A. Tester1,OU=EpriseProducts,DC=epriseldap,DC=silkroadtech,DC=com It would actually be passed as: CN=Adam A. Tester1,OU=EpriseProducts,DC=epriseldap,DC=silkroadtech,DC=com 3 To use the blowfish encryption you should set a protected config variable: SSOAuth.BlowFishKey This key needs to be a string larger than 1 character and smaller than 56 (it is truncated if it is larger). The key in this example is: Note: The (open) source of the blowfish encryption code came from: foobar To create the info stored in the config file you can do the following: Eprise\bin\eencrypt SSOAuth.BlowFishKey foobar The result is: SSOAuth.BlowFishKey = encrypted::e8bbbba7a99d9c80c6aa84879fae819b80a38d918e 87878A899A Therefore, you add these settings to the config SSOAuth.BlowFishKey=encrypted::E8BBBBA7A99D9C80C6AA84 Example For example purposes, here is the above DN encrypted with BlowFish using the Electronic Codebook (ECB) mode: 3A475B83FE7F25C4E2A65E3C4D84E4065C33F19C30FA1D7AE6BD6 A9D56FC2AAAB71D49D1F C2BB47D2CD E071F51 BD D7C71B10E65C FFB9E7368D87724E9C7BC239 F Note that this is the hex representation of the encrypted data. You may test this using curl to set the headers. A curl command would look like: Tip: curl is a command line tool for transferring files with URL syntax curl.exe -b "SESSIONID= ;USERDN=3A475B83FE7F25C4E2A65E3C 4D84E4065C33F19C30FA1D7AE6BD6A9D56FC2AAAB71D49D1F2070 A Practical Guide to LDAP 26

33 Chapter 3:Authenticating Users 082C2BB47D2CD E071F51BD D7C71B10E65C FFB9E7368D87724E9C7BC239F" Where the showmeheaders page showed me the headers and the roles that the user has. Note: the <$client.http.all_raw> merge string can be used to see all the headers on a page. A Practical Guide to LDAP 27

34 Understanding Authorization to Content Setting Up Your Configuration After a user is properly authenticated the next step is to assign the proper preferences and access to the content. The preferences and access to the content is driven through preference definitions and role assignments in the LDAP.cfg file. Attribute Mapping - Configuration File Overview The previous chapter outlines the five main sections of the LDAP configuration file. The Attribute Mapping section is specifically focused at assigning the authorization attributes (preferences and roles). The attribute mapping categories are as follows: 1 Preference Mapping This section defines LDAP attribute assignments to Eprise merge strings. This allows Eprise to take advantage of any defined LDAP attributes through merge strings. 2 Role Mapping This section defines the use of the LDAP attributes in the user s DN to assign the user to a role. The user DN attributes are mapped to Eprise roles. This allows Eprise to leverage the scoping included in the user DN defined in the directory server. 3 LDAP Users Locating Users This section is used for the User Search option of authenticating a user. 4 LDAP Groups This section defines the mapping of predefined directory server groups to Eprise roles. The LDIF export files continue to be a useful tool for understanding your directory server configuration. You can easily see LDAP attributes and values that are available for each user. You can also see the grouping and attribute reference to groups. The attribute reference to groups varies based on the brand of A Practical Guide to LDAP 28

35 Chapter 4:Understandiing Authorization to Content directory server. Some good rules of approach to clearly map your directory structure to Eprise would be to: 1 Familiarize yourself with the users defined in the directory server 2 Familiarize yourself with the defined groups they belong to 3 Analyze the LDIF exports for the same users and corresponding groups 4 Recognize the LDAP attribute references for the users and groups Mapping Attributes to Preferences Eprise provides two methods to access the values assigned to attributes in the directory server through merge strings. You may consider what will be the most useful in your implementation. Method One: Implicit Attribute Mapping Eprise allows you to directly access the LDAP attribute values through the client namespace. The implicit mappings are referenced through the client.account merge string components. This is a useful method to use if you have a directory server available to you while you are developing your code (vs. retrofitting your existing application to use a directory server). By default, all LDAP attributes and values of an authenticated user are available through merge strings. After authenticating a user, each attribute value is available through the merge string syntax of: <$client.account.xxxyyyyyyy> where XXX = the value assigned in LDAP.attribute.prefix of the LDAP.cfg file and where YYYYY = the attribute name as it is defined in the directory server. The following example uses the default LDAP.cfg LDAP.attribute.prefix=LDAP_ For example, to use the value in the directory server attribute called givenname in an Eprise merge string, the syntax would be as follows: <$client.account.ldap_givenname> For security reasons, the Eprise administrator may choose to exclude some attribute values from the eprise developer. The exclusion of attribute values is done through an explicit exclude in A Practical Guide to LDAP 29

36 Chapter 4:Understandiing Authorization to Content the LDAP.cfg. The following example excludes the directory server s user creator and modifier LDAP.attribute.exclude=creatorsName Method Two: Explicit Attribute Mapping Eprise also allows you to map LDAP attribute values to Eprise attributes. This is a useful method to use if you have developed most (or all) of your code using standard Eprise authentication. As a feature enhancement, you now want to retrofit your existing application to use a directory server. If most of your code directly references the Eprise attributes for users, the LDAP configuration also allows you to map the LDAP attributes to override the Eprise attributes. This is a straight forward mapping in the LDAP.cfg LDAP.attribute.map.givenName=USERNAME_FIRST!!Note: If the LDAP attribute name is mapped in the LDAP.cfg file, it is no longer available for reference through the direct object name reference outlined in method one. The two methods (implicit mapping and explicit mapping) are mutually exclusive of each other at an attribute name LDAP.attribute.map.telephoneNumber=TELEPHONE To use the value in the attribute called givenname the merge string syntax would be as follows: <$client.account.username_first> The following example is of a user defined preference. User defined preferences are reference in Eprise client namespace through the client.pref components. The example below describes a user defined LDAP attribute mapping to a user defined preference in Eprise. The user defined LDAP attribute name is SchoolDistrict. In order to reference that value in a merge string, a preference would also be defined in Eprise. For this example, the internal name defined in Eprise is SchoolDis I The mapping in the LDAP.cfg file would LDAP.preference.map.SchoolDistrict=SchoolDis To use the value in the custom attribute, the merge string syntax would be as follows: <$client.pref.schooldis> A Practical Guide to LDAP 30

37 Chapter 4:Understandiing Authorization to Content Mapping Rules Roles are a powerful feature of Eprise allowing you to group users and manage their access to your site. Roles can be established in Eprise and/or in your directory server. If you choose to take advantage of establishing roles in your directory server, there are three methods available to map an LDAP entity to an Eprise Role. The first method is to implicitly map a DN component of the user DN to an Eprise role. The second method is to implicitly map an LDAP group as an Eprise Role. These two methods allow you to create roles based on a LDAP entity. Eprise roles are defined through the directory server. If the DN components of users or groups are modified, the changes will come into effect in your Eprise role membership without any changes to your Eprise configuration. This is a very powerful administration feature. For example if a user is added to an LDAP group because of a relocation or promotion, that would be immediately reflected in their Eprise role membership. The third method is to explicitly map an LDAP role to an Eprise role. Explicit mapping allows you to map an LDAP role to an existing Eprise role. The LDAP entity is explicitly assigned to an Eprise role in the LDAP.cfg file. This method is particularly useful if you are retrofitting LDAP support on to an existing Eprise site. You may use a combination of implicit and explicit role assignments to establish the full membership list. The LDAP.cfg file allows you to both create Eprise roles through the directory server and assign Eprise roles to directory server entities (DN components and LDAP groups). Method One: Implicit Role Mapping Through DN Components Eprise allows LDAP users to be implicitly assigned to roles based on the User DN components. This is a powerful feature that allows the naming convention in the directory server to seamlessly map to Eprise roles without any coded references (in Eprise). Eprise uses the user Distinguished Name ( user DN ) for each login id, and breaks in up into its parts. Each part is referenced as a component. Each component has the form attribute =value A Practical Guide to LDAP 31

38 Chapter 4:Understandiing Authorization to Content For each component, if the attribute appears in the DNComponentsToMapToRoles setting, then the value will be added to the user s role list. For example, a user has the following user DN: dn: CN=Adam A. Tester1,OU=EpriseProducts,DC=epriseldap,DC=silkroadtech,DC=com In this example, product group (EpriseProducts) and domain (eprise-ldap, silkroadtech) are valuable role assignments to the Eprise site. With the following command, Eprise will add all values for the attributes OU and DC to role list (after LDAP.role.DNComponentsToMapToRoles=ou,dc Eprise will now include all ou and dc references from the user DN (of Adam A. Tester1 )to the user s role list. Using the merge string test of: Roles: <$client.role.roles><br> returns: Roles: 'com', 'epriseldap','epriseproducts','everyone','silkroadtech' His is a member of these roles because: DC=com DC=eprise-ldap OU=epriseproducts default assignment = everyone DC=silkroad The role of everyone is added to an Eprise user s role list by default. The DN components that now have been mapped into roles are called soft roles. Soft roles are roles that do not exist in the Eprise role tree (of the Participant Center). All components whose attributes are listed in the DNComponentsToMapToRoles list will be mapped into an authenticated user s role list. If some of the DN components that you pick up do not add any value to your site (like com in this example). A Practical Guide to LDAP 32

39 Chapter 4:Understandiing Authorization to Content Method Two: Implicit Role Mapping through LDAP Groups In addition to using the DN components to map an LDAP user to a role, Eprise allows the use of the directory server groups as roles. If a user is a member of an LDAP group, then the group will implicitly become an LDAP role. Support of using Groups as roles is enabled LDAP.group.SupportGroups=1 The groups definition varies based on the directory server being used. The option that you use is solely based on the method supported by your directory server. The LDIF export file is useful to help understand the structure of the group in the directory server. Eprise provides two options for two different directory server formats. These examples outline Active Directory Server, Sun One, and Netscape, but if you are using a different type of server you can easily determine which option to use by examining the LDIF file for ether the member or the group. Option One: The group membership is defined in the member definition The first format contains each group DN in the definition of the user. Active Directory Server is an example of a directory server that stores a class object at the member level to indicate the group membership. This example shows the user LDIF file of a user in ADS: dn: CN=Adam A. Tester1,OU=EpriseProducts,DC=epriseldap,DC=silkroadtech,DC=com memberof: CN=Technical Support,DC=epriseldap,DC=silkroadtech,DC=com memberof: CN=Burlington,DC=epriseldap,DC=silkroadtech,DC=com Note the inclusion of a member of attribute at the user level. This facilitates a simple search by Eprise. The required configuration variables are:!note: AD Global Catalog server does not use the a member level indicator, but uses a group level class object. See Option Two for group level rules if you are connecting to AD Global Catalog server.!note: Eprise determines the Group Name by examining the value of the configured GroupNameAttribute. The value is parsed, taking the left most DN component. Of the DN component, the attribute and = are discarded and the value is taken for the Role name. In this example CN= is discarded leaving Technical Support and LDAP.group.GroupNameAttribute=memberOf In this example, if Adam A. Tester1 was authenticated, the role list would now include Technical Support and Burlington. If Adam A. Tester1 is included in additional groups at some future time, the new group(s) would implicitly be added to Adam s role list. A Practical Guide to LDAP 33

40 Chapter 4:Understandiing Authorization to Content Option Two: The group membership is defined only in the group definition The second format contains each user (user DN) in the group definition and not in the definition of the user. Netscape and Sun One are examples of directory servers that store the members of an LDAP group only in the group definition. To examine this method, you must export an LDIF file for the group (instead of the user). The LDIF file of the group Burlington is as follows: objectclass: top objectclass: groupofuniquenames cn: Burlington dn: cn=burlington,ou=groups, dc=epriseldap,dc=silkroadtech,dc=com uniquemember: uid=atester1,ou=epriseproducts,dc=epriseldap,dc=silkroadtech,dc=com uniquemember: uid=btester2,ou=opionwareproducts,dc=epriseldap,dc=silkroadtech,dc=com uniquemember: uid=ctester3,ou=truelookproducts,dc=epriseldap,dc=silkroadtech,dc=com The group name is contained in the DN component cn. Each member of the group is listed as a uniquemember. In this example, the group name is Burlington and ATester1, BTester2, and CTester3 are all members of the Burlington group. In order to include the group name in the user s role list, these four configuration settings are required to be set: 1 LDAP.group.GroupNameAttribute indicating the DN component containing the value of the group name. cn=burlington 2 LDAP.group.FilterTemplate indicating the attribute name that contains the user (uniquemember=%s) 3 LDAP.group.SubTree indicating the starting node to begin the search of the sub tree. In the LDIF file, this follows the common name (cn) in the group dn. ou=groups, dc=eprise-ldap,dc=silkroadtech, dc=com!!note: %s is used to pass the user DN. %s is the only variable Eprise will expect. A Practical Guide to LDAP 34

41 Chapter 4:Understandiing Authorization to Content 4 LDAP.group.SearchScope indicating how many nodes in the tree structure the group search should include. LDAP.group.SearchScope=n!!Note: n is used to search all subtrees of the starting node. In the above example, if the user ATester1is authenticated, and the following configuration variables would return the group LDAP.group.SubTree=ou=Groups, dc=epriseldap,dc=silkroadtech, LDAP.group.SearchScope=n Method Three: Explicit Mapping of LDAP Roles to Eprise Roles Methods one and two describe how Eprise allows LDAP roles to be implicitly mapped through both their DN Components and the directory server groups. Next, method three describes how Eprise allows you to explicitly map the LDAP roles to Eprise roles. This powerful feature allows you to leverage valuable directory server categorizations into your Eprise site. If your Eprise site has already been created, use this mapping to link the directory server roles to your existing Eprise roles. For example, a user has the following user DN: dn: CN=Adam A. Tester1,OU=EpriseProducts,DC=epriseldap,DC=silkroadtech,DC=com In this example, product group (EpriseProducts) and domain (eprise-ldap, silkroadtech) are valuable role assignments to the Eprise site. The following command will add all values for occurrences of the OU and DC references to the Adam A. Tester1 s role list after he has been LDAP.role.DNComponentsToMapToRoles=ou,dc The DN Component value is explicitly mapped to the Eprise role by including it in the suffix of the dot notation. In this example, all members of the EpriseProducts ou, need to be mapped to a role called employee. The configuration option would be as LDAP.role.map.EpriseProducts=Employee Using the merge string test of: A Practical Guide to LDAP 35

42 Chapter 4:Understandiing Authorization to Content Roles: <$client.role.roles><br> returns: Roles: 'com', employee, 'epriseldap','epriseproducts','everyone',''silkroadtech' The roles com, 'eprise-ldap', 'epriseproducts',' everyone',' silkroadtech' were implicitly mapped through the DNComponentsToMapToRoles option. The role employee was explicitly mapped though the LDAP.role.map option. Each implicitly mapped role can be explicitly mapped into as many Eprise roles as necessary.!!note: the ExcludedRoles and RestrictedSoftRoles do not apply to explicitly mapped roles. If a role is explicitly mapped, it will be added to the role list. Excluding and Restricting LDAP Roles The implicit mapping of LDAP entities to create roles in Eprise is a very powerful assignment mechanism. But along with the advantages of leveraging the directory server class objects to create Eprise roles, comes the disadvantage of inadvertently creating an role list with for your users with useless roles. As a user navigates the Eprise site, their role list is constantly referenced to grant the proper permissions. An extensive role list can have negative performance impacts, particularly if the role list includes roles like com just because it was picked up as part of an implicit mapping. Eprise gives you two methods to correctly isolate your user s role lists to useful Eprise roles. Each of these methods is described below. The first method is to exclude useless or harmful LDAP entities from being assigned to your Eprise user. The second method is to restrict the possible LDAP entities to a subset of applicable roles. It is important to note that any LDAP role that is explicitly mapped to an existing Eprise role will be included in the user s role list. This is only achieved by intentionally mapping the soft role (aka an LDAP role) to an Eprise role in the LDAP.cfg file. Explicit role mappings are recognized and included in the role list. Excluding Roles Implicit role mapping may be useless if that role is never referenced in your Eprise application. Implicit mapping may also be harmful if the naming convention in the directory server has inadvertently overlapped with a Eprise defined role that has a different purpose. For this reason, Eprise empowers you to exclude LDAP roles. This option is to protect you from inadvertently mapping a user into a role that you did not intend to be a member. A checklist to review the implicit LDAP definitions is as follows: 1 Are there any role names that exist in both the directory server and in Eprise that have different meanings? These are suspect of having members improperly categorized. A Practical Guide to LDAP 36

43 Chapter 4:Understandiing Authorization to Content 2 Are there any Eprise roles that would be problematic if LDAP member were implicitly mapped? For example, you may want to exclude any admin roles. These should be reserved for standard Eprise users. A good example of this is Master. 3 Are there any implicitly mapped roles that add NO value to your Eprise application? com is one of the example DN components. That is useless to my Eprise site. To prevent a harmful or useless implicit mappings use the following LDAP.role.ExcludedRoles=master,com The ExcludedRoles option contains a comma separated list of role names. Excluded roles will override any implicitly mapped roles. Roles may be implicitly mapped through the DN component mapping option or by mapping groups to roles. The ExcludedRoles option will not override any roles that you explicitly map. Restricting Roles If you have an extensive directory server configuration, with many groups defined, you may be more comfortable with using the second option of restricted soft roles. You should consider this method if you are interested to limiting the implicit role mappings from the directory server to a very specific set of roles. To limit the implicit mappings to specific roles use the following LDAP.role.RestrictSoftRoleList=EpriseProducts,Opionwa reproducts, TrueLookProducts The LDAP.role.RestrictSoftRoleList option contains a comma separated list of role names that you want to be included in the user s role list. In this example, assume the DN components of the OU are mapped to roles LDAP.role.DNComponentsToMapToRoles=ou,dc This example limits possibilities of the soft role assignment from the directory server to only EpriseProducts, OpinionwareProducts, or TrueLookProducts. The users will exist in only one of these product lines. Using the original example: User Adam A Tester1 has the following user DN: dn: CN=Adam A. Tester1,OU=EpriseProducts,DC=epriseldap,DC=silkroadtech,DC=com After Adam logs in, his role list will include only the roles that apply to him. In this case, he will be become a member of EpriseProducts. In this example the restricted list contained three product lines, but Adam s User DN included him in only one A Practical Guide to LDAP 37

44 Chapter 4:Understandiing Authorization to Content of the three. He becomes a member of the one restricted role that applies to him. The DC s of DC=eprise-ldap,DC=silkroadtech,DC=com will be NOT be included in his role assignment. They do not exist on the restricted list. LDAP.role.RestrictSoftRoleList has three possible values: 1 A comma separated list of roles to be applied if role pertains to the user LDAP.role.RestrictSoftRoleList=role1,role2,role3 2 A meaning all LDAP roles will be excluded from the Eprise role list LDAP.role.RestrictSoftRoleList=0 3 Blank meaning all soft roles will be mapped as defined by the other configuration options LDAP.role.RestrictSoftRoleList= Order of Assignment The order of assigning roles is done in the following order: 1 Eprise has successfully authenticated the user through the directory server. 2 Eprise creates a temporary or working list to assign the user roles 3 If DNComponentsToMapToRoles is enabled, the DN components are added to the working list. 4 If the SupportGroups is enabled, the results of the group search are added to the working list. 5 Any excluded roles are removed from the working list (implicit mappings). 6 The list is now limited to any defined restrictions (on implicit mappings) 7 All Role.Map configuration options are added to the working list (explicit mappings). 8 Each role in the working list is added to the role list of the user. A Practical Guide to LDAP 38

45 Internally and Externally Defined Users and Roles Standard, External and Hybrid Users Allowing a directory server to authenticate and authorize users to your Eprise site opens up a different concept to the use of users and roles. Users of your site can be externally defined as well as internally defined. Eprise allows you to leverage both the assets of your directory server and Eprise features to empower your users. Understanding where your users are defined and the advantages of each is an important step of your implementation. Users defined as participant members (in Eprise) are called standard users. These users are created and searchable from within the Participant Center. Their roles and participant information can be readily viewed from the Eprise interface. Their permissions to the site are also set through the Participant Center. When taking advantage of a directory server, a minimal number of users will be standard users (typically just the administrator users). Users defined in an external source, the directory server, are called external users. External users exist only in the directory server and are not statically defined in the Participant Center. All participant information for external users is defined in the directory server. All of the role assignments for an external user are defined by a combination of the directory server configuration and the customization of the LDAP.cfg file. When taking advantage of a directory server, the majority of users will be external users. Users defined in both Eprise and the directory server (internally and externally) are called hybrid users. Creating hybrid users allows you to leverage the best features of both your directory server and the administration of the Eprise interface. When taking advantage of a directory server, a known quantity of users will be hybrid users. A hybrid user is created by simply adding an Eprise user for the same user in the directory server. As with an external user, a hybrid user takes advantage of centralized security and a centralized password available through a directory server. The hybrid user also takes advantage of all implicit and explicit role definitions declared in the LDAP.cfg file. In addition to the advantages of an external user, the hybrid user can also leverage the advantages of a standard Note: the Account Status of a hybrid user is determined by the status set in the directory server, not in Eprise. A Practical Guide to LDAP 39

46 Chapter 5: Internally and Externally Defined Users and Roles user. Specifically, the hybrid users can have their permissions (to modify and mange content) set within Eprise. Hard and Soft Roles Allowing a directory server to authenticate and authorize users to your Eprise site opens up a different concept to the use of roles as well as users. Programmatically assigning members to roles has always been an option but having an external source do it implicitly adds new value. Eprise LDAP support easily facilitates the use of LDAP groups and DN components as roles. If your Eprise site is taking advantage of LDAP, it is wise to have a clear understanding of internally and externally defined roles. Internally defined roles, or roles defined in Eprise are called hard roles. Eprise defines a role as a hard role if the role has been created in Eprise and exists in the Eprise role tree of the Participant Center. Defining roles through using the Eprise interface, or creating hard roles allow: 1 Members of a role to be users or other roles. 2 Definition of the key to members of a role (set to Member, Control or Enroll) 3 The Eprise administrator can easily view and/or remove members of a role (through the user interface). Roles are assigned to hybrid users and standard users through the Participant Center. Externally defined roles, or roles defined in the directory server are called soft roles. Eprise defines a role as a soft role if the role does not exist in the Eprise role tree of the Participant Center but can be referenced in Eprise. A soft role can be defined implicitly through the LDAP.cfg file or be referenced in merge strings. The use of roles defined in the directory server, or the use soft roles allow: 1 use of grouping and categorization of groups of users as defined in the directory server. 2 default of the key to members of a role to Member. 3 automatic maintenance of groups and users as defined in the directory server. Eprise facilitates the ease of incorporation of externally defined roles through the interface. Soft roles can be assigned to content through a free form entry option in the Assign Permissions window.!!note: the possible key values are Member, Enroll or Control. Enroll and Control are not useful outside the context of the Participant Center so these are not valuable attributes to a soft role. A Practical Guide to LDAP 40

47 Chapter 5: Internally and Externally Defined Users and Roles Choose the Enter LDAP Roles command button to enable free form entry into the role name entry boxes. In order for the permissions to be applied, the spelling of the role names must exactly match the roles assigned to the user through the implicit role assignment configured in the LDAP configuration file. A Practical Guide to LDAP 41

48 A Straight Forward Approach to Using LDAP As outlined in Chapter 5, Eprise allows users to be defined internally (with in Eprise as standard users), externally (with in the directory server) or both ( hybrid users ). Eprise provides the option to enable LDAP support for your site. If LDAP support is enabled, the support is at a user level (vs. a site level). Each user log in attempt is individually examined for the correct authentication method (internal or external or both). This flexibility allows you to take advantage of the each option. The previous chapters explain the Eprise LDAP configuration options available to authenticate and then authorize a user based on their definition in the directory server. Using those definitions, you must decide how to facilitate the ease of administration for both the site user and the site administrator. For this chapter, assume that you have properly configured your Eprise LDAP configuration to correctly authorize users based on their directory server attributes. A Hybrid Approach A Hybrid Approach refers to defining all of your users in the directory server (as external users) and also defining a subset of the users in as hybrid users Eprise. Member Users in the Directory Server As a common practice in most organizations, permissions to access the company network are granted in conjunction to the date of hire. Let s assume all employees ( users ) are created in the company directory server to be granted this essential access. After properly configuring Eprise to access the directory server, all appropriate users defined in the directory server will be granted access to your Eprise site. There is no administration required through the Eprise, this is an implicit function of using LDAP to authenticate and authorize users. A Practical Guide to LDAP 42

49 Chapter 6: A Straight Forward Approach to Using LDAP Control and Enroll users also defined in Eprise Hybrid Users With all appropriate users being able to access the site, the next step is to grant content management privileges to a subset of users as hybrid users. If your directory server implementation includes (and maintains) a detailed description of a user s function, you may have already mapped a directory server class object to Eprise roles that have content management privileges. If your directory server implementation does not include this level of detail, or it is something that is more prudent to administer closer to the source, you may define roles and users in Eprise. For example, the user Donald Tester4 exists in the directory server. You want to grant him additional privileges to content that you want to manage through Eprise. The following example enables this by creating him as a hybrid user. In the directory server: 1 Create the user as you would any user in your directory server. In Eprise: An account is created with the same login ID as the login id defined in the LDAP.cfg file for the directory server. The login id must be the Eprise login id. The mapping and search configuration options will be used to map the Eprise user to the LDAP user based on the login id. The Eprise password is a required entry here, but will not have any impact on the user s login. A Practical Guide to LDAP 43

50 Chapter 6: A Straight Forward Approach to Using LDAP The directory server user attributes are checked first during the authentication process. The directory server password will be used (when Donald logs in). The authentication process of a participant set to LDAP authentication type will use only the directory server user attributes during the authentication process. The directory server account status will be used. The Eprise account status is will not be used if the Authentication Type is set to LDAP. The Eprise user is set up to authenticate against LDAP. If you forget to select the LDAP authentication type, the user will not be authenticated against LDAP but only Eprise. Only the Eprise password, account status, and permissions will be in effect. Note: After you have assigned a user the Authentication Type of LDAP, the password is not longer applicable in Eprise. The directory server password is used. This is an important value add to your users. If for some reason you change your user s to an Authentication Type of LDAP, then modify them back to Eprise Standard you will be prompted for a password and the password will once again become editable on the Edit tab. A Practical Guide to LDAP 44

51 Chapter 6: A Straight Forward Approach to Using LDAP The user is a made a member of the role of ServicesEditor, and is assigned Control assess over the Services Content. Upon authenticating this user, all roles that have been configured through the LDAP.cfg file AND the roles assigned within Participant center are applied to this user. This user can now take advantage of all the categorization defined for him in the directory server as well as what is assigned to him in Eprise. Debugging the Authentication Method The User Cache section of the Cache report is available to debug the authentication method Eprise is using. If you have used a hybrid approach of creating all of your users in LDAP and a subset of your user in both Eprise and LDAP, it may be confusing where you are actually authenticating against. A useful confirmation of the authentication source is the Eprise user id. The rules are: 1 For the Eprise assigned user id: All positive numbers reflect an Eprise user (Standard and Hybrid users) All negative numbers reflect an external user (LDAP only) 2 For the DirSvcHandle: A Practical Guide to LDAP 45

52 Chapter 6: A Straight Forward Approach to Using LDAP Ηybrid users will reflect the derived User DN Standard users will reflect Standard 3 For the DirSvcUserKey: Ηybrid users will reflect the derived User DN Standard users will reflect Null In addition to referencing these values through a merge string, you can also access this value through the Help-> About -> Cache option. In this example, the users are as follows: Αdmin is a standard user (Eprise only) Αtester1 is an external user (LDAP only) Dtester4 is a hybrid user By examining the values in the User Cache, you can clearly see the method that a user has been authenticated under. dtester4 (hybrid user) was assigned a positive user id with the LDAP User DN in the DirSvcUserKey the positive user id reflects the Eprise authentication the DirSvcUserKey reflects the LDAP authentication atester1 (external user LDAP authentication) was assigned a negative user id with an LDAP User DN in the DirSvcUserKey the negative user id reflects the LDAP authentication A Practical Guide to LDAP 46

53 Chapter 6: A Straight Forward Approach to Using LDAP the DirSvcUserKey reflects the LDAP authentication admin (standard user Eprise Only) was assigned a positive user id with a null in the DirSvcUserKey the positive user id reflects the Eprise authentication the DirSvcUserKey reflects a null since this value has no value with an Eprise only authentication Examining the user cache can be very useful to confirm that your hybrid users have in fact been authenticated by the directory server. A Practical Guide to LDAP 47

54 Using Netegrity s SiteMinder with Eprise You may have chosen Site Minder by Netegrity to secure your web sites. Site Minder is a 3 rd party platform focused on implementing security policies to protect Web applications and resources. Two essential components of the SiteMinder product are the SiteMinder Policy Server and the SiteMinder Web Agent. The Policy Server is a server application that can connect to a variety of directories (LDAP, ODBC, NT Domains). The Policy Server provides authentication, authorization, accounting and policy management services. The SiteMinder web agent is a web server extension. The web agent scans all incoming request and matches the URLs against its Policy Server. If the Policy Server indicates that the URI is accessing a protected web application, then the Web Agent will follow the rules constructed in the Policy Server. Once the user has entered credentials (loginid and password for example), the Web Agent asks the Policy Server to validate the credentials. Assuming they are validated, the web agent will then forward the original request along to the intended web application (Eprise in this case), with the addition of a set of proprietary SiteMinder HTTP headers. Eprise will then use the proprietary HTTP headers to determine the identity of the user. Integration Modes Eprise supports two modes of integration with Site Minder. As a developer authenticating your users against a directory server, you should consider both options and determine which best suits your needs. There two available modes in Eprise for the integration are LDAP and HTTP. Each mode uses SiteMinder to do the authentication. The distinguishing feature of these two modes is where the authorization rules are configured. Each mode authenticates against the Policy Server. The difference is just where the authorization rules are defined. The LDAP mode allows you to configure Eprise roles and preferences through the LDAP.cfg file. The HTTP mode assumes you have configured SiteMinder to determine your roles and allows you to configure the A Practical Guide to LDAP 48

55 Chapter 7:Using Netegrity s SiteMinder with Eprise Eprise roles and preferences through the SSOAuth.cfg file. The following diagrams show the differences in the modes. Mode 1: Eprise and SiteMinder directly access your directory server. SiteMinder performs authentication and provides the User DN to Eprise via a HTTP header. Eprise then loads the authorization attributes from directory server based on settings in LDAP.cfg. Integration Mode 1: LDAP Browser IIS ISAPI: SM Web Agent SM Policy Server ISAPI: Eprise LDAP Mode 2: Eprise is not connected to LDAP. SiteMinder may be connected to any authentication method it supports. After performing authentication, SiteMinder sets one or more special HTTP headers (called SiteMinder responses) based on information found in the user directory. Eprise then populates the user profile (roles and account info) based on the settings in SSOAuth.cfg. Eprise has no direct access to the user directory. A Practical Guide to LDAP 49

56 Chapter 7:Using Netegrity s SiteMinder with Eprise Integration Mode 2: SiteMinder Responses Browser IIS ISAPI: SM Web Agent SM Policy Server ISAPI: Eprise LDAP, ODBC, other If you have configured SiteMinder s Policy Server to correctly map your directory server users and groups to valuable roles, and / or it is a central corporate repository for role and preference mappings you should consider using HTTP mode. Of course, if your users reside in some repository supported by SiteMinder that is not an LDAP directory service, you would also configure the HTTP mode. All other users should use the LDAP mode and follow the guidelines provided in the previous chapters to configure the authorization of the LDAP users. An important note is it is essential to Eprise to receive the proper header information. Eprise MUST receive the ServerSessionID from SiteMinder. Each integration mode SSOAuth.SessionKey=SM_SERVERSESSIONID in the SSOAuth.cfg file. Siteminder must pass this variable in the session header. The SiteMinder option DisableSessionVars: 'NO' Should be left at it s default (of NO). If it is set to YES, you may not receive the SM_SERVERSESSIONID. See the working example listed below for an example of examining the HTTP Header allowing you to verify the SiteMinder information available. Using the LDAP Authentication Method With the SiteMinder and LDAP integration, the Eprise site user will be authenticated through SiteMinder and authorized through the Eprise LDAP configuration. A Practical Guide to LDAP 50

57 Chapter 7:Using Netegrity s SiteMinder with Eprise SiteMinder 5.5 is composed of 2 main components of the Policy Server and the Web Agent. At a very high level, the policy server defines the security rules and the web agent enforces the rules. You should confirm you have a correct installation and configuration of your Policy Server and Web Agent before testing against LDAP Integration Similar to setting up a straight LDAP configuration, the authorization attributes will be configured in the LDAP.cfg file. If you have not already set up your LDAP.cfg file, you should do this first. For information on setting up your LDAP.cfg file, follow the directions outlined in chapter 4 (Understanding Authorization to Content) of this document. The configuration of the SSOAuth.cfg file is very straight forward. Uncomment the suggested values and comment out everything else. ; Suggested setup for 1) SiteMinder Auth-Only with LDAP.cfg ; (Configure and test LDAP.cfg SSOAuth.UserLogin=SM_USER Setting Up your Configuration Both integration methods require you to configure the SSOAuth.cfg file. This file is used by the SSOAuth plug in. You may confirm the SSOAuth plug in is loaded by examining the plugins listed in the Eprise Help About page. If the SSOAuth plug in is not listed, you must include it in the extension.libraries parameter of the misc.cfg file. This parameter contains a comma separated list of plug-ins. You should add ssoauth.dll to the list. Configuration File Overview As described in Chapter 4, authorization attributes can be configured from an external source. As with the options with LDAP, the SSOAuth.cfg file provides options to map the A Practical Guide to LDAP 51

58 Chapter 7:Using Netegrity s SiteMinder with Eprise authentication and authorization attributes from SiteMinder to Eprise. Both methods use the authentication options. The LDAP integration method uses the options defined in Chapter 4. The HTTP integration method allows you to map the authorization attributes. The attribute mapping categories are as follows: 1 Preference Mapping This section defines SiteMinder assignments to Eprise merge strings. This allows Eprise to take advantage of any attributes defined in SiteMinder through merge strings. 2 Role Mapping The SiteMinder roles can be mapped to Eprise roles. SiteMinder defines roles through the IdentityMinder add on. If you have defined the roles through IdentityMinder, they can be mapped and referenced through the Eprise client namespace. Very similar to the rules defined in Chapter 4, you can map the SiteMinder user preferences to the Eprise client namespace for reference in your Eprise site. In Eprise, create a user defined preference to allow a reference. This example defines an internal name of MemberStatus. A Practical Guide to LDAP 52

59 Chapter 7:Using Netegrity s SiteMinder with Eprise This creates a component in the client namespace as client.pref.memberstatus. Suppose there is an attribute in the user definition (in the directory source of SiteMinder) called SM_MEMBER. The following configuration option would map the SiteMinder SM_MEMBER to the client name space. (See <$client.http.all_raw> example to examine SiteMinder HTTPDirSvc.account.map.SM_MEMBER=MemberStatus Configuring SiteMinder roles to map to soft or hard roles in Eprise is very similar to the implicit LDAP role mapping detailed in Chapter 4. A difference is the way the information is passed in the HTTP header. Role headers and a separator are defined in the SSOAuth.cfg file. Each role header is parsed and the roles are implicitly applied to the user. The following example, two role SiteMinder headers are of significance, EmployeeCategory and Location. The user is assigned to multiple roles in the EmployeeCategory ( Employee and Contractor ). The user is assigned to one role in the Location ( Burlington ).The HTTP request contains the following header: A Practical Guide to LDAP 53

60 Chapter 7:Using Netegrity s SiteMinder with Eprise EmployeeCategory: Employee^Contractor, Location: Burlington The SSOAuth.cfg file would be configured as follows:.@!define@ HTTPDirSvc.role.header=EmployeeCategory,Locatio HTTPDirSvc.role.header.separator=^ To verify exactly what is coming back in the HTTP header, create an Eprise page that contains the following mergestring: ALL_RAW: <$client.http.all_raw><br> If you analyze the string returned, you will see the HTTP headers followed by a :. A sample of the output is as follows: SM_SERVERSESSIONID: Dpym5mNK72BF/NldGrHb6NNCzWU= SM_SERVERSESSIONSPEC: Ovf3GXqDWEapCxIoRJ9xRO+4Pg9CmtX8kOJxFucesvvWWT8SRUT/ UuNcFQuBO5IiajcSQS56j5qkd+xaE8avic0720oPP6jaWkbXzxP7Y SDOHurvrPmte8g/ +veogetcxsc6aynqfk3xzqbgvcq9rgf1ubb19bwuonvwsg+eoxhry Fn5F3xYIVleN3Gw9DsuAKJl// LgUiiVaWAbzbxkR11LCu3fospneTMjaoZ4fhZOj1kK87wFqW1v71k ErSa1Ib0he/ HSFLdMolqSu0n2joaFtkArkg3D5haPNNCasHYvvvn0TDo+5q31Fod Xwi/ rejdhn1ijxzceoanqh4ti9+d5lgvkjjawlc7k9qtbgljdtutrbndy qeocx+u74pbn SM_AUTHDIROID: 0e-94e1e f-11d4-8ca8-0008c7df6a81 SM_AUTHENTIC: YES employeecategory: Employee^Contractor location: Burlington SM_MEMBER: Gold SM_AUTHORIZED: YES Based on the HTTPDirSvc.role.header definition in SSOAuth.cfg, the user s role list would now include Employee, Contractor, Burlington. If one of these roles was not previously defined in Eprise, it would be recognized as a soft role. See Chapter 5 for more information on hard and soft roles in Eprise. In addition to implicitly assigning roles, you may also explicitly assign a SiteMinder role to an existing Eprise role. This is done through an explicit role assignment in the SSOAuth.cfg file. As per Chapter 5, the following example shows a hard role mapping. This example assigns the SiteMinder role of Burlington to an Eprise Role of HTTPDirSvc.role.map.Burlington=NorthEast Similar to the LDAP.cfg file, the SSOAuth.cfg file also has the option to exclude roles. Since roles can be implicitly assigned A Practical Guide to LDAP 54

61 Chapter 7:Using Netegrity s SiteMinder with Eprise through declaring the header and separator, you may want to exclude roles from being inadvertently assigned. An example of excluding the role master would HTTPDirSvc.role.ExcludedRoles=master For addition information on excluding roles see Chapter 4. A Practical Guide to LDAP 55

62 Appendix Privileged Connections and Using EENCRYPT The initial connection to the directory server is an anonymous bind. For security reasons, most implementations of directory servers will require a privileged connection to conduct a search. If this security has been set up in your implementation, and you plan to use user search to authenticate a user, or group search to authorize users, you will require a privileged connection to the directory server. The LDAP.cfg file includes a section to define a privileged connection to the directory server. There are two variables, the PrivilegedUser.DN and the PrivilegedUser.Password. In the event the user search and/ or the group search are enabled, Eprise will use these credentials to establish another connection to the directory server for the LDAP.ServerConfig.PrivilegedUser.Password= To prevent you from including your userid and password in clear text, you will include an encrypted version of the user DN and password. The eencrypt command line utility is included with Eprise for this purpose. It is located in the /eprise/bin directory of the Eprise installation. The command line format is: eencrypt configurationparameter value (each item is delimited by a space). Eencrypt will require you to enter the admin password for Eprise. A Practical Guide to LDAP 56

63 Appendix In the following example, the user DN for the user ATester will be returned encrypted C:\Eprise\bin>eencrypt LDAP.ServerConfig.PrivilegedUser.DN "CN=Adam A. Tester1,OU=EpriseProducts,DC=epriseldap,DC=silkroadtech,DC=com" ******************************************* * eencrypt for Eprise * ******************************************* Enter the Eprise Admin password :eprise Password has been accepted Unencrypted LDAP.ServerConfig.PrivilegedUser.DN = CN=Adam A. Tester1, OU=EpriseProducts,DC=epriseldap,DC=silkroadtech,DC=com Encrypted LDAP.ServerConfig.PrivilegedUser.DN = encrypted::672b E E110E0B A A B28325A E B23245A E14024A0B B23245A140E0B0C F4B23245A04080A A Practical Guide to LDAP 57

64 Appendix The entire sting (including the value encrypted:: ) should be copied to the LDAP.cfg LDAP.ServerConfig.PrivilegedUser.DN=encrypted::571B E E213E3B A A B18026A E B13146A E24327A3B3336 wcc200.dll Special Notes: 1 If the user s DN contains spaces you must delimit the user DN with double quotes 2 If you see errors return before the output value, you must install the Microsoft Visual J#.NET Version 1.1 Redistributable Package. This is available from Microsoft Download site. 3 The configuration parameter wcc200.dll should be included after any encrypted value. This tells eprise to decrypt the value. You will run the eencrypt utility two times, once for the UserDN and the next time for the user password. You will paste both values into the LDAP.cfg file. Working Example: Using LDAP for a Single Login ID and Password Assume for this example that all of your users and role assignment exist in Eprise. Now your organization would like to take advantage of your corporate directory server for Login ID s and passwords only. You are not going to use any of the role assignment configuration options available to you through the directory server, but you really want to give your users the value add of a common login id and password. All role assignment would happen in this example through Eprise. A super set of users exists in the directory server, and a subset of those users exist in Eprise. The Eprise users will be assigned to roles through Eprise (see Chapter 5 for information on hybrid users). A Practical Guide to LDAP 58

65 Appendix In this example, a user whose login id is dtester4 exists as a user in Eprise and in Active Directory Server. In Eprise, as a Eprise Standard user, the password is mypassword. Their corporate password (defined in an ADS directory server) is mycommon$. Listed below are some straight forward rules to implementing LDAP for login id s and passwords only. In Eprise: 1 You must visit each of the existing users in your Eprise Participant list and change the Authentication Type on the Advanced Tab to LDAP (vs Eprise Standard). 2 After enabling the LDAP Authentication Type, the Eprise password is no longer used. a The password no longer appears on the Edit tab. b The password will re-appear if you change the authentication type back to Eprise Standard In your Eprise LDAP.cfg: 3 Your user will need to log in through LDAP. Use the rules as outlined in Chapter 3 to determine your LDAP authentication method (apply a template, sub tree search or a component match in NDS). Your existing Eprise login id s must: a b exists in some attribute (attribute value) in your directory server OR be able to be mapped to an LDAP attribute through the Eprise authentication string (see Chapter 3 for additional information) For example, if your Eprise logins are the first letter of first name + last name or address, those values must exists in your directory server. 4 Blank out all references to the LDAP Authorization settings in the LDAP.CFG file (as provided in the next section) In your directory server: 5 No changes. Configuration of the LDAP.CFG In the following example, a standard Eprise user exists. In Eprise he is assigned the role employee. This example authenticates against an Active Directory Server directory server. This example uses a User Search to location the user through their unique identifier of samaccountname. The samaccountname contains the first letter of the first name + the last name in this A Practical Guide to LDAP 59

66 Appendix directory server implementation. For this example, this matches the login id s in Eprise. All of the informational comments have been removed from this example to increase the readability. You can use this example verbatim but you must modify the server name, port and adjust your DN Mapping method to locate your users (see Chapter 3). This implementation of the directory server requires a privileged user to conduct a user search. You will also have to change (and encrypt) the privileged user DN and privileged password at the end of the file. You must do this only if you are also using the SupportSearchForUser option. If you are not using the SupportSearchForUser option, this information will not be used in the file. ; ***************************************************** ************; ; File/Module Name: LDAP.cfg ; ; Description: LDAP authentication configuration file ; ; Eprise Version: 2.6.7, 3 ; ; LDAP server: NetScape Directory Server 4 ; ; Author: Andy Rappaport ; ; Copyright Eprise Corporation, ; ; The Copyright to the computer program(s) herein is the property of ; Eprise Corporation. The program(s) may be used and/ or ; copied only with the written permission of Eprise Corporation, A Practical Guide to LDAP 60

67 Appendix ; Inc. or in accordance with terms and conditions stipulated in the ; agreement/contract under which the program(s) have been supplied. ; ; ***************************************************** section.ldap=ldap Configuration ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;; ;; Support LDAP ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; LDAP.SupportLDAP=1 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;; ; LDAP DN mapping LDAP.DNmap.SupportSearchForUser=1 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;; ; DN Templates - LDAP server dependent ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;; LDAP.Separator=; A Practical Guide to LDAP 61

68 Appendix LDAP.ServerConfig.name=default LDAP.ServerConfig.default.server=ldap-eng LDAP.ServerConfig.default.SSL=0 ; LDAP.ServerConfig.default.DN_template= ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;; ; Attribute Map - LDAP server independent ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;; LDAP.attribute.prefix=LDAP_ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;; ; Preference Mapping ; ; Preference Mapping - None ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;; ; Role Mapping - LDAP server independent LDAP.role.ExcludedRoles= ; Role Mapping - LDAP.role.RestrictSoftRoleList=0 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;; A Practical Guide to LDAP 62

69 Appendix ; LDAP Users - Locating Users. LDAP server dependent LDAP.user.FilterTemplates=(sAMAccountName=<$client.fo rm.verloginid>) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;; ; LDAP Groups - LDAP server dependent LDAP.group.GroupNameInUserObject=0 ; LDAP Groups - None ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;; ; Privileged account Info - LDAP server independent LDAP.ServerConfig.PrivilegedUser.DN=encrypted::5F131B 1E0F710C3A2D293A2D1C F2D A383A3B0 A2C3A2D711B111C11621E3B C2B2D3E2B302D731C1162 A Practical Guide to LDAP 63

70 Appendix 0A2C3A2D2C731B1C623A2F2D362C3A72333B3E2F731B1C622C D303E3B2B3A3C37731B1C623C3032 wcc200.dll LDAP.ServerConfig.PrivilegedUser.Password=encrypted:: 2B676F6A7B05784E595D4E D424C057B59425D42474E4 C4E4F7E584E59057B4A58585C44594F0F4E5B E0F wcc200.dll Step by Step Login This is a step by step login procedure as configured above. Example One A Hybrid User dtester4 is a user that exists in both Eprise and your directory server. dtester4 is an example of your typical Eprise user. 1 The user logs in using dtester4 and the common password of mycommon$. This is the directory server password. This is not the Eprise password. A Practical Guide to LDAP 64

71 Appendix 2 The user is assigned to ONLY the employee role that was created in Eprise. All users are added to the everyone role by default. Example Two-An External User atester1 is a user that exists only in your directory server. atester1 is an example of your typical user entered into the directory server, who has no access to Eprise content. This user is part of the superset of users that exist in your directory server BUT not in the subset of your Eprise users. 1 The user logs in using atester1 and the common password of mycommon$. This is the directory server password. This is not the Eprise account. A Practical Guide to LDAP 65

72 Appendix 2 The user is assigned to ONLY to the everyone role by default. This example allows all LDAP users to log into the site using their LDAP userid and password, but only the users defined in Eprise would have any roles assign for access to the content of your site. A Practical Guide to LDAP 66