03/07/08 © 2008 DSR and LDAP Authentication Avocent Technical Support

© 2008 Prerequisites The student should have a basic understanding of the purpose of LDAP The student should have a basic understanding of LDAP terminology and syntax The student should be able to recognize a basic LDAP query string

© 2008 Objectives Demonstrate the ability to successfully setup DSR LDAP authentication in for Basic, User Attribute and Group Attribute Illustrate using Active Directory how the authentication mechanism takes place and where the user and group attributes are located in AD Explain in general terms how LDAP authentication would be setup in a Non-Microsoft LDAP environment

© 2008 DSR OBWI and LDAP With release of / code base, DSR’s now support LDAP authentication via OBWI, OSCAR, and DS Remote Operations software With the release of LDAP authentication, the DSR Name can now be modified in OBWI. This is to facilitate the use of Appliance Group Attribute LDAP authentication. DSR LDAP authentication does NOT support anonymous binding (Search DN and password are necessary) When Authenticating via LDAP, NO local accounts or Access Controls are kept on the DSR. All accounts and access control mechanisms are contained SOLEY on the LDAP server DSR LDAP has been primarily designed and tested using Microsoft’s implementation of LDAP in Active Directory ONLY. Use of Non- Microsoft versions of LDAP may result in limited or no functionality with other Third Party LDAP applications.

03/07/08 © 2008 Setting up LDAP authentication via the OBWI (On Board Web Interface)

© 2008 Overview page LDAP is enabled via this page. LDAP can be configured to either default to authenticate either primarily via LDAP (LDAP before Local) or Locally (LDAP after Local) Both Primary Server and Secondary server information must be entered, even if only one LDAP server is being authenticated against Choosing LDAP or LDAPS will default to the appropriate TCP port number, but this port number can be modified to match ports used by existing LDAP server

© 2008 LDAP search :Search DN and Search Password All Searches must have a search DN defined. No anonymous searches The first term of the Search DN is always the username. Subsequent terms show where on the LDAP tree the account exists Search Password: Enter the password of the account defined in the Search DN field

© 2008 Example of Search DN as seen in Active Directory Example: cn=dsbrowse, cn=users, dc=hsvtechlabad, dc=avct cn=dsbrowse cn=users dc=hsvtechlabad, dc=avct This is an example of the dsbrowse user account in AD users and computers Note: How the search dn starts at the actual account and moves “up” the tree. Once it hits the “root” level of the domain, each domain component is listed in order from left to right. Domain components separated by periods when in FQDN notation, and has it’s own “dc=“ entry in LDAP notation

© 2008 LDAP Search: Search Base and UID Mask The Search “base” designates where you want to start your search. A search base will only search the designated container or ou and all child containers or ou’s. Thus, a search base of only domain components designates a search of the entire domain. UID Mask: This designates what LDAP attribute on the LDAP server the “Username” provided by the customer on the login screen of the DSR will be compared to. This attribute is case sensitive and is followed by the term “=%1” to indicate to the DSR to use the contents “Username” on the Login Page field as the string to be compared.

© 2008 Example of UID mask in AD sAMAccountName=%1: This means compare the username entered at the login screen of the DSR to the LDAP Attribute “sAMAccountName” on the AD server. sAMAccountName NOTE: The “sAMAccountName” attribute is unique to Windows Active Directory installations and refers to the “User login name (pre-Windows 2000):” field. On non-Windows LDAP servers, this attribute does not exist. The customer will need to determine what attribute to use for the UID mask for their particular brand of LDAP server. (Usually uid=%1)

© 2008 Query Screen QUERY MODE: Allows for three “levels” of Authentication. You choose which mode you want to use based on how “granular” you want your access rights to be: These modes can be assigned to either the appliance itself, or to the target devices connected  Basic: All LDAP authenticated users have full administrative rights to the appliance and full access rights to all attached target devices: If the appliance is in “basic” mode, the target devices are automatically in “basic” mode”  User Attribute: The DSR looks for a specific “User Attribute” that is placed in the actual LDAP user account, to determine that user’s access level. User Attribute is usually done when you want to give a user “universal” access rights to all appliances or target devices.  Group Attribute: This is the most granular of the three levels and is used to specifically limit a user not only to individual appliances but to individual target devices on a given appliance. ACCESS LEVELS: Access Levels are the attributes that are placed either in an individual user account object or group object to define the access level to be assigned. Access Levels are as follows:  KVM Appliance Admin Can modify User, Appliance and Target Device settings.  KVM User Admin Can Modify User Account settings but can not modify actual Appliance or Target Device Settings  KVM User Can only initiate KVM over IP sessions ACCESS CONTROL ATTRIBUTE: This is the name of the field that you want the DSR to search either in the User Object, or Group Object in the LDAP schema. The DSR looks in this “field” to find the ACCESS LEVEL designated above.

© 2008 Example of LDAP Query Screen

© 2008 Example of User Attribute Administrator grants user one of three access levels Admin puts this “attribute” into a “field” on the actual users “account” on the LDAP server. (NOTE: These access levels are case sensitive and MUST be typed exactly as shown above) DSR only allows login for authenticated users that have this “attribute” located in their account. By default, In AD we use the “info” field which corresponds to the “Notes Field” under the “Telephone” tab in the User properties in AD. Any “field” can be used, but the user must find out what the LDAP designation for that field is, and then change the Access Control Attribute on the DSR to the appropriate value In this example, William Thomas Would be given “KVM Appliance Administrator access to ANY DSR with “appliance” set for “User Attribute”, And can start KVM sessions on all DSR’s with either Appliance or Target Device set to “User Attribute”

© 2008 Group Attribute Group Attribute is much more granular than User Attribute. The administrator MUST create Appliance Objects, and Target Device Objects that match the names of the Appliances and Target devices in their LDAP server (In AD, It is easier to make sure your “IQ module” names match the existing computer objects already existing in AD, than to create duplicate objects) The administrator then places the Appliance objects, Target Device Objects, and User Account objects into a “security group” The administrator then sets the “access level” of that group via the group attribute. The Authenticated LDAP user then gets the access level that is assigned via the group attribute to ONLY those appliances and target devices designated in their group. When setting up GROUP attributes, additional information is required to allow the DSR to properly query the group. This information is Greyed out when using both Appliance and Target device Query Modes are set to either “basic” or “user attribute”  GROUP CONTAINER: Defines the OU where the Group Objects defining Access Levels are located  GROUP CONTAINER MASK: Tells the DSR server what “type” of container the group object is in the LDAP schema (usually an OU or Organizational Unit) The DSR will perform a search of all “OU’s” in the schema, starting at the “Group Container” for the Access Level defined  TARGET MASK: Tells the LDAP server what type of objects the “target devices” are represented as in the LDAP schema (usually a CN)

© 2008 AD Example of Group Attribute By default, In AD we use the “info” field which corresponds to the “Notes Field” under the “General” tab in the Group properties in AD. Any “field” can be used, but the user must find out what the LDAP designation for that field is, and then change the Access Control Attribute on the DSR to the appropriate value All users in this group are given KVM User Access Rights to the objects in this group As shown in the Members Tab: William Thomas has, KVM User Access to the DSR: SVDSR8035, and can ONLY open KVM sessions to two target devices: LDAPServer-252 and TechLabAD-251

© 2008 Special Considerations In OBWI authenticated users see ALL the target devices listed on the appliance. Even ones they don’t have “rights” to. If they do not have “access” to a target device this denial of access will occur when the user tries to initiate a KVM session to the target device. This is markedly different from DSView 3, where authenticated users can only “see” the servers they have rights to. The examples given in this presentation will allow you to get OBWI LDAP authentication functional in an AD environment. Other LDAP implementations will be similar but have it’s own unique terminology

© 2008 Special Considerations (Cont.) Target Device Objects and Appliance Objects on the LDAP server must EXACTLY match the Target Device and Appliance Names. LDAP Attributes are often case sensitive and must be entered exactly as appears on the LDAP server in the UID Mask, Group Mask and Target Device Mask fields For LDAP Group and User attribute to work, the LDAP server must be able to respond to a “blank” search filter (like AD does). Some LDAP servers like E-Directory and Sun LDAP do NOT respond with data for a query with a blank search filter and as such will ONLY work on Basic Authentication.