Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Introduction This document details how to configure your Openfire installation

Introduction This document details how to configure your Openfire installation to use an external directory such as Open LDAP or Active Directory. Integration with a directory lets users authenticate using their directory username and password. Optionally, you can configure Openfire to load user profile and group information from the directory. Any group in Openfire can be designated as a shared group, which means that you can pre-populate user's rosters using directory groups. Background LDAP (Lightweight Directory Access Protocol) has emerged as a dominant standard for user authentication and for storage of user profile data. It serves as a powerful tool for large organizations (or those organizations integrating many applications) to simplify user management issues. Many LDAP servers are available, such as Open LDAP, Active Directory, and Novell's eDirectory. By default, Openfire stores all user data in its database and performs authentication using database lookups. The LDAP module replaces that functionality and allows Openfire to: Use a LDAP server to authenticate a user's identity. Load user profile information from a LDAP directory. Load group information from an LDAP directory. Note: Openfire treats the LDAP directory as read-only. This document will guide you through configuring LDAP support in Openfire. These instructions assume that you're a competent LDAP user, and that you're familiar with Openfire setup issues. Configuration The Openfire setup tool includes an easy to use LDAP setup wizard. Choose the LDAP option on the Profile Settings page to configure directory integration. The wizard along with in-line help will guide you through the rest of the process. Specific tips for working with Active Directory are noted below. LDAP Guide « Back to documentation index Openfire: LDAP Guide http://www.igniterealtime.org/builds/openfire/docs/latest/documentatio... 1 de 7 11/03/2015 10:35 If you have already completed the setup process but need to enable LDAP integration, you can re-run the setup tool. To do so: Stop Openfire. 1. Edit conf/openfire.xml in your Openfire installation folder and set <setup>true</setup> to <setup>false</setup>. 2. Restart Openfire and enter the setup tool. 3. Working with Active Directory Microsoft's Active Directory is a broadly deployed directory system that supports the LDAP protocol. You'll be prompted for several LDAP fields when connecting to Active Directory servers, some of which are detailed below: Base DN The base DN describes where to load users and groups. If you're using a default Active Directory setup, all user accounts and groups are located in the "Users" folder under your domain. In LDAP form, that's cn=Users;dc=<Your Domain>. To get more specific, say your domain is activedirectory.jivesoftware.com. In that case, your base DN would be cn=Users; dc=activedirectory,dc=jivesoftware,dc=com. If you've customized where users are stored, you'll just need to replicate that folder structure using LDAP syntax. Administrator DN By default, Active Directory does not allow anonymous LDAP connections. Therefore, you'll need to enter the DN of a user that's allowed to connect to the server and read all user and group data. Unless you've created a special user account for this purpose, an easy choice is to use the built-in administrator account. By default, the administrator DN is in the form cn=Administrator,dc=<Your Domain>. Using our previous example, cn=Administrator,cn=users,dc=activedirectory,dc=jivesoftware,dc=com. Manually Editing the Config File If you prefer to edit the configuration file to enable LDAP integration directly, use the following instructions. Open the configuration file conf/openfire.xml from your Openfire installation in your favorite editor and add or change the following settings. Properties flagged with ( *) must be set. Properties flagged with (**) must be set in order to enable LDAP group support, all other properties are optional: Main Settings provider.user.className * -- set the value to "org.jivesoftware.openfire.ldap.LdapUserProvider". provider.auth.className * -- set the value to "org.jivesoftware.openfire.ldap.LdapAuthProvider". ldap.host * -- LDAP server host; e.g. localhost or machine.example.com, etc. It is possible to use Openfire: LDAP Guide http://www.igniterealtime.org/builds/openfire/docs/latest/documentatio... 2 de 7 11/03/2015 10:35 many LDAP servers but all of them should share the same configuration (e.g. SSL, baseDN, admin account, etc). To specify many LDAP servers use the comma or the white space character as delimiter. ldap.port -- LDAP server port number. If this property is not set, the default value is 389. ldap.connectionTimeout -- The value of this property is the string representation of an integer representing the connection timeout in milliseconds. If the LDAP provider doesn't connect within the specified period, it aborts the connection attempt. The integer should be greater than zero. An integer less than or equal to zero means no connection timeout is specified in which case the default 10 seconds timeout is used. Does not apply to SSL connections. ldap.readTimeout -- The value of this property is the string representation of an integer representing the read timeout in milliseconds for LDAP operations. If the LDAP provider doesn't get an LDAP response within the specified period, it aborts the read attempt. The integer should be greater than zero. An integer less than or equal to zero means no read timeout is specified which is equivalent to waiting for the response infinitely until it is received which defaults to the original behavior. Requires Java 1.6 or later. ldap.baseDN * -- the starting DN that searches for users will performed with. The entire subtree under the base DN will be searched for user accounts. ldap.alternateBaseDN -- a second DN in the directory can optionally be set. If set, the alternate base DN will be used for authentication, loading single users and displaying a list of users. Content in the base DN and the alternate DN will be treated as one. ldap.adminDN -- a directory administrator's DN. All directory operations will be performed with this account. The admin must be able to perform searches and load user records. The user does not need to be able to make changes to the directory, as Openfire treats the directory as read-only. If this property is not set, an anonymous login to the server will be attempted. ldap.adminPassword -- the password for the directory administrator. ldap.usernameField -- the field name that the username lookups will be performed on. If this property is not set, the default value is uid. Active Directory users should try the default value sAMAccountName. ldap.nameField -- the field name that holds the user's name. If this property is not set, the default value is cn. Active Directory users should use the default value displayName. ldap.emailField -- the field name that holds the user's email address. If this property is not set, the default value is mail. Active Directory users should use the the default value mail. ldap.searchFields -- the LDAP fields that will be used for user searches. If this property is not set, the username, name, and email fields will be searched. An example value for this field is "Username/uid,Name/cname". That searches the uid and cname fields in the directory and labels them as "Username" and "Name" in the search UI. You can add as many fields as you'd like using comma-delimited "DisplayName/Field" pairs. You should ensure that any fields used for searching are properly indexed so that searches return quickly. ldap.searchFilter -- an optional search filter to append to the default filter when loading users. The default search filter is created using the attribute specified by ldap.usernameField. For example, if the username field is "uid", then the default search filter would be "(uid={0})" where {0} is dynamically replaced with the username being searched for. The most common usage of a search filter is to limit the entries that are users based on objectClass. For example, a reasonable search filter for a default Active Directory installation is "(objectClass=organizationalPerson)". When combined with the default filter, the actual search executed would be "(&(sAMAccountName={0})(objectClass=organizationalPerson))". ldap.subTreeSearch -- by default, Openfire will search the entire LDAP sub-tree (starting at the base DN) when trying to load users. If this property is set to false, then sub-tree searching is disabled and users will only be loaded directly from the base DN. Disabling sub-tree can improve performance, but it will fail to find users if your directory is setup to use sub-folders under the base DN. Group Settings provider.group.className ** -- set the value to "org.jivesoftware.openfire.ldap.LdapGroupProvider". ldap.groupNameField ** -- the field name that the groupname lookups will be performed on. If this property is not set, the default value is cn. ldap.groupMemberField -- the field name that holds the members in a group. If this property is not set, the default value is member. ldap.groupDescriptionField -- the field name that holds the description a group. If this property is not set, the default value is description. ldap.posixMode ** -- a value of "true" means that users are stored within the group by their user name alone. A value of "false" means that users are stored by their entire DN within the group. If this property is not set, the default value is false. The posix mode must be set correctly for your server in order for group integration to work. Posix modes for common LDAP servers: Openfire: LDAP Guide http://www.igniterealtime.org/builds/openfire/docs/latest/documentatio... 3 de 7 11/03/2015 10:35 ActiveDirectory: false ldap.groupSearchFilter -- an optional search filter to append to the default filter when uploads/s3/ ldap-guide 2 .pdf