Active Directory DataSource Configuration for Avaya OSPC OSPC LDAP Integration overview
LDAP based data sources like Microsoft’s Active Directory (AD) will be a popular integration for the OSPC phonebook server. OSPC supports up to 20 different read-only connections for OSPC phonebook server which utilize the use of LDAP or ODBC based connections. The purpose of this tech note is to give guidance for configuring an OSPC phonebook data source to make use of Microsoft’s Active Directory using LDAP.
LDAP Tools
When engaging in LDAP based connectivity it is good to have some tools and information readily available. Since this integration involves Active Directory and a Windows Domain at a minimum you should first consult with your proper domain and AD support groups to learn about the proper way to connect to and query AD using LDAP. You will find at times certain rules apply like the need use certain credentials or secure LDAP 636(SSL).
OSPC supplies the Softerra (www.ldapbrowser.com) in the software/Service-Tools/LDAPBrowser directory. The Softerra LDAP browser is a free to use UM standard LDAP v3 compliant browser that will be helpful at times for the OSPC admin. Basic steps to immediately use the LDAP browser are as follows:
NOTE – for more advanced use please consult the LDAPbrower help guide
NOTE: You can enter a domain controller (DC) address or top level domain
www.yourcompany.com and allow DNS to handle the LDAP service request 389 and version 3 are standard
Enter your domain account and password – if querying against a domain that you are NOT currently authenticated against but you possess a valid account for use the domain/username combination for the user DN
NOTE – it is expected that the OSPC Server will be installed in the same AD domain as the clients and the operators will authenticate using normal user domain accounts
With LDAP browser you will be able to see how the directory is organized meaning which organizational unit(s) (OU) hold the required user accounts and in each user account which attributes are being used
SET command:
Another tool to use on the OSPC server is the SET command in a command shell on the OSPC server. Start Æ Run Æ cmd will invoke a command shell and if you simply type SET and hit return you will see the many system variables being displayed. By using the SET command you can quickly determine some key bits of helpful information:
USERDOMAIN = Domain name of accounts domain
LOGONSERVER = Server Address for authenticating DC if top level domain search if not working (DNS service records need to exist)
USERNAME = Current Username
USERDNSDOMAIN = Should make up the Base DN. For example: DC=mydomain,DC=com
NOTE – for this to be useful the OSPC server or client needs to be part of the domain and the account used to login successfully authenticated in that target domain
TECH TIP: Since the SET command scrolls by fast collecting its output information to a text file for review is sometimes preferred:
C:\SET > c:\temp\set_output.txt
Very good examples of building LDAP datasources are listed in the published “OSPC 2.50 connected to ACM Service and Installation Manual”. This example will in fact follow the example given for: Example 5 for Exchange5.5 data source using a JDBC– LDAP bridge
Launch the OSPC config tool: Programs Æ Avaya Æ OSPC Æ ConfigTool Login (default is avaya/000000 (six zeros))
Expand Phonebook and in the default form you can select “New” to start a new form The form screenshot below is where you enter connection information and the initial SQL query statement to pull from AD only the attributes that are useful for OSPC. OSPC config tool Phonebook connection form:
NAME: customer defined
DESCRIPTION: customer defined DRIVER: JdbcLDAP driver as shown
*PROVIDER URL: jdbc:ldap://(yourcompany.com or domain controller
name/address):389/DC=(x),DC=(y),DC=(z)?SEARCH_SCOPE:=subTreeScope&pageSi
NOTE: subTreeScope is important to be able to search nested subtrees of the
base DN. A flat directory would be very rare so subTreeScope is usually needed.
USER: current domain and account: domain\account
NOTE: This is key to solving binding issues and to pass the proper credentials
through as most domains do not allow non-binding or ANONYMOUS LDAP queries
PASSWORD: current domain password
SQL STATEMENT: SQL query desired, for example:
SELECT DN,sn,givenName,distuinguishedName,cn,mail,telephoneNumber,department from OU=subtree,OU=subtree Users WHERE sn=*
NOTE: The amount of subtrees depend on what you learn about your specific
AD schema. For example there may be main accounts OU and under that accounts OU several other OU’s exists for each region or country so for example you may see I the schema: OU=global accounts and under that OU=Asia
accounts, OU=Europe accounts and so on. The OSPC installer/admin will hae to work with the customer to determine which account are targeted and from which OU; top level or even subtree.
*x.y.z = your AD base DN in the form of domain components (DC’s) not to be confused with domain ctonrollers (DC’s): for example accounts.yourcompany.com will be split up into 3 DC’s x.y.z to plug into the provider URL above.
x=accounts.y=yourcompany.z=com
Now that you entered your connection information select “Save” which will test the connectivity and report any errors.
To purge the records simply purge by selecting “Remove Records”
Mappings:
The mappings tab on this connection profile allows for AD field mappings to fields in the OSPC phonebook database.
An index primary key is needed. distinguishedName is a good source for a unique primary key attribute for indexing purpose. If when searching using OSPC client multiple records are found for unique search criteria you can add additional index keys until uniqueness is achieved.
Next map the source fields to appropriate OSPC database target fields and continue until customer requirements are met and the appropriate AD attributes are mapped to OSPC database fields. Use results from the LDAPbrowser to determine what user account level AD attributes to request to build the SQL query statement in the conenctoin form
properly.
NOTE: The minimum mappings are the surname(sn) for Last name mapping and the
primary business phone number (telephoneNumber ) mapping to Business 1
This screenshot shows givenName (first name) being mapped to the OSPC First Name field:
Common minimum mapping example:
NOTE: Index key does is not required to map to an OSPC target field. It can act independently and often does.
NOTE: “Reload will restore previous connection configuration if desired BEFORE
selecting Save
Update Service:
It is good to schedule the first dataset pull for a time in the near future. For example 2-5 minutes from time you set this form. Once you activate and save the schedule a
connection will perform the initial pull of the datasets into the OSPC database based on the update time setting provided.
The best way to monitor that these transactions have occurred is to monitor the
performance tab in task manager: Start Æ Run Æ taskmgr and select the ‘performance” tab and pay attention to the CPU utilization.
This completes the backend AD/LDAP configuration tasks needed to enable OSPC client/sever to connect and query against an Active Directory data source.
