OpenLDAP provides authentication support that is distributable across platforms and geography. Jabberd 2 requires a minimum version of OpenLDAP 2.1.0.
Complete this section if you are using OpenLDAP authorization. Your OpenLDAP installation should not require special configuration for Jabberd 2; however, at the time of writing (Jabberd 2 stable release 3), there is an important issue regarding Jabberd connection with OpenLDAP v3 servers. Jabberd 2 currently uses v2 syntax. By default, OpenLDAP v3 servers require v3 syntax.
There is a workaround for this issue. Add the following statement to your slapd.conf file, and restart your slapd daemon:
allow bind_v2
This statement will allow your Jabberd 2 server to connect to your OpenLDAP v3 server.
c2s.xml)
Complete this section if you are using OpenLDAP for authentication. OpenLDAP configuration is more detailed because configuration requires host and connection settings in addition to query settings.
In c2s.xml under the section labeled Authentication/registration database configuration, edit the driver to use ldap (OpenLDAP):
<!-- Authentication/registration database configuration -->
<authreg>
<!-- Backend module to use -->
<module>ldap<module>
LDAP module configuration in c2s.xml deals with the settings required to connect to your OpenLDAP server. The host must either be a hostname resolvable by the server or the IP address of the OpenLDAP server. Port 389 is the default port for OpenLDAP servers, so in most cases, port should be left as is. The v3 tag specifies whether your OpenLDAP server is v3. Uncomment this tag if it is. Leave the v3 tag commented for OpenLDAP v2 servers. Lastly, uncomment either the starttls or ssl tag if your server supports encryption (see notes below):
<!-- LDAP module configuration -->
<ldap>
<!-- LDAP server host and port (default: 389) -->
<host>ldap.example.com</host>
<port>389</port>
<!-- Use LDAP v3 if possible. If disabled, v2 will be used.
Encryption options are only available if v3 is enabled. -->
<!--
<v3/>
-->
<!-- Encryption. If enabled, this will create an encrypted channel
to the LDAP server using the LDAP STARTTLS mechanism. -->
<!--
<starttls/>
-->
<!-- Encryption. If enabled, this will create an encrypted channel
to the server using the old-style "ldaps://" mechanism. It is
recommended that you use <starttls/> instead of this. -->
<!--
<ssl/>
-->
|| TODO: note that PAM should use SSL/TLS ||
v3 and starttls tags. On the other hand, the author has not had success using SSL encryption between Jabberd 2 and OpenLDAP. To set up SSL, you should specify the OpenLDAP SSL hostname (if different from the non-SSL hostname). This is often something like ldaps.example.com. More importantly, you should specify the SSL port. The standard SSL port (LDAPS) for OpenLDAP is 636. Lastly, you should uncomment the ssl tag.
binddn is the full RDN (relative distinguished name) for the user. This may be something like cn=admin,ou=people,dc=example,dc=com :
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn>cn=Directory Manager</binddn>
<bindpw>secret</bindpw>
-->
uidattr tags. This ID should be the attribute by which your users are uniquely identified under the specified base DN (distinguished name). In other words, when querying against the specified base DN, the specified uidattr should uniquely identify each user. The basedn attribute specifies the base against which queries are run. This can be the topmost DN of the OpenLDAP server, such as dc=example,dc=com or it can be an RDN below which the user entries are found, such as ou=people,ou=sales,dc=example,dc=com. Using a lower level RDN is likely to speed OpenLDAP queries. Lastly, if your configuration requires multiple realms, you can specify a base DN for each by using the realm attribute of the basedn tag. Note that if you are not using multiple realms, you need only to specify a single basedn without the realm attribute:
<!-- LDAP attribute that holds the user ID (default: uid) -->
<uidattr>uid</uidattr>
<!-- base DN of the tree. You should specify a DN for each
authentication realm declared in the <local/> section above,
by using the realm attribute. -->
<basedn realm='company'>o=Company.com</basedn>
<basedn>o=Example Corp.</basedn>
</ldap>
Below is an obfuscated view of the author's working OpenLDAP configuration:
<!-- LDAP module configuration -->
<ldap>
<!-- LDAP server host and port (default: 389) -->
<host>ldap.mydomain.org</host>
<port>389</port>
<!-- Use LDAP v3 if possible. If disabled, v2 will be used.
Encryption options are only available if v3 is enabled. -->
<v3/>
<!-- Encryption. If enabled, this will create an encrypted channel
to the LDAP server using the LDAP STARTTLS mechanism. -->
<starttls/>
<!-- Encryption. If enabled, this will create an encrypted channel
to the server using the old-style "ldaps://" mechanism. It is
recommended that you use <starttls/> instead of this. -->
<!--
<ssl/>
-->
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn>cn=admin,dc=mydomain,dc=org</binddn>
<bindpw>snip</bindpw>
-->
<!-- LDAP attribute that holds the user ID (default: uid) -->
<uidattr>uid</uidattr>
<!-- base DN of the tree. You should specify a DN for each
authentication realm declared in the <local/> section above,
by using the realm attribute. -->
<basedn>ou=people,ou=design,dc=mydomain,dc=org</basedn>
</ldap>
Users cannot create their own accounts when using OpenLDAP for authentication. Therefore, public account registration should be disabled, while auto-create should be enabled so that the session manager can create accounts the first time users log on.
In c2s.xml, look for the Registration configuration subsection under the Authentication/registration database configuration section. Commenting the enable tag as below will disable public registration:
<!-- Registration configuration -->
<register>
<!-- Account registration is enabled by default (provided the
auth/reg module in use supports it). Comment this out to
disable. -->
<!-- <enable/> -->
In sm.xml under the section labeled User options (near the bottom of the file), uncomment the auto-create tag as below so that the session manager will create a new Jabberd2 account the first time a user logs on:
<!-- User options -->
<user>
<!-- By default, users must explicitly created before they can start
a session. The creation process is usually triggered by a c2s
component in response to a client registering a new user.
Enableing this option will make it so that a user create will be
triggered the first time a non-existant user attempts to start
a session. This is useful if you already have users in an
external authentication database (eg LDAP) and you don't want
them to have to register. -->
<auto-create/>
Your Jabberd 2 configuration for storage and authentication is now complete (provided that you have provisioned and configured for a storage package). Jump to the next section, Test Server, to begin testing your server before moving on other configuration tasks, such as configuring SSL, in Section 5.
© 2003 Will Kamishlian and Robert Norris
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.