Ttranslation 28.5% Update 2010-02-15 - Revision 20329

Глава 40. Zend_Ldap

Содержание

40.1. Introduction
40.1.1. Theory of operation
40.1.1.1. Automatic Username Canonicalization When Binding
40.1.1.2. Account Name Canonicalization
40.1.1.3. Multi-domain Authentication and Failover
40.2. API overview
40.2.1. Configuration / options
40.2.2. API Reference
40.2.2.1. Zend_Ldap
40.2.2.1.1. Zend_Ldap_Collection
40.2.2.2. Zend_Ldap_Attribute
40.2.2.3. Zend_Ldap_Dn
40.2.2.4. Zend_Ldap_Filter
40.2.2.5. Zend_Ldap_Node
40.2.2.6. Zend_Ldap_Node_RootDse
40.2.2.6.1. OpenLDAP
40.2.2.6.2. ActiveDirectory
40.2.2.6.3. eDirectory
40.2.2.7. Zend_Ldap_Node_Schema
40.2.2.7.1. OpenLDAP
40.2.2.7.2. ActiveDirectory
40.2.2.8. Zend_Ldif_Encoder
40.3. Usage Scenarios
40.3.1. Authentication scenarios
40.3.1.1. OpenLDAP
40.3.1.2. ActiveDirectory
40.3.2. Basic CRUD operations
40.3.2.1. Retrieving data from the LDAP
40.3.2.2. Adding data to the LDAP
40.3.2.3. Deleting from the LDAP
40.3.2.4. Updating the LDAP
40.3.3. Extended operations
40.3.3.1. Copy and move entries in the LDAP
40.4. Tools
40.4.1. Creation and modification of DN strings
40.4.2. Using the filter API to create search filters
40.4.3. Modify LDAP entries using the Attribute API
40.5. Object oriented access to the LDAP tree using Zend_Ldap_Node
40.5.1. Basic CRUD operations
40.5.1.1. Retrieving data from the LDAP
40.5.1.1.1. Getting a node by its DN
40.5.1.1.2. Searching a node's subtree
40.5.1.2. Adding a new node to the LDAP
40.5.1.3. Deleting a node from the LDAP
40.5.1.4. Updating a node on the LDAP
40.5.2. Extended operations
40.5.2.1. Copy and move nodes in the LDAP
40.5.3. Tree traversal
40.6. Getting information from the LDAP server
40.6.1. RootDSE
40.6.2. Schema Browsing
40.6.2.1. OpenLDAP
40.6.2.2. ActiveDirectory
40.7. Serializing LDAP data to and from LDIF
40.7.1. Serialize a LDAP entry to LDIF
40.7.2. Deserialize a LDIF string into a LDAP entry

40.1. Introduction

Zend_Ldap is a class for performing LDAP operations including but not limited to binding, searching and modifying entries in an LDAP directory.

40.1.1. Theory of operation

This component currently consists of the main Zend_Ldap class, that conceptually represents a binding to a single LDAP server and allows for executing operations against a LDAP server such as OpenLDAP or ActiveDirectory (AD) servers. The parameters for binding may be provided explicitly or in the form of an options array. Zend_Ldap_Node provides an object-oriented interface for single LDAP nodes and can be used to form a basis for an active-record-like interface for a LDAP-based domain model.

The component provides several helper classes to perform operations on LDAP entries (Zend_Ldap_Attribute) such as setting and retrieving attributes (date values, passwords, boolean values, ...), to create and modify LDAP filter strings (Zend_Ldap_Filter) and to manipulate LDAP distinguished names (DN) (Zend_Ldap_Dn).

Additionally the component abstracts LDAP schema browsing for OpenLDAP and ActiveDirectoy servers Zend_Ldap_Node_Schema and server information retrieval for OpenLDAP-, ActiveDirectory- and Novell eDirectory servers (Zend_Ldap_Node_RootDse).

Using the Zend_Ldap class depends on the type of LDAP server and is best summarized with some simple examples.

If you are using OpenLDAP, a simple example looks like the following (note that the bindRequiresDn option is important if you are not using AD):

$options = array(
    
'host'              => 's0.foo.net',
    
'username'          => 'CN=user1,DC=foo,DC=net',
    
'password'          => 'pass1',
    
'bindRequiresDn'    => true,
    
'accountDomainName' => 'foo.net',
    
'baseDn'            => 'OU=Sales,DC=foo,DC=net',
);
$ldap = new Zend_Ldap($options);
$acctname $ldap->getCanonicalAccountName('abaker',
                                           
Zend_Ldap::ACCTNAME_FORM_DN);
echo 
"$acctname\n";

If you are using Microsoft AD a simple example is:

$options = array(
    
'host'                   => 'dc1.w.net',
    
'useStartTls'            => true,
    
'username'               => 'user1@w.net',
    
'password'               => 'pass1',
    
'accountDomainName'      => 'w.net',
    
'accountDomainNameShort' => 'W',
    
'baseDn'                 => 'CN=Users,DC=w,DC=net',
);
$ldap = new Zend_Ldap($options);
$acctname $ldap->getCanonicalAccountName('bcarter',
                                           
Zend_Ldap::ACCTNAME_FORM_DN);
echo 
"$acctname\n";

Note that we use the getCanonicalAccountName() method to retrieve the account DN here only because that is what exercises the most of what little code is currently present in this class.

40.1.1.1. Automatic Username Canonicalization When Binding

If bind() is called with a non-DN username but bindRequiresDN is TRUE and no username in DN form was supplied as an option, the bind will fail. However, if a username in DN form is supplied in the options array, Zend_Ldap will first bind with that username, retrieve the account DN for the username supplied to bind() and then re-bind with that DN.

This behavior is critical to Zend_Auth_Adapter_Ldap, which passes the username supplied by the user directly to bind().

The following example illustrates how the non-DN username 'abaker' can be used with bind():

$options = array(
        
'host'              => 's0.foo.net',
        
'username'          => 'CN=user1,DC=foo,DC=net',
        
'password'          => 'pass1',
        
'bindRequiresDn'    => true,
        
'accountDomainName' => 'foo.net',
        
'baseDn'            => 'OU=Sales,DC=foo,DC=net',
);
$ldap = new Zend_Ldap($options);
$ldap->bind('abaker''moonbike55');
$acctname $ldap->getCanonicalAccountName('abaker',
                                           
Zend_Ldap::ACCTNAME_FORM_DN);
echo 
"$acctname\n";

The bind() call in this example sees that the username 'abaker' is not in DN form, finds bindRequiresDn is TRUE, uses 'CN=user1,DC=foo,DC=net' and 'pass1' to bind, retrieves the DN for 'abaker', unbinds and then rebinds with the newly discovered 'CN=Alice Baker,OU=Sales,DC=foo,DC=net'.

40.1.1.2. Account Name Canonicalization

The accountDomainName and accountDomainNameShort options are used for two purposes: (1) they facilitate multi-domain authentication and failover capability, and (2) they are also used to canonicalize usernames. Specifically, names are canonicalized to the form specified by the accountCanonicalForm option. This option may one of the following values:

Таблица 40.1. Options for accountCanonicalForm

Name Value Example
ACCTNAME_FORM_DN 1 CN=Alice Baker,CN=Users,DC=example,DC=com
ACCTNAME_FORM_USERNAME 2 abaker
ACCTNAME_FORM_BACKSLASH 3 EXAMPLE\abaker
ACCTNAME_FORM_PRINCIPAL 4 abaker@example.com

The default canonicalization depends on what account domain name options were supplied. If accountDomainNameShort was supplied, the default accountCanonicalForm value is ACCTNAME_FORM_BACKSLASH. Otherwise, if accountDomainName was supplied, the default is ACCTNAME_FORM_PRINCIPAL.

Account name canonicalization ensures that the string used to identify an account is consistent regardless of what was supplied to bind(). For example, if the user supplies an account name of abaker@example.com or just abaker and the accountCanonicalForm is set to 3, the resulting canonicalized name would be EXAMPLE\abaker.

40.1.1.3. Multi-domain Authentication and Failover

The Zend_Ldap component by itself makes no attempt to authenticate with multiple servers. However, Zend_Ldap is specifically designed to handle this scenario gracefully. The required technique is to simply iterate over an array of arrays of serve options and attempt to bind with each server. As described above bind() will automatically canonicalize each name, so it does not matter if the user passes abaker@foo.net or W\bcarter or cdavis - the bind() method will only succeed if the credentials were successfully used in the bind.

Consider the following example that illustrates the technique required to implement multi-domain authentication and failover:

$acctname 'W\\user2';
$password 'pass2';

$multiOptions = array(
    
'server1' => array(
        
'host'                   => 's0.foo.net',
        
'username'               => 'CN=user1,DC=foo,DC=net',
        
'password'               => 'pass1',
        
'bindRequiresDn'         => true,
        
'accountDomainName'      => 'foo.net',
        
'accountDomainNameShort' => 'FOO',
        
'accountCanonicalForm'   => 4// ACCT_FORM_PRINCIPAL
        
'baseDn'                 => 'OU=Sales,DC=foo,DC=net',
    ),
    
'server2' => array(
        
'host'                   => 'dc1.w.net',
        
'useSsl'                 => true,
        
'username'               => 'user1@w.net',
        
'password'               => 'pass1',
        
'accountDomainName'      => 'w.net',
        
'accountDomainNameShort' => 'W',
        
'accountCanonicalForm'   => 4// ACCT_FORM_PRINCIPAL
        
'baseDn'                 => 'CN=Users,DC=w,DC=net',
    ),
);

$ldap = new Zend_Ldap();

foreach (
$multiOptions as $name => $options) {

    echo 
"Trying to bind using server options for '$name'\n";

    
$ldap->setOptions($options);
    try {
        
$ldap->bind($acctname$password);
        
$acctname $ldap->getCanonicalAccountName($acctname);
        echo 
"SUCCESS: authenticated $acctname\n";
        return;
    } catch (
Zend_Ldap_Exception $zle) {
        echo 
'  ' $zle->getMessage() . "\n";
        if (
$zle->getCode() === Zend_Ldap_Exception::LDAP_X_DOMAIN_MISMATCH) {
            continue;
        }
    }
}

If the bind fails for any reason, the next set of server options is tried.

The getCanonicalAccountName() call gets the canonical account name that the application would presumably use to associate data with such as preferences. The accountCanonicalForm = 4 in all server options ensures that the canonical form is consistent regardless of which server was ultimately used.

The special LDAP_X_DOMAIN_MISMATCH exception occurs when an account name with a domain component was supplied (e.g., abaker@foo.net or FOO\abaker and not just abaker) but the domain component did not match either domain in the currently selected server options. This exception indicates that the server is not an authority for the account. In this case, the bind will not be performed, thereby eliminating unnecessary communication with the server. Note that the continue instruction has no effect in this example, but in practice for error handling and debugging purposes, you will probably want to check for LDAP_X_DOMAIN_MISMATCH as well as LDAP_NO_SUCH_OBJECT and LDAP_INVALID_CREDENTIALS.

The above code is very similar to code used within Zend_Auth_Adapter_Ldap. In fact, we recommend that you simply use that authentication adapter for multi-domain + failover LDAP based authentication (or copy the code).

Comments

Loading...