CA certificates are specified within a file called cert7. If client certificates are required, an optional key3. The secmod file can be specified if required. These files are in the same format as used by the Netscape Communicator or Mozilla web browsers. The easiest way to obtain these files is to grab them from your browser installation.
An optional password may be specified to unlock the certificate's private key. Note: Client certificates are specified globally rather than per connection, and so must be specified with the LDAPTrustedGlobalCert directive as below. When any settings are specified per-connection, the global settings are superseded. Specifies the maximum size of the primary LDAP cache.
The default size is cached searches. The default is seconds 10 minutes. Specifies the maximum age, in seconds, that a pooled LDAP connection can remain idle and still be available for use.
Connections are cleaned up when they are next needed, not asynchronously. A setting of 0 causes connections to never be saved in the backend connection pool.
The default value of -1, and any other negative value, allows connections of any age to be reused. Since 2. First, the reference time is not updated if no backend LDAP conncetions were needed. Second, the reference time uses the time the HTTP request was received instead of the time the request is completed. This timeout defaults to units of seconds, but accepts suffixes for milliseconds ms , minutes min , and hours h.
The logged information will likely contain plaintext credentials being used or validated by LDAP authentication, so care should be taken in protecting and purging the error log when this directive is used. The default is entries. Setting it to 0 disables operation caching. Specifies the time in seconds that entries in the operation cache remain valid. The default is seconds. Some LDAP servers divide their directory among multiple domains and use referrals to direct a client when a domain boundary is crossed.
To explain it little more, the name you enter in the browser's authentication dialog, this can be any attribute, for example, givenname, surname, cn etc. To use uid is the best as it is normally a unique attribute for each person.
The authentication will fail if multiple matches are found. You MUST have this directive. There are four forms of this directive, you'll only use one of them and comment out the other three. If you specify valid-user , then any valid user with correct password is allowed.
You can also specify a space separated list of user ids with require user directive to allow those users only. If a id has space in it, put double or single quote around the name. Or with require filter option, a valid LDAP filter can be specified in order to authenticate the use on arbitrary condition.
Or you can only allow users who have certain attribute, for example you might allow all the users whose roomnumber is say or all users with telephonenumber etc. Querying the Global Catalog allows all the domains to be queried in a single query, without the query spanning servers over potentially slow links. If enabled, the Global Catalog is an independent directory server that runs on port for SSL.
To search for a user, do a subtree search for the attribute userPrincipalName , with an empty search root, like so:. Users will need to enter their User Principal Name as a login, in the form somebody nz. Unfortunately, it is not possible to just change to LDAP authentication by adding the proper directives, because it will break the Permissions forms in the FrontPage client, which attempt to modify the standard text-based authorization files.
Once a FrontPage web has been created, adding LDAP authentication to it is a matter of adding the following directives to every. FrontPage restricts access to a web by adding the Require valid-user directive to the.
This means that anybody who has an entry in the LDAP directory is considered a valid user, whereas FrontPage considers only those people in the local user file to be valid. By substituting the ldap-group with group file authorization, Apache is allowed to consult the local user file which is managed by FrontPage - instead of LDAP - when handling authorizing the user.
Once directives have been added as specified above, FrontPage users will be able to perform all management operations from the FrontPage client. This directive allows you to override the prefix used for environment variables set during LDAP authorization. By default, subsequent authentication providers are only queried if a user cannot be mapped to a DN, but not if the user can be mapped to a DN and their password cannot be verified with an LDAP bind.
An optional DN used to bind to the server when searching for entries. A bind password to use in conjunction with the bind DN. Note that the bind password is probably sensitive data, and should be properly protected.
If the value begins with exec: the resulting command will be executed and the first line returned to standard output by the program will be used as the password. File-path is relative to the ServerRoot. This file specifies the list of language extensions to character sets. Most administrators use the provided charset. Language-Extension charset [ Language-String ] The case of the extension does not matter. Blank lines, and lines beginning with a hash character are ignored. The ldap-attribute , ldap-user , and ldap-group single-level only authorization checks use comparisons.
This is the only foolproof way to compare DNs. It is possible to get false negatives with this approach, but it is much faster. The default is always. This directive specifies which LDAP attributes are used to check for user members within groups. Multiple attributes can be used by specifying this directive multiple times. When set on , this directive says to use the distinguished name of the client username when checking for group membership.
Otherwise, the username will be used. By default, the server either anonymously, or with a dedicated user and password, converts the basic authentication username into an LDAP distinguished name DN. This directive forces the server to use the verbatim username and password provided by the incoming user to perform the initial DN search.
The regular expression argument is compared against the current basic authentication username. The substitution argument may contain backreferences, but has no other variable interpolation. When this directive is set to a non-zero value X combined with use of the Require ldap-group someGroupDN directive, the provided user credentials will be searched for as a member of the someGroupDN directory object or of any group member of the current group up to the maximum nesting level X specified by this directive.
See the Require ldap-group section for a more detailed example. This directive is useful should you want people to log into a website using an email address, but a backend application expects the username as a userid. It is turned off by default. An LDAP group object may contain members that are users and members that are groups called nested or sub groups.
Verified sub-groups can then be searched for more user or sub-group members. To specify multiple, redundant LDAP servers, just list all servers, separated by spaces. Once a connection has been made to a server, that connection remains active for the life of the httpd process, or until the LDAP server goes down.
Note that this is different than a true round-robin search. This parameter can be one of the following:. Copyright The Apache Software Foundation.
0コメント