978 lines
37 KiB
HTML
978 lines
37 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<title>ProFTPD module mod_ldap</title>
|
|
</head>
|
|
|
|
<body bgcolor=white>
|
|
|
|
<hr><br>
|
|
<center>
|
|
<h2><b>ProFTPD module <code>mod_ldap</code></b></h2>
|
|
</center>
|
|
<hr><br>
|
|
|
|
<p>
|
|
This module is contained in the <code>mod_ldap.c</code> file for ProFTPD 1.2.<i>x</i>/1.3.<i>x</i>, and is not compiled by default. Installation instructions
|
|
are discussed <a href="#Installation">here</a>.
|
|
|
|
<p>
|
|
The most current version of <code>mod_ldap</code> is distributed with the
|
|
ProFTPD source code.
|
|
|
|
<h2>Author</h2>
|
|
<p>
|
|
Please contact John Morrissey <jwm <i>at</i> horde.net> with any
|
|
questions, concerns, or suggestions regarding this module.
|
|
|
|
<h2>Directives</h2>
|
|
<ul>
|
|
<li><a href="#LDAPAliasDereference">LDAPAliasDereference</a>
|
|
<li><a href="#LDAPAttr">LDAPAttr</a>
|
|
<li><a href="#LDAPAuthBinds">LDAPAuthBinds</a>
|
|
<li><a href="#LDAPBindDN">LDAPBindDN</a>
|
|
<li><a href="#LDAPConnectTimeout">LDAPConnectTimeout</a>
|
|
<li><a href="#LDAPDefaultAuthScheme">LDAPDefaultAuthScheme</a>
|
|
<li><a href="#LDAPDefaultGID">LDAPDefaultGID</a>
|
|
<li><a href="#LDAPDefaultQuota">LDAPDefaultQuota</a>
|
|
<li><a href="#LDAPDefaultUID">LDAPDefaultUID</a>
|
|
<li><a href="#LDAPForceDefaultGID">LDAPForceDefaultGID</a>
|
|
<li><a href="#LDAPForceDefaultUID">LDAPForceDefaultUID</a>
|
|
<li><a href="#LDAPForceGeneratedHomedir">LDAPForceGeneratedHomedir</a>
|
|
<li><a href="#LDAPGenerateHomedir">LDAPGenerateHomedir</a>
|
|
<li><a href="#LDAPGenerateHomedirPrefix">LDAPGenerateHomedirPrefix</a>
|
|
<li><a href="#LDAPGenerateHomedirPrefixNoUsername">LDAPGenerateHomedirPrefixNoUsername</a>
|
|
<li><a href="#LDAPGroups">LDAPGroups</a>
|
|
<li><a href="#LDAPLog">LDAPLog</a>
|
|
<li><a href="#LDAPProtocolVersion">LDAPProtocolVersion</a>
|
|
<li><a href="#LDAPQueryTimeout">LDAPQueryTimeout</a>
|
|
<li><a href="#LDAPSearchScope">LDAPSearchScope</a>
|
|
<li><a href="#LDAPServer">LDAPServer</a>
|
|
<li><a href="#LDAPUsers">LDAPUsers</a>
|
|
<li><a href="#LDAPUseSASL">LDAPUseSASL</a>
|
|
<li><a href="#LDAPUseTLS">LDAPUseTLS</a>
|
|
</ul>
|
|
|
|
<hr>
|
|
<h3><a name="LDAPAliasDereference">LDAPAliasDereference</a></h3>
|
|
<strong>Syntax:</strong> LDAPAliasDereference <em>never|always|search|find</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPAliasDereference</code> directive configures how aliases are
|
|
handled. The possible values have the following behaviors:
|
|
<ul>
|
|
<li><em>never</em>
|
|
<p>
|
|
Never dereference aliases
|
|
</li>
|
|
|
|
<p>
|
|
<li><em>always</em>
|
|
<p>
|
|
Always dereference aliases
|
|
</li>
|
|
|
|
<p>
|
|
<li><em>search</em>
|
|
<p>
|
|
Dereference aliases only when searching
|
|
</li>
|
|
|
|
<p>
|
|
<li><em>find</em>
|
|
<p>
|
|
Dereference aliases only when locating the base object for the search
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
The default is "never", <i>e.g.</i>:
|
|
<pre>
|
|
<IfModule mod_ldap.c>
|
|
LDAPAliasDeference never
|
|
</IfModule>
|
|
</pre>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPAttr">LDAPAttr</a></h3>
|
|
<strong>Syntax:</strong> LDAPAttr <em>old-attr-name new-attr-name</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPAttr</code> directive is used to map, or to associate, a standard
|
|
attribute name to a non-standard attribute name. If, for example, your
|
|
LDAP directory schema used different names for some of the attributes used
|
|
by <code>mod_ldap</code>, you would use this directive to tell
|
|
<code>mod_ldap</code> what new attribute names to use.
|
|
|
|
<p>
|
|
The following LDAP attributes can be renamed in this manner:
|
|
<ul>
|
|
<li><code>uid</code>
|
|
<li><code>uidNumber</code>
|
|
<li><code>gidNumber</code>
|
|
<li><code>homeDirectory</code>
|
|
<li><code>userPassword</code>
|
|
<li><code>loginShell</code>
|
|
<li><code>cn</code>
|
|
<li><code>memberUid</code>
|
|
<li><code>ftpQuota</code>
|
|
</ul>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPAuthBinds">LDAPAuthBinds</a></h3>
|
|
<strong>Syntax:</strong> LDAPAuthBinds <em>on|off</em><br>
|
|
<strong>Default:</strong> LDAPAuthBinds on<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
By default, the DN specified by the
|
|
<a href="#LDAPBindDN"><code>LDAPBindDN</code></a> will be used to bind to the
|
|
LDAP server to obtain user information, including the <code>userPassword</code>
|
|
attribute. If <code>LDAPAuthBinds</code> is set to <em>on</em>, the DN
|
|
specified by <code>LDAPDNInfo</code> will be used to fetch all user information
|
|
<i>except</i> the <code>userPassword</code> attribute. Then, the
|
|
<code>mod_ldap</code> module will bind to the LDAP server as the user who is
|
|
logging in via FTP with the user-supplied password. If this bind succeeds,
|
|
the user is considered authenticated and is allowed to log in. This method of
|
|
LDAP authentication has the added benefit of supporting any password encryption
|
|
scheme that your LDAP server supports.
|
|
|
|
<p>
|
|
In versions of <code>mod_ldap</code> up to 2.7.6, the default for
|
|
<code>LDAPAuthBinds</code> was <em>off</em>. After <code>mod_ldap</code> 2.8,
|
|
the default value for <code>LDAPAuthBinds</code> is <em>on</em>.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPBindDN">LDAPBindDN</a></h3>
|
|
<strong>Syntax:</strong> LDAPBindDN <em>dn password</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.3.5rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPBindDN</code> directive configures the <em>DN</em> and the
|
|
<em>password</em> that <code>mod_ldap</code> will use when binding to the LDAP
|
|
directory. If this configuration directive is missing, then anonymous binds
|
|
are used.
|
|
|
|
<p>
|
|
The default is:
|
|
<pre>
|
|
<IfModule mod_ldap.c>
|
|
# Use anonymous binds
|
|
LDAPBindDN "" ""
|
|
</IfModule>
|
|
</pre>
|
|
|
|
<p>
|
|
See also: <a href="#LDAPServer"><code>LDAPServer</code></a>, <a href="#LDAPUseSASL"><code>LDAPUseSASL</code></a>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPConnectTimeout">LDAPConnectTimeout</a></h3>
|
|
<strong>Syntax:</strong> LDAPConnectTimeout <em>secs</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.3.8rc3 and later
|
|
|
|
<p>
|
|
The <code>LDAPConnectTimeout</code> directive configures the timeout value,
|
|
in seconds, that will be used when connecting to LDAP servers. The default
|
|
timeout value is determined by your LDAP API.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPDefaultAuthScheme">LDAPDefaultAuthScheme</a></h3>
|
|
<strong>Syntax:</strong> LDAPDefaultAuthScheme <em>"crypt"|"clear"</em><br>
|
|
<strong>Default:</strong> crypt<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPDefaultAuthScheme</code> directive specifies the authentication
|
|
scheme used for passwords which have no "{hashname}" prefix in the LDAP
|
|
directory. For example, if you have:
|
|
<pre>
|
|
userPassword <em>mypass</em>
|
|
</pre>
|
|
in your directory, you would want to set <code>LDAPDefaultAuthScheme</code>
|
|
to <em>"clear"</em>, <i>e.g.</i>:
|
|
<pre>
|
|
LDAPDefaultAuthScheme clear
|
|
</pre>
|
|
|
|
<p>
|
|
The default value is <em>"crypt"</em>.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPDefaultGID">LDAPDefaultGID</a></h3>
|
|
<strong>Syntax:</strong> LDAPDefaultGID <em>gid</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPDefaultGID</code> directive sets the default GID to be used
|
|
for users when no <code>gidNumber</code> attribute is found for that user.
|
|
If the <em>gid</em> parameter is "Auto", then the system
|
|
<code>getpwnam(3)</code> function will be used to "automatically" determine
|
|
the GID value for this user. This "automatic" functionality is useful for
|
|
<i>e.g.</i> Microsoft AD domains in combination with <code>sssd</code>.
|
|
|
|
<p>
|
|
This directive is useful primarily in virtual user environments common in
|
|
large-scale ISPs and hosting organizations. If a user does not have an LDAP
|
|
<code>gidNumber</code> attribute, the <code>LDAPDefaultGID</code> is used.
|
|
This allows one to have a large number of users in an LDAP directory without
|
|
<code>gidNumber</code> attributes; setting this configuration directive will
|
|
automatically assign those users a single GID.
|
|
|
|
<p>
|
|
See also: <a href="#LDAPDefaultUID"><code>LDAPDefaultUID</code></a>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPDefaultQuota">LDAPDefaultQuota</a></h3>
|
|
<strong>Syntax:</strong> LDAPDefaultQuota <em>default-quota</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.3.5rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPDefaultQuota</code> directive configures a <em>default-quota</em>
|
|
to use if a user does not have an <code>ftpQuota</code> attribute. This
|
|
parameter is formatted the same way as the <code>ftpQuota</code> LDAP attribute.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPDefaultUID">LDAPDefaultUID</a></h3>
|
|
<strong>Syntax:</strong> LDAPDefaultUID <em>uid</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPDefaultUID</code> directive sets the default UID to be used
|
|
for users when no <code>uidNumber</code> attribute is found for that user.
|
|
If the <em>uid</em> parameter is "Auto", then the system
|
|
<code>getpwnam(3)</code> function will be used to "automatically" determine
|
|
the UID value for this user. This "automatic" functionality is useful for
|
|
<i>e.g.</i> Microsoft AD domains in combination with <code>sssd</code>.
|
|
|
|
<p>
|
|
This directive is useful primarily in virtual user environments common in
|
|
large-scale ISPs and hosting organizations. If a user does not have an LDAP
|
|
<code>uidNumber</code> attribute, the <code>LDAPDefaultGID</code> is used.
|
|
This allows one to have a large number of users in an LDAP directory without
|
|
<code>uidNumber</code> attributes; setting this configuration directive will
|
|
automatically assign those users a single UID.
|
|
|
|
<p>
|
|
By default, the search filter template used is:
|
|
<pre>
|
|
(&(uid=%v)(objectclass=posixAccount))
|
|
</pre>
|
|
The <em>uid</em> for the the search filter is taken from the
|
|
<code>LDAPAttr</code> directive. Search filter templates are only supported
|
|
in versions of <code>mod_ldap</code> 2.7 and later.
|
|
|
|
<p>
|
|
See also: <a href="#LDAPAttr"><code>LDAPAttr</code></a>, <a href="#LDAPDefaultGID"><code>LDAPDefaultGID</code></a>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPForceDefaultGID">LDAPForceDefaultGID</a></h3>
|
|
<strong>Syntax:</strong> LDAPForceDefaultGID <em>on|off</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
Even when a <a href="#LDAPDefaultGID"><code>LDAPDefaultGID</code></a> is
|
|
configured, the <code>mod_ldap</code> module will allow individual users to
|
|
have <code>gidNumber</code> attributes that will override this default GID.
|
|
With <code>LDAPForceDefaultGID</code> directive configured to be <em>on</em>,
|
|
all LDAP-authenticated users are given the default GID; GIDs may not be
|
|
overridden by <code>gidNumber</code> attributes.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPForceDefaultUID">LDAPForceDefaultUID</a></h3>
|
|
<strong>Syntax:</strong> LDAPForceDefaultUID <em>on|off</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config<br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
Even when a <a href="#LDAPDefaultUID"><code>LDAPDefaultUID</code></a> is
|
|
configured, the <code>mod_ldap</code> module will allow individual users to
|
|
have <code>uidNumber</code> attributes that will override this default UID.
|
|
With <code>LDAPForceDefaultUID</code> directive configured to be <em>on</em>,
|
|
all LDAP-authenticated users are given the default UID; UIDs may not be
|
|
overridden by <code>uidNumber</code> attributes.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPForceGeneratedHomedir">LDAPForceGeneratedHomedir</a></h3>
|
|
<strong>Syntax:</strong> LDAPForceGeneratedHomedir <em>off|on</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code
|
|
><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
When no <code>homeDirectory</code> attribute is found, the <code>mod_ldap</code>
|
|
module can be configured to <em>generate</em> a home directory using the
|
|
<a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a> directive.
|
|
If there <i>is</i> a <code>homeDirectory</code> attribute present, however,
|
|
the <code>mod_ldap</code> module will use that attribute value as the home
|
|
directory.
|
|
|
|
<p>
|
|
However, there may be cases where the administrator wishes to <em>override</em>
|
|
the <code>homeDirectory</code> attribute, and thus to <i>always</i> use the
|
|
home directory value that <code>mod_ldap</code> would generate. The
|
|
<code>LDAPForceGeneratedHomedir</code> directive is used in such cases.
|
|
|
|
<p>
|
|
For example, assume that the user logging in is named "tj", and has an
|
|
LDAP object whose <code>homeDirectory</code> attribute value is "/home/tj".
|
|
To <em>force</em> the use of <code>mod_ldap</code>'s generated home directory
|
|
instead of that <code>homeDirectory</code> value, the configuration might
|
|
look like:
|
|
<pre>
|
|
LDAPForceGeneratedHomedir on
|
|
LDAPGenerateHomedir on
|
|
LDAPGenerateHomedirPrefix /var/ftp
|
|
</pre>
|
|
Using the above configuration, the home directory that the
|
|
<code>mod_ldap</code> module would use is <code>/var/ftp/tj</code>, despite
|
|
what <code>homeDirectory</code> attribute may be in the LDAP directory.
|
|
|
|
<p>
|
|
<b>Note</b> that if <code>LDAPForceGeneratedHomedir</code> is enabled, then
|
|
<code>LDAPGenerateHomedir</code> must <b>also</b> be enabled. It is an error
|
|
to enable <code>LDAPForceGeneratedHomedir</code> without also enabling
|
|
<code>LDAPGenerateHomdir</code>.
|
|
|
|
<p>
|
|
See also: <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a>, <a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a>, <a href="#LDAPGenerateHomedirPrefixNoUsername"><code>LDAPGenerateHomedirPrefixNoUsername</code></a>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPGenerateHomedir">LDAPGenerateHomedir</a></h3>
|
|
<strong>Syntax:</strong> LDAPGenerateHomedir <em>on|off</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
By default, the <code>mod_ldap</code> module uses the <code>homeDirectory</code>
|
|
attribute to determine what home directory to use for the session. Sometimes,
|
|
however, an administrator will want to use a <i>different</i> home directory
|
|
for these FTP/SFTP sessions, something other than the path in the
|
|
<code>homeDirectory</code> attribute. The <code>LDAPGenerateHomedir</code>
|
|
directive is used for situations like this.
|
|
|
|
<p>
|
|
The <code>LDAPGenerateHomedir</code> directive configures the
|
|
<code>mod_ldap</code> module to "generate" a new home directory value,
|
|
<em>overriding</em> the value from the <code>homeDirectory</code> attribute.
|
|
The generated home directory value <b>requires</b> that a starting point
|
|
for the new home directory, a "prefix", also be provided using the
|
|
<a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a>
|
|
directive.
|
|
|
|
<p>
|
|
The <code>LDAPGenerateHomedir</code> directives does <b>not</b> cause the
|
|
new home directory to be <em>created on the filesystem</em>. It only changes
|
|
the home directory value that the <code>mod_ldap</code> module provides to
|
|
the ProFTPD engine. The <i>creation</i> of the home directory, if it does
|
|
not already exist, is done using the
|
|
<a href="../howto/CreateHome.html"><code>CreateHome</code></a> directive.
|
|
|
|
<p>
|
|
See also: <a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a>, <a href="#LDAPGenerateHomedirPrefixNoUsername"><code>LDAPGenerateHomedirPrefixNoUsername</code></a>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPGenerateHomedirPrefix">LDAPGenerateHomedirPrefix</a></h3>
|
|
<strong>Syntax:</strong> LDAPGenerateHomedirPrefix <em>prefix</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPGenerateHomedirPrefix</code> directive is used when
|
|
<code>LDAPGenerateHomedir</code> is enabled, causing the <code>mod_ldap</code>
|
|
module to <em>generate</em> a <b>default</b> home directory, when the
|
|
<code>homeDirectory</code> attribute value is not present. The generated home
|
|
directory value like this:
|
|
<pre>
|
|
<i>prefix</i>/<i>username</i>
|
|
</pre>
|
|
The configured <em>prefix</em> string has the username (from the
|
|
<code>uid</code> attribute) appended to generate the home directory value for
|
|
the user.
|
|
|
|
<p>
|
|
For example:
|
|
<pre>
|
|
LDAPGenerateHomedir on
|
|
LDAPGenerateHomedirPrefix /var/ftp
|
|
</pre>
|
|
Using the above configuration, and assuming a user name of "tj", the home
|
|
directory that the <code>mod_ldap</code> module would use is
|
|
<code>/var/ftp/tj</code>, no matter what the <code>homeDirectory</code>
|
|
attribute may be in the LDAP directory.
|
|
|
|
<p>
|
|
See also: <a href="#LDAPForceGeneratedHomedir"><code>LDAPForceGeneratedHomedir</code></a>, <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a>, <a href="#LDAPGenerateHomedirPrefixNoUsername"><code>LDAPGenerateHomedirPrefixNoUsername</code></a>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPGenerateHomedirPrefixNoUsername">LDAPGenerateHomedirPrefixNoUsername</a></h3>
|
|
<strong>Syntax:</strong> LDAPGenerateHomedirPrefixNoUsername <em>on|off</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
When the <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a>
|
|
and <a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a> directives are used, the <em>generated</em> home directory value for
|
|
the session is:
|
|
<pre>
|
|
<i>prefix</i>/<i>username</i>
|
|
</pre>
|
|
However, there may be cases where the administrator does <b>not</b> want
|
|
the username automatically appended to the generated value, and instead wishes
|
|
to use <i>just</i> the prefix as the home directory. For these use cases,
|
|
use the <code>LDAPGenerateHomedirPrefixNoUsername</code> directive.
|
|
|
|
<p>
|
|
For example:
|
|
<pre>
|
|
LDAPGenerateHomedir on
|
|
LDAPGenerateHomedirPrefix /var/ftp
|
|
LDAPGenerateHomedirPrefixNoUsername on
|
|
</pre>
|
|
Using the above configuration, and assuming a user name of "tj", the home
|
|
directory that the <code>mod_ldap</code> module would use is
|
|
<code>/var/ftp</code>, no matter what the <code>homeDirectory</code> attribute
|
|
may be in the LDAP directory.
|
|
|
|
<p>
|
|
See also: <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a>, <a href="#LDAPGenerateHomedirPrefix"><code>LDAPGenerateHomedirPrefix</code></a>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPGroups">LDAPGroups</a></h3>
|
|
<strong>Syntax:</strong> LDAPGroups <em>base-dn cn-filter-template gid-number-filter-template member-uid-filter-template</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.3.5rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPGroups</code> directive activates LDAP GID-to-name lookups for
|
|
directory listings. The first parameter to this directive is the LDAP
|
|
<em>base DN</em> to use for GID-to-name lookups. The second through fourth
|
|
optional parameters are templates to be used for the search filter;
|
|
<code>%v</code> will be replaced with the GID that is being looked up.
|
|
|
|
<p>
|
|
By default, the CN filter template look like this:
|
|
<pre>
|
|
(&(LDAPAttr_cn=%v)(objectclass=posixGroup))
|
|
</pre>
|
|
The <code>gidNumber</code> filter template is:
|
|
<pre>
|
|
(&(LDAPAttr_gidNumber=%v)(objectclass=posixGroup))
|
|
</pre>
|
|
and the <code>memberUid</code> filter template used is:
|
|
<pre>
|
|
(&(LDAPAttr_memberUid=%v)(objectclass=posixGroup))
|
|
</pre>
|
|
Note that filter templates are only supported in <code>mod_ldap</code>
|
|
version 2.8.3 and later.
|
|
|
|
<p>
|
|
The attribute names used in the default search filters are taken from the
|
|
<a href="#LDAPAttr"><code>LDAPAttr</code></a> directive.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPLog">LDAPLog</a></h3>
|
|
<strong>Syntax:</strong> LDAPLog <em>file|"none"</em><br>
|
|
<strong>Default:</strong> <em>None</em><br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.3.5rc4 and later
|
|
|
|
<p>
|
|
The <code>LDAPLog</code> directive is used to specify a log file for
|
|
<code>mod_ldap</code>'s reporting on a per-server basis. The <em>file</em>
|
|
parameter given must be the full path to the file to use for logging.
|
|
|
|
<p>
|
|
Note that this path must <b>not</b> be to a world-writable directory and,
|
|
unless <code>AllowLogSymlinks</code> is explicitly set to <em>on</em>
|
|
(generally a bad idea), the path must <b>not</b> be a symbolic link.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPProtocolVersion">LDAPProtocolVersion</a></h3>
|
|
<strong>Syntax:</strong> LDAPProtocolVersion <em>2|3</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPProtocolVersion</code> directive configures the version of
|
|
the LDAP protocol that <code>mod_ldap</code> will use when talking to the
|
|
LDAP servers. The default protocol version used is <em>3</em>.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPQueryTimeout">LDAPQueryTimeout</a></h3>
|
|
<strong>Syntax:</strong> LDAPQueryTimeout <em>secs</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPQueryTimeout</code> directive configures the timeout value,
|
|
in seconds, that will be used for LDAP directory queries. The default timeout
|
|
value is determined by your LDAP API.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPSearchScope">LDAPSearchScope</a></h3>
|
|
<strong>Syntax:</strong> LDAPSearchScope <em>base|onelevel|subtree</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPSearchScope</code> directive is used to set the scope used for
|
|
LDAP searches. The default setting, <em>subtree</em>, searches for all entries
|
|
in the tree from the current level down. Setting this directive to
|
|
<em>onelevel</em> searches only one level deep in the LDAP tree.
|
|
|
|
<p>
|
|
<b>Note</b> that the <code>LDAPSearchScope</code> directive <b>cannot</b> be
|
|
used when the LDAP URL syntax, rather than hostname/port, is used for your
|
|
<a href="#LDAPServer"><code>LDAPServer</code></a> configuration. Why not?
|
|
The search scope can be specified as part of the URL itself. This, combined
|
|
with the fact that the <code>LDAPServer</code> directive can take
|
|
<i>multiple</i> hosts/URLs, makes it clear to include the search scope in the
|
|
URLs as needed.
|
|
|
|
<p>
|
|
If you are <b>not</b> using the LDAP URL syntax, then the following will
|
|
use the <em>subtree</em> search scope:
|
|
<pre>
|
|
LDAPServer ldap.example.com
|
|
</pre>
|
|
or, to make it explicit in your configuration:
|
|
<pre>
|
|
LDAPServer ldap.example.com
|
|
LDAPSearchScope subtree
|
|
</pre>
|
|
On the other hand, if you <b>are</b> using LDAP URLs, then you specify the
|
|
search scope as part of the URL:
|
|
<pre>
|
|
LDAPServer ldap://ldap.example.com/??sub
|
|
</pre>
|
|
It is <b>important</b> that the "/" after the hostname/port be part of your
|
|
LDAP URL when specifying the search scope. That is, using:
|
|
<pre>
|
|
LDAPServer ldap://ldap.example.com??sub
|
|
</pre>
|
|
<b>will not work as expected</b>; see
|
|
<a href="https://tools.ietf.org/html/rfc2255">RFC 2255</a>, Section 3. LDAP
|
|
URL parameters are <b>not</b> like HTTP URL query parameters; LDAP URL
|
|
parameters <b>are</b> order-specific. And the "/" before any of the
|
|
optional parameters <b>is required</b>.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPServer">LDAPServer</a></h3>
|
|
<strong>Syntax:</strong> LDAPServer <em>url1|host1:port1 url2|host2:port2 [ssl-ca:<path>] [ssl-cert:<path>] [ssl-key:<path>] [ssl-ciphers:<list>] [ssl-verify:boolean]</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPServer</code> directive allows you to to specify the hostname(s)
|
|
and port(s) of the LDAP server(s) to use for LDAP authentication. If no
|
|
<code>LDAPServer</code> configuration directive is present, the default LDAP
|
|
servers specified by your LDAP library will be used. Note that the LDAP
|
|
URL syntax may also be used.
|
|
|
|
<p>
|
|
To specify multiple LDAP servers, you can configure the entire list of servers
|
|
on one line:
|
|
<pre>
|
|
# Using just hostname/port
|
|
LDAPServer host1:port1 host2:port2
|
|
</pre>
|
|
or:
|
|
<pre>
|
|
# Using the URL syntax
|
|
LDAPServer url1 url2
|
|
</pre>
|
|
In ProFTPD 1.3.7rc4 and later, you can also use multiple <code>LDAPServer</code>
|
|
directives as well, <i>e.g.</i>:
|
|
<pre>
|
|
LDAPServer host1:port1
|
|
LDAPServer url1
|
|
LDAPServer host2
|
|
LDAPServer url2
|
|
</pre>
|
|
|
|
<p>
|
|
The default search scope for LDAP URLs is "base" (unless a scope is explicitly
|
|
provided in the URL). This behavior differs from the
|
|
<a href="#LDAPSearchScope"><code>LDAPSearchScope</code></a> directive, which
|
|
defaults to "subtree".
|
|
|
|
<p>
|
|
<b>Note</b> that to use LDAPS (LDAP over SSL), you <b>must</b> use the
|
|
<em>URL</em> format, <i>e.g.</i>:
|
|
<pre>
|
|
LDAPServer ldaps://host1:port1 ldaps://host2:port2
|
|
</pre>
|
|
|
|
<p>
|
|
However, LDAPS is deprecated. Instead, LDAP prefers the
|
|
<a href="https://en.wikipedia.org/wiki/STARTTLS">STARTTLS</a> mechanism. To
|
|
enable use of STARTTLS for your LDAP connections, use the
|
|
<a href="#LDAPUseTLS"><code>LDAPUseTLS</code></a> directive, <i>e.g.</i>:
|
|
<pre>
|
|
LDAPServer ldap://host1:port1 ldap://host2:port2
|
|
LDAPUseTLS on
|
|
</pre>
|
|
|
|
<p>
|
|
In ProFTPD 1.3.7rc4 and later, it is possible to configure SSL/TLS parameters
|
|
for a given connection. Most of the time, all that is needed for the SSL
|
|
session is the CA (Certificate Authority) to use, for verifying the
|
|
certificate presented by the LDAP server, using the <em>ssl-ca:</em> parameter.
|
|
Thus:
|
|
<pre>
|
|
LDAPServer ... ssl-ca:/path/to/cacert.pem
|
|
</pre>
|
|
If your LDAP server is configured to require SSL/TLS mutual authentication
|
|
(also called "client auth"), you may need the <em>ssl-cert:</em> and
|
|
<em>ssl-key:</em> parameters as well:
|
|
<pre>
|
|
LDAPServer ... ssl-ca:/path/to/cacert.pem \
|
|
ssl-cert:/path/to/client-cert.pem \
|
|
ssl-key:/path/to/client-key.pem
|
|
</pre>
|
|
Finally, you may want to configure the specific SSL/TLS ciphersuites that
|
|
should be used; the <em>ssl-ciphers:</em> parameter can be used for this:
|
|
<pre>
|
|
LDAPServer ... ssl-ca:/path/to/cacert.pem \
|
|
ssl-cert:/path/to/client-cert.pem \
|
|
ssl-key:/path/to/client-key.pem \
|
|
ssl-ciphers:DEFAULT:!EXPORT:!DES
|
|
</pre>
|
|
|
|
<p>
|
|
If there is an issue with the server certificate presented by your LDAP
|
|
server, <b>but</b> you need to create the SSL/TLS session anyway, you can
|
|
relax the certificate verification requirements using the <em>ssl-verify:</em>
|
|
parameter, <i>e.g.</i>:
|
|
<pre>
|
|
LDAPServer ... ssl-ca:/path/to/cacert.pem \
|
|
ssl-verify:off
|
|
</pre>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPUsers">LDAPUsers</a></h3>
|
|
<strong>Syntax:</strong> LDAPUsers <em>base-dn [name-filter-template [uid-filter-template]]</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.3.5rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPUsers</code> directive activates LDAP UID-to-name lookups
|
|
for directory listings. The first parameter to this directive is the LDAP
|
|
<em>base DN</em> to use for UID-to-name lookups. The optional second parameter
|
|
is a template to be used for the search filter for the username; <code>%v</code>
|
|
will be replaced with the UID that is being looked up. Similarly, an optional
|
|
third parameter is also a template, to be used for the search filter for
|
|
the UID.
|
|
|
|
<p>
|
|
By default, the name search filter template looks like this:
|
|
<pre>
|
|
(&(uid=%v)(objectclass=posixAccount))
|
|
</pre>
|
|
and the UID search filter template looks like this:
|
|
<pre>
|
|
(&(LDAPAttr_uidNumber=%v)(objectclass=posixGroup))
|
|
</pre>
|
|
The <em>uidNumber</em> attribute name used in the search filter comes from
|
|
the <a href="#LDAPAttr"><code>LDAPAttr</code></a> directive.
|
|
Note that filter templates are only supported in <code>mod_ldap</code>
|
|
version 2.7 and later.
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPUseSASL">LDAPUseSASL</a></h3>
|
|
<strong>Syntax:</strong> LDAPUseSASL <em>mech1 ...</em><br>
|
|
<strong>Default:</strong> None<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.3.7rc4 and later
|
|
|
|
<p>
|
|
The <code>LDAPUseSASL</code> directive tells the <code>mod_ldap</code> module
|
|
to use the configured space-separated list of
|
|
<a href="https://ldapwiki.com/wiki/SASL">SASL</a> (Simple Authentication and
|
|
Security Layer) mechanisms, when using the
|
|
<a href="#LDAPBindDN"><code>LDAPBindDN</code></a> to talk to the LDAP server.
|
|
By default, <em>simple</em> binds are done to the LDAP server.
|
|
|
|
<p>
|
|
The currently supported mechanisms are:
|
|
<ul>
|
|
<li>ANONYMOUS
|
|
<li>CRAM-MD5
|
|
<li>DIGEST-MD5
|
|
<li>LOGIN
|
|
<li>PLAIN
|
|
<li>SCRAM-SHA-1
|
|
</ul>
|
|
The order in which the mechanisms are configured matters; the first one
|
|
selected by the LDAP server wins.
|
|
|
|
<p>
|
|
<b>Note</b> that a SASL mechanism configured here may still be rejected by
|
|
the LDAP server, if the server-side policies for authentication are not met.
|
|
Indeed, some SASL mechanisms may only be allowed by the server <i>if</i> used
|
|
in conjunction with SSL/TLS; this is a common requirement for using the
|
|
<code>LOGIN</code> and <code>PLAIN</code> mechanisms.
|
|
|
|
<p>
|
|
Thus a good default configuration, using TLS <i>and</i> SASL, might be:
|
|
<pre>
|
|
<IfModule mod_ldap.c>
|
|
LDAPServer ldap.example.com
|
|
LDAPBindDN CN=readonly,DC=example,DC=com ...
|
|
LDAPUseSASL SCRAM-SHA-1 DIGEST-MD5
|
|
LDAPUseTLS on
|
|
</IfModule>
|
|
</pre>
|
|
|
|
<p>
|
|
<hr>
|
|
<h3><a name="LDAPUseTLS">LDAPUseTLS</a></h3>
|
|
<strong>Syntax:</strong> LDAPUseTLS <em>on|off</em><br>
|
|
<strong>Default:</strong> off<br>
|
|
<strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br>
|
|
<strong>Module:</strong> mod_ldap<br>
|
|
<strong>Compatibility:</strong> 1.2.7rc1 and later
|
|
|
|
<p>
|
|
The <code>LDAPUseTLS</code> directive configures whether <code>mod_ldap</code>
|
|
will use SSL/TLS via <a href="https://en.wikipedia.org/wiki/STARTTLS">STARTTLS</a> to protect the connections made to the configured LDAP servers.
|
|
|
|
<p>
|
|
By default, the <code>mod_ldap</code> module connects to the LDAP server via
|
|
non-encrypted connections. Enabling this option causes <code>mod_ldap</code>
|
|
to use an encrypted (TLS/SSL) connection to the LDAP server. If a secure
|
|
connection to the LDAP server fails, <code>mod_ldap</code> will not
|
|
authenticate users; <code>mod_ldap</code> will <b>not</b> fall back to an
|
|
unsecure connection.
|
|
|
|
<p>
|
|
<hr>
|
|
<h2><a name="Installation">Installation</a></h2>
|
|
Follow the normal steps for using third-party modules in ProFTPD:
|
|
<pre>
|
|
$ ./configure --with-modules=mod_ldap
|
|
$ make
|
|
$ make install
|
|
</pre>
|
|
You may need to specify the location of the OpenLDAP header and library files
|
|
in your <code>configure</code> command, <i>e.g.</i>:
|
|
<pre>
|
|
$ ./configure --with-modules=mod_ldap \
|
|
--with-includes=/usr/local/openldap/include \
|
|
--with-libraries=/usr/local/openldap/lib
|
|
</pre>
|
|
|
|
<p>
|
|
<hr>
|
|
<h2><a name="Usage">Usage</a></h2>
|
|
|
|
<p>
|
|
One <code>mod_ldap</code> user submitted the following configuration for
|
|
allowing <code>mod_ldap</code> to communicate to a Windows Active Directory
|
|
server. Note that this configuration has not been tested; if it works for
|
|
you (or not), please let us know:
|
|
<pre>
|
|
<IfModule mod_ldap.c>
|
|
LDAPServer ldaps://dc.example.org:3268
|
|
LDAPUseTLS on
|
|
LDAPAuthBinds on
|
|
LDAPBindDN "cn=SRV_ACC_SVN_AUTH,ou=special accounts,ou=Sales,dc=example,dc=org" ******************
|
|
|
|
LDAPUsers ou=Users,ou=Sales,dc=example,dc=org "(&(sAMAccountName=%u)(objectclass=user)(memberOf=cn=Linux Admins,ou=Groups,ou=Sales,dc=example,dc=com))"
|
|
LDAPSearchScope subtree
|
|
|
|
# Assign default IDs
|
|
LDAPDefaultUID 106
|
|
LDAPDefaultGID 65534
|
|
|
|
# Create the home directory
|
|
LDAPGenerateHomedir on
|
|
LDAPGenerateHomedirPrefix /home
|
|
|
|
# Use different attribute names where necessary
|
|
LDAPAttr uid sAMAccountName
|
|
LDAPAttr gidNumber primaryGroupID
|
|
</IfModule>
|
|
</pre>
|
|
|
|
<p>
|
|
<b>Logging</b><br>
|
|
The <code>mod_ldap</code> module supports <a href="../howto/Tracing.html">trace logging</a>, via the module-specific log channels:
|
|
<ul>
|
|
<li>ldap
|
|
<li>ldap.library
|
|
</ul>
|
|
Thus for trace logging, to aid in debugging, you would use the following in
|
|
your <code>proftpd.conf</code>:
|
|
<pre>
|
|
TraceLog /path/to/ftpd/trace.log
|
|
Trace ldap:20
|
|
</pre>
|
|
This trace logging can generate large files; it is intended for debugging use
|
|
only, and should be removed from any production configuration.
|
|
|
|
<p><a name="FAQ">
|
|
<b>Frequently Asked Questions</b><br>
|
|
|
|
<p><a name="ScopesFAQ">
|
|
<font color=red>Question</font>: Why is <code>mod_ldap</code> using a "base"
|
|
scope by default, rather than "subtree"? I configured:
|
|
<pre>
|
|
LDAPSearchScope subtree
|
|
</pre>
|
|
but it is not working; I see the following in my LDAP server logs:
|
|
<pre>
|
|
slapd[31709]: conn=20239 op=1 SRCH <b>base</b>="ou=people,dc=example,dc=com" scope=0 deref=0 filter="(&(uid=tj)(objectClass=posixAccount))"
|
|
</pre>
|
|
<font color=blue>Answer</font>: The use of the "base" scope for searches, in
|
|
spite of any <code>LDAPSearchScope</code> directive, happens when a URL, rather
|
|
than hostname/port, are used in the <code>LDAPServer</code> directive. <a href="https://tools.ietf.org/html/rfc2255">RFC 2255</a>, Section 3 specifies that the default scope is "base".
|
|
|
|
<p>
|
|
Thus instead of:
|
|
<pre>
|
|
LDAPServer ldap://ldap.example.com
|
|
</pre>
|
|
you will need to use:
|
|
<pre>
|
|
LDAPServer ldap://ldap.example.com/??sub
|
|
</pre>
|
|
See the <a href="#LDAPSearchScope"><code>LDAPSearchScope</code></a>
|
|
documentation for more details.
|
|
|
|
<p><a name="HomedirsFAQ">
|
|
<font color=red>Question</font>: How do I use <code>LDAPGenerateHomedir</code>
|
|
and <code>CreateHome</code> together successfully? Can I use <i>just</i>
|
|
<code>LDAPGenerateHomedir</code>?<br>
|
|
<font color=blue>Answer</font>: If you want to have home directories for your
|
|
LDAP users automatically <b>created</b>, you <b>do</b> need to use the
|
|
<a href="../howto/CreateHome.html"><code>CreateHome</code></a> directive.
|
|
Whether you <em>need</em> to use the <a href="#LDAPGenerateHomedir"><code>LDAPGenerateHomedir</code></a> directive is a different (but related) question.
|
|
|
|
<p>
|
|
The <code>LDAPGenerateHomedir</code> directive (and its relative <a href="#LDAPForceGeneratedHomedir"><code>LDAPForceGeneratedHomedir</code></a>) should be
|
|
used <i>when you want to users to have a different home directory than is
|
|
configured for them in LDAP</i>. They are <b>not</b> used for creating these
|
|
directories, just generating the paths to use.
|
|
|
|
<p>
|
|
Thus to <i>generate</i> a different home directory for your LDAP-defined users,
|
|
<i>and</i> to have these different home directories <em>created</em>, you
|
|
might use something like this:
|
|
<pre>
|
|
<IfModule mod_ldap.c>
|
|
...
|
|
LDAPGenerateHomedir on
|
|
LDAPGenerateHomedirPrefix /data
|
|
LDAPForceGeneratedHomedir on
|
|
|
|
# And make sure these home directories are created
|
|
CreateHome on 0770 skel /opt/ProFTPD/etc/skel
|
|
...
|
|
</IfModule>
|
|
</pre>
|
|
|
|
<p><a name="MultipleBindsFAQ">
|
|
<font color=red>Question</font>: In my LDAP server logs, I see ProFTPD make
|
|
<i>multiple</i> binds for the same client logging in:
|
|
<pre>
|
|
slapd[31709]: conn=20239 op=0 BIND dn="cn=admin,dc=example,dc=com" method=128
|
|
slapd[31709]: conn=20239 op=0 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0
|
|
</pre>
|
|
I was expecting just <i>one</i> bind. Is this a bug, or is it expected
|
|
behavior?<br>
|
|
<font color=blue>Answer</font>: Yes, this <em>is</em> the expected behavior.
|
|
See the <a href="#LDAPAuthBinds"><code>LDAPAuthBinds</code></a> directive
|
|
for details.
|
|
|
|
<p>
|
|
<b>Note</b> that you may see <i>additional</i> binds when other modules, such
|
|
as <code>mod_ifsession</code>, are present in your <code>proftpd</code> build.
|
|
|
|
<p>
|
|
<hr>
|
|
<font size=2><b><i>
|
|
© Copyright 2013-2023 TJ Saunders<br>
|
|
All Rights Reserved<br>
|
|
</i></b></font>
|
|
<hr>
|
|
|
|
</body>
|
|
</html>
|