I2A2 LDAP
I2A2 provides a protocol converter that:
- Translates Lightweight Directory Access Protocol (LDAP) to I2A2 DBM protocol, bypassing the net daemon I2A2 external protocol;
- Communicates with I2A2 DBMs;
- Returns DBM replies converted to LDAP protocol;
- Conforms to LDAP protocol version 3, LDAPv3. (Does NOT support LDAPv2.)
The latest LDAP protocol version, LDAPv3, is described in RFC 2251 and related
RFCs. Another excellent reference is a book sometimes called the "LDAP bible". The
book is titled Understanding and Deploying LDAP Directory Services, and it was written by Timothy A. Howes, Ph.D., Mark C.
Smith, and Gordon S. Good.
The I2A2 LDAP protocol converter is a true LDAP server, conforming to RFC 2251 and LDAPv3. It is built from source code
(version 2.1.21) made available by the OpenLDAP project. That open source project
provides code for an LDAP server, usually called slapd, that can be customized with private data base interfaces,
called "back ends." The I2A2 LDAP server has a custom back end that communicates with the I2A2 DBMs in their language and
translates DBM replies into LDAP replies.
LDAPv2 NOT Supported Please note that the I2A2 LDAP protocol converter does not support the deprecated version 2
of the protocol., LDAPv2. The converter only supports version 3, LDAPv3. Client LDAP APIs that default to LDAPv2 should be
reconfigured to use the more current LDAPv3 instead. Consult your client API documentation for more information on doing that.
If you have trouble reconfiguring your client API to use LDAPv3, please contact
I2A2 Administration for assistance.
I2A2 LDAP Schema
The I2A2 LDAP schema is based on the standard core, cosine and inetorgperson schemas.
It uses the base Purdue X.501 Obejct IDentifier number, 1.3.6.1.4.1.4440.4, and extensions to it to add I2A2 LDAP items. The
items that have been added may be found in the
I2A2 Schema description.
I2A2 LDAP Protocol Converter Addresses
The I2A2 LDAP protcol converter listens on the I2A2 DBM system whose host address is:
dbm.i2a2.purdue.edu
Do not confuse the dbm.i2a2.purdue.edu host name with others that may currently be aliases to it, including
authenticate.i2a2.purdue.edu, authorize.i2a2.purdue.edu, and lookup.i2a2.purdue.edu. None of those aliases should be used
when contacting the I2A2 LDAP protocol converter, because they don't appear in the SSL|TLS certificate that the protocol
converter uses to secure its connections.
Two standard LDAP ports are used:
- Port 389, the plain text LDAP port, sometimes given the service name "ldap";
- Port 636, the SSL|TLS LDAP port, sometimes given the service name "ldaps".
Sometimes picking the correct one of the above ports is difficult. When they want to make SSL|TLS connections, some LDAP clients
prefer to connect to the plain text LDAP port, 389 ("ldap"), and then use an extended LDAP operation to switch the connection from
plain text to SSL|TLS. That is a legitimate way to operate, albeit wasteful of time. The bottom line is that you'll have to
consult the documentation for your LDAP client to determine which port it wants to use.
Using the service names, the URIs for these two ports become:
- ldap://dbm.i2a2.purdue.edu
- ldaps://dbm.i2a2.purdue.edu
Additional addressing components in the form of LDAP Distinguished Names (DNs) are also required. They must be delivered to the I2A2 LDAP protocol converter as part of the LDAP protocol exchange. They identify the I2A2 DBM that is to service the LDAP request and can also identify the PUID of interest. I2A2 LDAP DNs are described below.
SSL|TLS Credentials
When sensitive information must be sent to the I2A2 LDAP protocol converted-- e.g., a password during an LDAP "simple
authentication request" (bind) -- it must be sent via an encrypted channel, using the
SSL|TLS protocol.
The I2A2 LDAP protocol converter operates in SSL|TLS server-side mode and its certificate is signed by the Purdue Certificate
Authority (CA). The Purdue CA certificate is available
here.
Supported LDAP Operations
The I2A2 LDAP protocol converter supports a limited subset of LDAP operations and facilities. Those include:
- Bind -- an authentication operation
- Search -- a lookup operation
- Unbind -- complement to bind
- Filtering -- to support lookup and authorization characteristic requests
The I2A2 LDAP protocol converter supports those operations and facilities by translating them into specific I2A2 DBM operations, based in part on the LDAP Distinguished Names (DNs) supplied by the client, and in part on the particular services offered by individual DBMs.
I2A2 LDAP Attributes
I2A2 LDAP uses standard attributes and defines some specific to I2A2. They are described
here.
Base Distinguished Names (DNs) An important part of the address of an LDAP protocol exchange is the
base Distinguished Name (DN). To the I2A2 LDAP protocol converter the base distinguished name identifies the I2A2 DBM for
which the LDAP request is intended.
The three base DNs, leading to the three I2A2 DBMs are:
- ou=authenticate,dc=purdue,dc=edu -- this DN names the I2A2 authenticator DBM and is normally used for bind requests. It may also be used for search requests, but only via the alias or PUID keys.
- ou=authorize,dc=purdue,dc=edu -- this DN names the I2A2 authorizer DBM and is normally used for search requests that are accompanied by a characteristics filter. This DN may be used for simple search requests, but only via the alias or PUID keys.
- ou=identify,dc=purdue,dc=edu -- this DN names the reflector (identification) I2A2 DBM and is normally used for search requests, including via the alias, PUID, or name keys.
Relative Distinguished Names (RDNs)
The DN may be preceded by a Relative Distinguished Name (RDN) that identifies a particular PUID by its PUID number or alias -- e.g.,
puid=10284869,ou=identify,dc=purdue,dc=edu
uid=abc,ou=authorize,dc=purdue,dc=edu
When the DN begins "ou=identify" the RDN may be a name, identified by the LDAP Common Name (CN) attribute type -- e.g.,
cn=alfred e newman,ou=identify,dc=purdue,dc=edu
DBM Services Available by DN
While each DBM offers specialized services, all DBMs offer some form of lookup service. Here is a table that identifies by DN and DBM what services are offered. In the table, only the first component of the DN is used to identify the DBM.
| DN | DBM | Services offered |
| ou=authenticate | Authenticator |
Bind, using alias or PUID and the coordinated career account (Purdue Realm) password Search by alias or PUID. |
| ou=authorize | Authorizer |
Test a characteristic Boolean expression contained in an LDAP filter. Search by alias or PUID. |
| ou=identify | Reflector | Search by alias, PUID, name, or name regular expression. |
I2A2 LDAP Services and Facilities
The remainder of the discussion of the I2A2 LDAP protocol converter's services and facilities is organized in the following major categories, found at the indicated links:
- Bind -- the LDAP bind request
- Search -- the LDAP search request
- Filters -- using filters with I2A2 LDAP
I2A2 LDAP Sample Programs
Here are some sample programs for making LDAP connections to the I2A2 LDAP protocol converter. They focus on SSL|TLS connections.
-
The OpenLDAP ldapsearch client program provides sample code for making plain text and SSL|TLS connections to an
LDAP server. It understands URIs, filters, base names, DNs, simple password authentication, and a host of other LDAP
options. Ldapsearch can be found in the the clients/tools sub-directory of OpenLDAP distribution, available from the
OpenLDAP Project.
- This i2a2-auth.pl sample Perl LDAP program, written by Ron Kittendorf of Purdue's Office of the Vice President for Information Technology, shows how to authenticate a PUID and password via an LDAP bind.
- This i2a2-ident.pl sample Perl LDAP program, written by Ron Kittendorf of Purdue's Office of the Vice President for Information Technology, shows how to search for an alias, a PUID, or a name via an LDAP search. The Net::LDAP module used by Ron's program can be obtained from the Perl LDAP Homepage. Don't overlook the Net::LDAP module's requirements, described on the Perl LDAP Homepage.