smaller reset larger        English         

Main Menu

All times are in GMT -8 (DST) :: The time is now 3:59 pm.

Sub Menu

Article Data
Article Ref
3799-FIBM-9462
Written By
Thom O'Connor
Date Created
Fri, 31st Aug 2007
Updated By
Thom O'Connor
Date Modified
Fri, 7th Sep 2007
 
(Lost?)

   LDAP Authentication against an Active Directory server

Question 

How do I use external LDAP authentication against an Active Directory server?

Answer 

Overview:
External LDAP Authentication with CommuniGate Pro requires an authentication plugin. There is more information on this topic, as well as sample authentication plugins, here:
   http://www.communigate.com/CGAUTH

The latest such plugin, and the one we'd recommend for its improved functionality (supports multiple LDAP servers and better character handling), is this one:
  https://support.communigate.com/scripts/authLDAPNew.pl

Active Directory:
Please note, we are not necessarily Active Directory experts. More more info, you may need to reference the Microsoft Support Site.
However, it appears that Active Directory stores its user accounts in this LDAP tree, by default:
   cn=users,dc=domain,dc=com

Example:
For our purposes here, we will use the example domain "example.com", and an active directory server named "ad.example.com"

One good technique when working these things out is to first test LDAP functionality using an ldapsearch client or browser. We will use the OpenLDAP command line tool "ldapsearch" here:

Using ldapsearch, here is one apparently successful method of querying Active Directory via LDAP:
 # ldapsearch -x -H ldap://ad.example.com -D "Administrator@example.com" -W -b "cn=users,dc=example,dc=com"
Enter LDAP Password: *******

Result:
# extended LDIF
#
# LDAPv3
# base <cn=users,dc=example,dc=com> with scope sub
# filter: cn=test1
# requesting: ALL
#
# Test1, Users, example.com
dn: CN=Test1,CN=Users,DC=example,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
<snip>
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
The above represents a successful "bind" against the LDAP server using the Administrator@example.com "bindDN", and a successful retrieval of the "test1" account data. This type of bind and data retrieval is useful, though not immediately applicable to this particular example, as it uses a special bind account (such as Administrator). Often, for security purposes as well as overall simplfication, we would prefer to bind as the actual user who is trying to authenticate - this is how the authLDAPNew.pl script works in most cases.

Therefore, if using any of the authLDAP scripts for external authentication, one would likely configure it like the following, for integration with Active Directory:
address=>'ad.example.com',                      # the address or IP of LDAP server
timeout=>5, # timeout in seconds, 20 by default
adminDN=>'', # the DN for admin bind
adminPassword=>'',
searchBase=>'cn=users,dc=example,dc=com', # search base for NEW and SASL commands
searchFilter=>'(&(cn=<user>)(objectclass=*))',
bindDN=>'cn=<user>,cn=users,dc=example,dc=com', # the account DN for direct bind for VRFY command

Please note: the "adminDN" and "adminPassword" entries are not used for a standard "bind as user" authentication mechanism, therefore you can choose to leave this entries blank for this method of authentication. If using an external authentication "READPLAIN" authentication method - which is required to use external LDAP authentication with Pronto or for any SASL challenge-response mechanisms (such as CRAM-MD5, DIGEST-MD5, or NTLM), then the "adminDN" and "adminPassword" fields must be used in order to perform a "bind as special account", which is allowed to retrieve a plain-text password. There is more information on this technique here:

https://support.communigate.com/tickets/kb_article.php?ref=2272-WTXV-8661

How Useful Was This Article?      (Rating: 68%    Votes: 5)  

Select a Rating

Article Comments 

There are currently no comments.