ejabberd with LDAP authorization
I parted from ICQ for a long time and without regrets. Taking the opportunity, I raised my own Jabber-server, which I have been successfully using to this day. However, not all of my employees have a Jabber account (not everyone even knows what it is :-), which makes communication at work somewhat difficult. To communicate with the others, to organize a secure and independent messaging system, I decided to raise a corporate jabber server. And since we are actively using LDAP, it seemed logical to use it for user authentication and account management.
- OS: FreeBSD 5.4
- There are several sites on the server, including the site of our company with the company.ru domain (in order not to be accused of self-promotion - the name has been changed :-)
- LDAP server at ldap.company.local (our servers are connected to the local network of company.local)
- ejabberd 1.1.4_2 (latest version on FreeBSD ports at the time of installation)
All paths in the note are specific to FreeBSD, they may be different on other systems.
')
I installed ejabberd from FreeBSD ports without any difficulty. You can read about installing on other systems in the ejabberd manual .
It is important to understand how ejabberd works with settings. He has two sources:
Comments begin with the% character and end with the end of the line.
Teams must end with a full stop.
Parameters are specified like this:
Lists are indicated in square brackets. List items are separated by commas. After the last element a comma is not put.
For the first time this will be enough.
The initial setup is done by editing the
First of all, you need to specify which part of the configuration (stored in the database) we want to change. There are three commands for this:
The next step is to link ejabberd services to TCP ports and configure these services. There are four services (or modules):
If we want to communicate not only with each other, but also with users of other servers, we need to perform additional configuration of s2s connections:
To access the web interface, add the admins access list, allow its members access to the configuration, and add myself to this list:
ejabberd can serve several virtual domains with different configurations. I have only one domain listed:
All further parameters I will specify only for this domain:
I add commands to a virtual host:
To use SSL, you will need a certificate.
In the configuration files directory (/ usr / local / etc / ejabberd) I execute the following commands:
After that, the server.cer file can be safely removed.
This configuration is enough to test the server. I execute
I did it all on the first try. Now try the web interface. In my configuration, it is located at:
For authorization, you must specify the same data as when using the Jabber-client.
Here you can go to “Virtual hosts - company.ru - Users” and see the list of users who can use this jabber server.
UPD : To view the list, you need to add lines to your host configuration:
When working with a new program or technology, the most difficult thing is to start. Personally, at first I was embarrassed by an example of a configuration file, embarrassed by an unusual syntax and size. And the documentation, I confess, too. Therefore, I tried to create a minimum configuration that allowed at least to start the server and connect to it. Having a working server in hand, you can further customize it, hang modules, tune, and so on. The main thing - a solid foundation underfoot.
I hope in the near future my hands will reach me to write about the further configuration. Or maybe someone else will do it ;-)
Sometimes, after a crash, ejabberd refuses to start. Check whether the beam and empd processes or other erlang applications are hanging.
In order to manage all virtual domains via the web interface, the {access, configure, ...} entry must be located in the global scope and not in the virtual host configuration.
When using an LDAP backend, the client must enable the “Allow plaintext login” option. UPD: This is not a password security threat if using SSL. In this case, the encrypted connection to the server is first established, and then the open password is transmitted. For example, in the Psi client, this is configured as follows: Encrypt connection: Always; Allow plaintext authentication: Over encrypted connection.
Initial data
- OS: FreeBSD 5.4
- There are several sites on the server, including the site of our company with the company.ru domain (in order not to be accused of self-promotion - the name has been changed :-)
- LDAP server at ldap.company.local (our servers are connected to the local network of company.local)
- ejabberd 1.1.4_2 (latest version on FreeBSD ports at the time of installation)
All paths in the note are specific to FreeBSD, they may be different on other systems.
')
Installation
I installed ejabberd from FreeBSD ports without any difficulty. You can read about installing on other systems in the ejabberd manual .
Customization
It is important to understand how ejabberd works with settings. He has two sources:
- DB with the current configuration (/ var / spool / ejabberd /)
- Text files (/ usr / local / etc / ejabbrd /)
- ejabberd uses the configuration written to the database;
- the web interface changes data only in the database;
- configuration files are read only once at the start of ejabberd;
- configuration files rewrite the information in the database, but not all, but only the specified part (which one - see below about override_XXX).
- Changes made via the web interface may be lost when restarting ejabberd
- Changes made to the configuration file may not affect the ejabberd configuration
A little about the syntax of the configuration files
Comments begin with the% character and end with the end of the line.
Teams must end with a full stop.
Parameters are specified like this:
{parameter, value}
Lists are indicated in square brackets. List items are separated by commas. After the last element a comma is not put.
For the first time this will be enough.
Initial setup
The initial setup is done by editing the
/usr/local/etc/ejabberd/ejabberd.cfg file.First of all, you need to specify which part of the configuration (stored in the database) we want to change. There are three commands for this:
- override_global - global parameters relating to all nodes in the cluster (what a cluster, at first, is not very important)
- override_local - parameters of the current node (server) only
- override_acls - only permission settings
override_global. override_local. override_acls.
Ports and Services
The next step is to link ejabberd services to TCP ports and configure these services. There are four services (or modules):
- ejabberd_c2s - maintains client connections to the server
- ejabberd_s2s_in - serves incoming connections from other jabber servers
- ejabberd_service - interacts with external components (transports)
- ejabberd_http - serves HTTP connections
{listen, [
% Client server
{5222, ejabberd_c2s, [
starttls, {certfile, "./server.pem"}% Use StartTLS. The path to the certificate indicates relatively
% configuration file. We will create the server.pem certificate later.
]},
% Server-to-server. If we want to communicate not only within our domain
{5269, ejabberd_s2s_in, [
]},
% HTTP service
{5280, ejabberd_http, [
web_admin% Provide a web interface
]}
]}.
If we want to communicate not only with each other, but also with users of other servers, we need to perform additional configuration of s2s connections:
{s2s_use_starttls, true}. % Use StartTLS for inter-server communication
{s2s_certfile, "/usr/local/etc/ejabberd/server.pem"}. % Certificate. will create later.
{outgoing_s2s_port, 5269}. % I don’t know exactly what it is, but without that it didn’t work for me :-)
To access the web interface, add the admins access list, allow its members access to the configuration, and add myself to this list:
{acl, admins, {user, "my_login", "company.ru"}}. % admins is an arbitrary list name, my_login is my account in LDAP,
% company.ru - virtual domain on which the server will work
{access, configure, [{allow, admins}]}. % configure - permission to configure the server, admins - list name
Domain Settings
ejabberd can serve several virtual domains with different configurations. I have only one domain listed:
{hosts, ["company.ru"]}.
All further parameters I will specify only for this domain:
{host_config, "company.ru", [
... here I will specify the parameters of the company.ru host ...
]}.
LDAP connection
I add commands to a virtual host:
{auth_method, ldap},% Authentication Method - LDAP
{ldap_servers, ["ldap.company.local"]},% Address of the LDAP server
{ldap_port, 389},% His port
{ldap_base, "ou = people, dc = company, dc = local"}% Base DN of user accounts
Creating a certificate
To use SSL, you will need a certificate.
In the configuration files directory (/ usr / local / etc / ejabberd) I execute the following commands:
$ openssl req -newkey rsa: 1024 -keyout server.pem -nodes -x509 -days 3650 -out server.cer $ echo "" >> server.pem $ cat server.cer >> server.pem $ chown ejabberd: ejabberd server.pem $ chmod 0400 server.pem
After that, the server.cer file can be safely removed.
First start
This configuration is enough to test the server. I execute
/usr/local/etc/rc.d/ejabberd start and watch the log /var/log/ejabberd/sasl.log . If there are no CRASH REPORT records in it, then the server has started normally. For verification, you can connect the Jabber client to company.ru using the login my_login@company.ru (my_login is my LDAP login, and company.ru is the virtual host specified in ejabberd) and the password from LDAP. If it fails, you need to check the connection with LDAP, ldap_base and, of course, the logs.I did it all on the first try. Now try the web interface. In my configuration, it is located at:
http://company.ru:5280/admin/
For authorization, you must specify the same data as when using the Jabber-client.
Here you can go to “Virtual hosts - company.ru - Users” and see the list of users who can use this jabber server.
UPD : To view the list, you need to add lines to your host configuration:
{modules, [
{mod_last, []},
{mod_offline, []}
]}
Conclusion
When working with a new program or technology, the most difficult thing is to start. Personally, at first I was embarrassed by an example of a configuration file, embarrassed by an unusual syntax and size. And the documentation, I confess, too. Therefore, I tried to create a minimum configuration that allowed at least to start the server and connect to it. Having a working server in hand, you can further customize it, hang modules, tune, and so on. The main thing - a solid foundation underfoot.
I hope in the near future my hands will reach me to write about the further configuration. Or maybe someone else will do it ;-)
The resulting config
%
% SHARED OPTIONS
%
% Override all settings
override_global.
override_local.
override_acls.
% Ports and services
{listen, [
% Client to server
{5222, ejabberd_c2s, [
starttls, {certfile, "/usr/local/etc/ejabberd/server.pem"}
]},
% Server to server
{5269, ejabberd_s2s_in, [
]},
% HTTP service
{5280, ejabberd_http, [
web_admin
]}
]}.
% Use STARTTLS + Dialback for S2S connections
{s2s_use_starttls, true}.
{s2s_certfile, "/usr/local/etc/ejabberd/server.pem"}.
% If SRV lookup fails, then port 5269 is used to communicate with remote server
{outgoing_s2s_port, 5269}.
% Webadmin access
{acl, admins, {user, "my_login", "company.ru"}}.
{access, configure, [{allow, admins}]}.
% Host config
{hosts, ["company.ru"]}.
%
% HOST: company.ru
%
{host_config, "company.ru", [
{auth_method, ldap},
{ldap_servers, ["ldap.company.local"]},
{ldap_port, 389},
{ldap_base, "ou = people, dc = 3wstyle, dc = local"}
]}.
A few notes
Sometimes, after a crash, ejabberd refuses to start. Check whether the beam and empd processes or other erlang applications are hanging.
In order to manage all virtual domains via the web interface, the {access, configure, ...} entry must be located in the global scope and not in the virtual host configuration.
When using an LDAP backend, the client must enable the “Allow plaintext login” option. UPD: This is not a password security threat if using SSL. In this case, the encrypted connection to the server is first established, and then the open password is transmitted. For example, in the Psi client, this is configured as follows: Encrypt connection: Always; Allow plaintext authentication: Over encrypted connection.
Links
Source: https://habr.com/ru/post/44154/
All Articles