Contents1. Scenario |
1. Scenario
The scenario goal is to set up OpenFire with LDAP based authentication against Microsoft (MS) Active Directory (AD).
2. A brief introduction to LDAP protocol
LDAP is an application protocol. OpenFire will act as a client to a LDAP server – MS AD in our case. We will use AD LDAP for two reasons:
- User authentication
- Contact list (roster) population with users and groups already defined in AD.
How it works:
- You enter username and password in your jabber client.
- Your client sends your credentials to the OpenFire Server.
- The OpenFire server tries to connect to the LDAP server with these credentials (make a bind). If connection is successful the OpenFire server knows, that you are the one who you pretend to be.
- The OpenFire server reads user and group information from the AD via LDAP protocol according to some predefined criteria (search filters).
Basic assumption:
The easiest way to understand LDAP protocol is to imagine that the file browser on your computer is a LDAP server. You have a com directory with a subdirectory named company. The company directory in turn contains a subdirectory named my and so on. Let’s assume that you search for all png files. Depending on your search starting point your results will vary. If you search starts at OUS folder, you probably won’t get any results. In terms of LDAP the search starting point is called base dn and the search criteria is called search filter.
Now a real example:
Suppose we have an AD. The domain is called my.company.com, and the FQDN of the domain controller is dc1.my.company.com . There are two groups: salesand it. Both reside in Groups Organizational Unit (OU), which resides in OUS. We also have a Users OU. At the picture below you can see how the AD looks like viewed in Active Directory Users and Computers (at foreground) and viewed by an MS LDAP browser called ADSIEDIT (at background). Please take a look at the Distinguished Name. You can think about it as a full path to an object (a group, a person, etc.) in AD while using LDAP notation. Remember the example above? You can denote cn as a common name, ou as an organizational unit , dc as a domain component.
You can see how people records (DNs) look like in the AD and in an LDAP browser:
3. Configure OpenFire
First open your web browser. In our case OF is installed on dc1.
Next enter a domain name.
Choose LDAP integration
Configure database settings, then enter necessary information. Please note, that you can use a dedicated user account for OF administrator, no need for AD administrative privileges. Test settings!
Tweak your user and group filters! You can use this simple filter to extract only users with a valid email address. Of course you can use any valid field in LDAP schema as a search criteria.
(&(objectClass=organizationalPerson)(mail=*))
You can filter groups by ‘group name’. This filter will extract only groups ending with ‘-fg’.
(&(objectClass=group)(cn=*-fg))
Remember to test the admin login!
4 Tuning performance
4.1 Java virtual machine memory settings
In order to achieve best performance you will need to increase default memory used by java VM. In Gentoo linux – go to /etc/conf.d/openfire
and change -Xmx2048m to the desired value.
| /etc/conf.d/openfire | ||
|
4.2 Cache properties
You have to monitor your cache performance and most likely you will have to increase cache size. Go to server manager:: Caches summary. Watch for Roster cache size and usage. Some symptoms of inefficient cache size are: slow user connection, users appears offline while connected, messages are delayed, LDAP server experiences heavy traffic. Properties to note:
cache.ldap.size
cache.userCache.size
cache.userGroup.size
cache.username2roster.size
cache.vcardCache.size
I achieve best performance boost with Username2Roster.
If you have a large number of users and frequent logins, you can try to enable authCache:
ldap.authCache.enabled
ldap.authCache.size
4.3 Uninstall modules
Remove all unneeded modules.
ToDo / Note this is a work in progress/:
add links, more tweaks, more search filters.