mod_authz_ldap - reference
  Introduction Download Installation Configuration LDAP HOWTO Reference  

Reference Configuration Directives

Find a short description of the configuration directives in mod_authz_ldap below. For details about the configuration, please refer to the configuration manual.

Syntax: AuthzLDAPMethod { ldap | ldapmapped | certificate | both }
Context: virtual host, directory
Default: none
Defines how the module should authenticate. By default, it does not do anything. If ldap is selected, only basic authentication against the directory is performed. With certificate an X.509 certificate is verified against the LDAP directory. both asks to first verify the certificate in the LDAP directory and then perform basic authentication against the LDAP directory, but the distinguished name for the basic authentication login and for the certificate must match. The ldapmapped is mainly for use with Active Directory, which has got the bind syntax completely wrong. The active directory seems to expect that you bind with our username as the bind DN, not with your DN!
Syntax: AuthzLDAPMapMethod { certificate | issuerserial | issuersubject | ad }
Context: virtual host, directory
Default: none
Defines how the module should map the certificate to an LDAP directory node. The certificate method performs a subtree search from the user base node for a user with a userCertificate attribute that matches the certificate seen on the connection. This requires that the directory allows equality matching for the userCertificate attribute, which is not what the standards say. The issuerserial method uses the map to look for a node based on issuer name and serial number, and uses the owner attribute of such a node to find the user. Analogously, issuersubject uses issuer name and subject name to find the map node.

The ad method was contributed, but I'm currently unable to test it. Here is the original descritpion: Certificates will be searched for in a way that is thought to be similar to that used with Active Directory. First, the subject alternative names of the certificate are parsed and, if one of type othername is found and its associated object identifier is "1.3.6.1.4.1.311.20.2.3" (User Principal Name), its value is used to search for an entry having such value for the userPrincipalName attribute. If no such subject alternative name is found, then the issuer and subject distinguished names of the certificate are combined to form a search filter for the altSecurityIdentities attribute.

Syntax: AuthzLDAPServer host[:port]
Context: virtual host, directory
Default: as set in the LDAP client configuration file, usually something like /etc/ldap.conf
Defines the LDAP server to connect to. If the port is not set, the standard LDAP port 389 is used.
Syntax: AuthzLDAPBindDN dn
Context: virtual host, directory
Default: none
Some servers require an LDAP bind, this directive sets the distinguished name for the bind operation.
Syntax: AuthzLDAPBindPassword pw
Context: virtual host, directory
Default: none
Some servers require an LDAP bind, this directive sets the password name for the bind operation.
Syntax: AuthzLDAPProtocolVersion {1|2|3}
Context: virtual host, directory
Default: none
Set the protocol version to use to connect to the directory. Required with OpenLDAP 2.1.5 libraries.
Syntax: AuthzLDAPUserBase dn
Context: virtual host, directory
Default: none
The user must be searched for in the directory, this directive sets the search base.
Syntax: AuthzLDAPUserKey attributename
Context: virtual host, directory
Default: none
The value of this directive defines the search filter used to search for the user.
Syntax: AuthzLDAPUserScope {base|onlevel|subtree}
Context: virtual host, directory
Default: base
If the namespace for users in the directory is flat, a onlevel search will be the most efficient way to find the user, but some organisations will have hierarchical name spaces. If the namespace ist flat and the user distinguished name can be computed from userid and search base, a base search is also possible. In this case, the userid is constructed as described above.
Syntax: AuthzLDAPGroupBase dn
Context: virtual host, directory
Default: none
Set the base for group membership requirement searches.
Syntax: AuthzLDAPGroupKey attributename
Context: virtual host, directory
Default: none
Set the name of the attribute identifying groups underneath the group search base set by the AuthzLDAPGroupBase directive.
Syntax: AuthzLDAPGroupScope {base|onlevel|subtree}
Context: virtual host, directory
Default: base
Scope to search for matching groups.
Syntax: AuthzLDAPMemberKey attributename
Context: virtual host, directory
Default: member
Set the name of the attribute containing group member distinguished names.
Syntax: AuthzLDAPMapBase dn
Context: virtual host, directory
Default: none
Base for certificate mapping entries.
Syntax: AuthzLDAPMapScope {base|onlevel|subtree}
Context: virtual host, directory
Default: onlevel
Scope for certificate mapping entries.
Syntax: AuthzLDAPSetAuthorization { user | ldapdn | subject | map }{+password}
Context: virtual host, directory
Default: none
This directive gives precise control over the way how the authorization header is overwritten by mod_authz_ldap. By default, the modules leaves the headers alone. This allows the user authenticated by a certificate to use basic authentication unimpeeded. The argument indicates the source from where the user name will be taken: user means the original basic authentication header, ldapdn means the LDAP distinguished name found to be associated with this user, subject means this users certificate subject DN, and map means the value of the mapped attribute when the AuthzLDAPMapUserToAttr is in use. If the string +password is appended, the module takes the password specified in the original basic authentication header, otherwise it uses the constant string password.
Syntax: AuthzLDAPSetGroupAuth { user | ldapdn | map }
Context: virtual host, directory
Default: none
This directive gives control over how the membership checking should be done. With the user value, the user name is used for membership verification. With ldapdn, it is the LDAP distinguished name found upon certificate or user lookup. With map, the user is first mapped according to the settings of AuthzLDAPMapUserToAttr and the result used for membership checking. The following configuration example illustrates this: 
	# map users to the uid uid for membership checking
	AuthzLDAPMapUserToAttr      uid
	AuthzLDAPSetGroupAuth       map
	# this means that the memberUid attribute must match the uid
	# (which is the result of the map operation)
	AuthzLDAPMemberKey          memberUid
	# checks membership in a specific group. a user is accepted
	# precisely if his uid is the value of one of the memberUid
	# attributes of the group specified below
	require group cn=ceres10,ou=intranet,ou=groups,o=company
Syntax: AuthzLDAPMapUserToAttr attributename
Context: virtual host, directory
Default: none
If set, the value (if present) of the indicated attribute in the mapped entry is used to replace the user identity instead of the distinguished name of the mapped entry. This is only supported when either AuthzLDAPDirect or AuthzLDAPMapWithAD are set.
Syntax: AuthzLDAPRoleAttributeName attributename
Context: virtual host, directory
Default: none
Used to specify a attribute name to check for special values as given by require role directives.
Syntax: AuthzLDAPModifyKey attributename
Context: virtual host, directory
Default: none
Then checking a directory entry for last password modification, an attribute containing the time of last modification must be specified.
Syntax: AuthzLDAPAuthoritative {on|off}
Context: virtual host, directory
Default: on
Usually the authentication and authorization decisions of mod_authz_ldap are final. Sometimes however it is desired to have other modules do checks if mod_authz_ldap would deny a request. In these cases, this option must be set to off.
Syntax: AuthzLDAPProxyAuthentication {on|off}
Context: virtual host, directory
Default: automatically determined
In some cases the kind of authentication performed must be explicitly specified to the module. E.g. a reverse proxy will let the module believe that proxy authentication is the thing to do, but to the client the proxy appears as the server, so it should really do normal authentication. Setting this option to off forces normal authentication, on forces proxy authentication.

If a reverse proxy performs basic authentication using this module, and the backend server expects to see the basic authentication header also, you must turn this option off. This causes the module to believe it is doing basic authentication, although it is working as a proxy. If AuthzLDAPSetAuthorization is set so as to set the basic authorization header, mod_proxy will send the Authorization header to the backend system. Note that mod_proxy will never forward the Proxy-Authorization header, as it sees this as a security problem.

Syntax: AuthzLDAPLogLevel {emerg|alert|crit|error|warn|notice|info|debug}
Context: virtual host, directory
Default: debug
Reduce the volume of log messages from this module.
Syntax: AuthzLDAPAllowPassword {on|off}
Context: virtual host, directory
Default: off
If a user does not present a certificate, still accept him if she can prove her identity via userid/password. Note that this weakens security quite a bit, and should probably used only in settings where certificates are a convenience rather than a requirement. For this to work it is necessary to set the mod_ssl configuration directive SSLVerifyClient to optional.
Syntax: AuthzLDAPCacheConnection { on | off }
Context: virtual host, directory
Default: off
Set to on if the module should cache LDAP connections between requests. This may speed up LDAP operations, but also ties up resources inside the apache process and on the LDAP server. You must not set this to on if you are invoking mod_authz_ldap from within an .htaccess file (because every invokation of the module creates a new LDAP connection, which will be cached indefinitely).
 
© Dr. Andreas Müller, Beratung und Entwicklung.