NAME
DBD::LDAP - Provides an SQL/Perl DBI interface to LDAP
AUTHOR
This module is Copyright (C) 2000-2019 by
Jim Turner
Email: turnerjw784 .att. yahoo dot comAll rights reserved.
You may distribute this module under the same terms as Perl itself.
PREREQUISITES
Convert::ANS1 (required by Net::LDAP)
Net::LDAP
DBI
- an LDAP database to connect to.SYNOPSIS
use DBI;
$dbh = DBI->connect("DBI:LDAP:ldapdb",'user','password') #USER LOGIN.
or die "Cannot connect as user: " . $DBI::errstr;
$dbh = DBI->connect("DBI:LDAP:ldapdb") #ANONYMOUS LOGIN (Read-only).
or die "Cannot connect as guest (readonly): " . $DBI::errstr;
$sth = $dbh->prepare("select * from people where (cn like 'Smith%')")
or die "Cannot prepare: " . $dbh->errstr();
$sth->execute() or die "Cannot execute: " . $sth->errstr();
while ((@results) = $sth->fetchrow_array)
{
print "--------------------------------------------------------\n";
++$cnt;
while (@results)
{
print "------>".join('|',split(/\0/, shift(@results)))."\n";
}
}
$sth->finish();
$dbh->disconnect();DESCRIPTION
LDAP stands for the "Lightweight Directory Access Protocol". For more information, see: http://www.ogre.com/ldap/docs.html
DBD::LDAP is a DBI extension module adding an SQL database interface to standard LDAP databases to Perl's database-independent database interface. You will need access to an existing LDAP database or set up your own using an LDAP server, ie. "OpenLDAP", see (http://www.openldap.org).
The main advantage of DBD::LDAP is the ability to query LDAP databases via standard SQL queries in leu of cryptic LDAP "filters". LDAP is optimized for quick lookup of existing data, but DBD::LDAP does support entry inserts, updates, and deletes with commit/rollback via the standard SQL commands!
LDAP databases are "heirarchical" in structure, whereas other DBD-supported databases are "relational" and there is no LDAP-equivalent to SQL "tables", so DBD::LDAP maps a "table" interface over the LDAP "tree" via a configuration file you must set up. Each "table" is mapped to a common "base DN". For example, consider a typical LDAP database of employees within different departments within a company. You might have a "company" names "Acme" and the root "dn" of "dc=Acme, dc=com" (Acme.com). Below the company level, are divisions, ie. "Widgets", and "Blivets". Each division would have an entry with a "dn" of "ou=Widgets, dc=Acme, dc=com", "ou=Blivets, dc=Acme, dc=com", etc. Employees within each division could have a "dn" like "cn=John Doe, ou=Widgets, dc=Acme, dc=com", etc.
With DBD::LDAP, we could create tables to access these different levels, ie. "top", which would have a "DN" of "dc=Acme, dc=com", "WidgetDivision" for "ou=Widgets, dc=Acme, dc=com". "BlivetDivision" for "ou=Blivets, dc=Acme, dc=com", etc. Tables can also be constained by additional attribute specifications (filters), ie constraining by "objectclass", ie. "(objectclass=person)". Then, doing a "select * from WidgetDivision" would display all "person"s with a "dn" containing "ou=Widgets, dc=Acme, dc=com".
INSTALLATION
Installing this module (and the prerequisites from above) is quite simple. You just fetch the archive, extract it with
gzip -cd DBD-LDAP-####.tar.gz | tar xf -
-or-
tar -xzvf DBD-LDAP-####.tar.gz(this is for Unix users, Windows users would prefer WinZip or something similar) and then enter the following:
cd DBD-LDAP-#.###
perl Makefile.PL
make
make testIf any tests fail, let me know. Otherwise go on with
make installNote that you almost definitely need root or administrator permissions. If you don't have them, read the ExtUtils::MakeMaker man page for details on installing in your own directories.
GETTING STARTED:
1) Create a "database", ie. "foo" by creating a text file "foo.ldb". The general format of this file is:
----------------------------------------------------------
hostname[;port][:[root-dn][:[loginrule]]]
tablename1:[basedn]:[basefilter]:dnattrs:[visableattrs]:[insertattrs]:[ldap_options]
tablename2:[basedn]:[basefilter]:dnattrs:[visableattrs]:[insertattrs]:[ldap_options]
...
----------------------------------------------------------
<hostname> represents the ldap server host name.
<port> represents the server's port, default is 389.
<root-dn> if specified, is appended to the end of each tablename's
base-dn.
<loginrule> if specified, converts single word "usernames" to the
appropriate DN, ie:
"cn=*,<ROOT>" would convert user name "foo" to "cn=foo, " and
append the "<root-dn>" onto that. The asterisk is converted to
the user-name specified in the "connect" method. If not specified,
the username specified in the "connect" method must be a full DN.
If the "<root-dn>" is not specified, then the "<loginrule>" would
need to be a full DN.
tablename - represents the name to be used in SQL statements for a given
set of entries which make up a virtual "table".
basedn - if specified, is appended to the "<root-dn>" to make up the
common base DN for all entries in this table. If "<root-dn>" is
not specified, then a full DN must be specified; otherwise, the
default is the root-dn.
basefilter - if specified, specifies a filter to be used if no "where"-
clause is specified in SQL queries. If a "where"-clause is
specified, the resulting filter is "and"-ed with this one. The
default is "(objectclass=*)".
dnattrs - specifies which attributes that values for which are to be
appended to the left of the basedn to create DNs for new entries
being inserted into the table.
visableattrs - if specified, one or more attributes separated by commas
which will be sought when the SQL statement does not specify
attributes, ie. "select * from tablename". If not specified, the
attributes of the first matching entry are returned and used for
all entries matching a given query.
insertattrs - if specified, one or more attribute/value combinations to be
added to any new entry inserted into the table, usually needed for
objectclass values. The attributes and values usually correspond
to those specivied in the "<basefilter>". The general format is:
attr1=value1[|value2...],attr2=value1...,...
These attributes and values will be joined with any user-specified
values for these attributes.
ldap_options - if specified, can be any one or more of the following:
ldap_sizelimit - Limit the number of entries fetch by a query to this
number (0 = no limit) - default: 0.
ldap_timelimit - Limit the search to this number of seconds per query.
(0 = no limit) - default: 0.
ldap_scope - specify the "scope" of the search. Values are: "base",
"one", and "sub", see Net::LDAP docs. Default is "one",
meaning the set of records one level below the basedn. "base"
means search only the basedn, and "sub" means the union
of entries at the "base" level and "one" level below.
ldap_inseparator - specify the separator character/string to be used
in queries to separate multiple values being specified for
a given attribute. Default is "|".
ldap_outseparator - specify the separator character/string to be used
in queryies to separate multiple values displayed as a result
of a query. Default is "|".
ldap_firstonly - only display the 1st value fetched for each attribute
per entry. This makes "ldap_outseparator" unnecessary.2) write your script to use DBI, ie:
#!/usr/bin/perl
use DBI;
$dbh = DBI->connect('DBD:LDAP:foo','me','mypassword') ||
die "Could not connect (".$DBI->err.':'.$DBI->errstr.")!";
...3) get your application working.
INSERTING, FETCHING AND MODIFYING DATA
EXAMPLE: 1st, we'll create a database called "ldapdb" with the tables previously mentioned in the example in the DESCRIPTION section. In our example, "ldapserver" is our LDAP server hostname[:port] or ip-address[:port]. If port is omitted, it defaults to 389. "dc=Acme, dc=com" represents our optional (relative) "root DN" for our "database". "cn=*, <ROOT>" is our optional "login rule", which allows our $dbh->connect() command to specify a simple user-name without having to specify a full DN to log in. In this example, if the "user-name" is "Bob", then the it's converted to "cn=Bob, dc=Acme, dc=com" by replacing "<ROOT> with the "root DN" and replacing any asterisk with the "user-name". If the user-name is a single-pair RDN (relative DN), then the root DN is appended onto that, ie. "cn=Bob" => "cn=Bob, dc=Acme, dc=com". If the user-name is empty, blank, or a full DN, no transformation is done (See example below):
EXAMPLE database file with 3 tables defined (user must create one for each of his/her own databases). NOTE: The "root dn" is the root access level for the database and tables being created, NOT necessarily the "root dn" for the entire LDAP tree itself, as the user (developer) may not want to permit access in a given "database" above a certain level in the LDAP tree:
----------------- file "ldapdb.ldb" ----------------
ldapserver:dc=Acme, dc=com:cn=*,<ROOT>
top:::dc
WidgetDivision:ou=Widgets, :&(objectclass=top)(objectclass=person):cn:cn,sn,ou,title,telephonenumber,description,objectclass,dn:objectclass=top|person|organizationalPerson:ldap_outseparator => ":"
BlivetDivision:ou=Blivets, :&(objectclass=top)(objectclass=person):cn:cn,sn,ou,title,telephonenumber,description,objectclass,dn:objectclass=top|person|organizationalPerson:ldap_outseparator => ":"
----------------------------------------------------Now, to connect to the newly created example database above, one would use:
my $dbh = DBI->connect('DBD:LDAP:ldapdb','Bob','Bobs_password') ||
die "Could not connect (".$DBI->err.':'.$DBI->errstr.")!";
In this case "Bob" would be converted to "cn=Bob, dc=Acme, dc=com". It could've also been
specified as "cn=Bob" or the full "cn=Bob, dc=Acme, dc=com", based on the first line of the
database (.ldb) file we created above. A different full DN could also have been specified. NOTE: If
your login user-names are not defined in your database's common root-dn, it may be necessary to specify
a relative DN to log in, ie. "cn=Bob, ou=Widgets" or a full DN. If you need or wish to mandate a full
DN to log in and connect, simply omit the login-rule (3rd argument of line 1 in your database file)
which in this case is the "cn=*,<ROOT>" part.The following examples insert some data in a table and fetch it back: First all data in the string:
$dbh->do(q{
INSERT INTO top (ou, cn, objectclass)
VALUES ('Widgets', 'WidgetDivision', 'top|organizationalUnit')
};Next an example using parameters:
$dbh->do("INSERT INTO WidgetDivision (cn,sn,title,telephonenumber) VALUES (?, ?, ?, ?)",
'John Doe','DoeJ','Manager','123-1111');
$dbh->commit;NOTE: Unlike most other DBD modules which support transactions, changes made do NOT show up until the "commit" function is called, unless "AutoCommit" is set. This is due to the fact that fetches are done from the LDAP server and changes do not take effect there until the Net::LDAP "update" function is called, which is called by "commit".
NOTE: The "dn" field is generated automatically from the base "dn" and the dn component fields specified by "dnattrs", If you try to insert a value directly into it, it will be ignored. Also, if not specified, any attribute/value combinations specified in the "insertattrs" option will be added automatically.
To retrieve data, you can use the following:
my($query) = "SELECT * FROM WidgetDivision WHERE cn like 'John%' ORDER BY cn";
my($sth) = $dbh->prepare($query);
$sth->execute();
while (my $entry = $sth->fetchrow_hashref) {
print("Found result record: cn = ", $entry->{'cn'},
", phone = ", $row->{'telephonenumber'});
}
$sth->finish();The SQL "SELECT" statement above (combined with the table information in the "ldapdb.ldb" database file would generate and execute the following equivalent LDAP Search:
base => 'ou=Widgets, dc=Acme, dc=com',
filter => '(&(&(objectclass=top)(objectclass=person))(cn=John*))',
scope => 'one',
attrs => 'cn,sn,ou,title,telephonenumber,description,objectclass,dn'See the DBI manpage for details on these methods. See the Data rows are modified with the UPDATE statement:
$dbh->do("UPDATE WidgetDivision SET description = 'Outstanding Employee' WHERE cn = 'John Doe'");NOTE: You can NOT change the "dn" field directly - direct changes will be ignored. You change the "rdn" component of the "dn" field by changing the value of the other field(s) which are appended to the base "dn". Also, if not specified, any attribute/value combinations specified in the "insertattrs" option will be added automatically.
Likewise you use the DELETE statement for removing entries:
$dbh->do("DELETE FROM WidgetDivision WHERE description = 'Outstanding Employee'");METADATA
The following attributes are handled by DBI itself and not by DBD::LDAP, thus they should all work as expected.
PrintError
RaiseError
WarnThe following DBI attributes are handled by DBD::LDAP:
AutoCommit
Works
NUM_OF_FIELDS
Valid after '$sth->execute'
NUM_OF_PARAMS
Valid after '$sth->prepare'
NAME
Valid after '$sth->execute'; undef for Non-Select statements.
NULLABLE
Not really working. Always returns an array ref of one's, as
DBD::LDAP always allows NULL (handled as an empty string).
Valid after `$sth->execute'.
LongReadLen
Should work
LongTruncOk
Should workThese attributes and methods are not supported:
bind_param_inout
CursorNameIn addition to the DBI attributes, you can use the following dbh attributes. These attributes are read-only after "connect".
ldap_dbuser
Current database user.
ldap_HOME
Environment variable specifying a path to search for LDAP
databases (*.ldb) files.DRIVER PRIVATE METHODS
DBI->data_sources()
The `data_sources' method returns a list of "databases" (.ldb files)
found in the current directory and, if specified, the path in
the ldap_HOME environment variable.
$dbh->tables()
This method returns a list of table names specified in the current
database.
Example:
my($dbh) = DBI->connect("DBI:LDAP:mydatabase",'me','mypswd');
my(@list) = $dbh->func('tables');OTHER SUPPORTING UTILITIES
RESTRICTIONS
DBD::LDAP currently treats all data as strings and all fields as VARCHAR(255) (type 12), though data is not limited nor truncated to that arbitrary length, but rather just returned as that by DBI's *info() functions.
Currently, you must define tables manually in the "<database>.ldb" file using your favorite text editor.
TODO
"Create Table", "Alter Table", and "Drop Table" SQL functions for creating, altering, and deleting the tables defined in the "<database>.ldb" file.
Some kind of datatype support, ie. numeric (for sorting), CHAR for padding, Long/Blob - for >255 chars per field, etc.
KNOWN BUGS
none - (yet).