[ejabberd] mod_vcard_ldap

Leif Johansson leifj at it.su.se
Wed Oct 20 18:57:35 MSD 2004


> 
>   For you it may not be that hard to implement but for me it would take a
> long time since I do not program in Erlang.  Up until I found ejabberd 2

I may look into it the next time I get around to coding for ejabberd.

> weeks ago I did not even know there was such a programming language. 
> Actually I am trying to figure out how to just get ejabberd to let me
> change the users password in ldap.  I don't see any code for encrypting

That all depends on how you store passwords in your directory server!
The userPassword attribute actually specifies clear-text passwords but
usually stores values of the form "{" crypto-method "}" hash for
instance {CRYPT}.. crypt hash of password .. But you have no way of
knowing which crypt-mech to use.

Please note that using your directory server as an authentication server
in the normal way (bind with DN+password over tls) is a no-no. LDAP was
never meant to be used this way and you are better off just using your
/etc/passwd (or PAM on a modern unix). Using LDAP for auth doesn't get
you anything of value. The reason I wrote the exauth patch was to
support the case where you LDAP server stores information and something
else (radius etc) does auth.

Having said that it is certainly a very common "misstake" and is often
supported. The problem (as you have discovered) is that there is no
standardized and widely deployed way to change passwords on an LDAP
server. Rfc 3062 ftp://ftp.rfc-editor.org/in-notes/rfc3062.txt describes
a method but your directory server must implement it. If you are using
a modern version of openldap I believe it works.

However this really doesn't belong in either mod_vcard_ldap or in the
extauth stuff. It might belong in the ldap method of ejabberd though.

> the password to be used with ldap.  Actually the encrypted password was
> the only reason I choosed to use ldap to begin with.  If ejabberd would
> encrypt the password on the server then I would have no reason to use
> ldap at all.

You could use legacy jabber auth but I would not recommend it. Sasl is
the way of the future (see below for a longer discussion).

>   I have never actually seen a server that didn't give the option to
> encrypt the user's password?

Just so that everyone is on the same page:

You touch on difficult problems. If you use shared-secred mechanisms
such as the legacy authentication system for jabber you run the risk of
exposing all your users passwords if your server is hacked (since the
hashes stored in the server are essentially password-equivalents). On
the other hand if you use encrypted passwords (for instance classical
unix crypt-passwords) you must protect the authentication with tls
to avoid exposing each password unencrypted on the network.

The right (TM) solution is to use a real authentication framework such
as kerberos which used with standardized apis/protocol wrappers such
as sasl+gssapi allows your clients to authenticate cleanly to the
service. The downside is that your xmpp-clients need to understand
sasl+gssapi. We will probably see this in the near future since this
is the only way to authenticate if your authentication server is an
ActiveDirectory (which uses kerberos).

Unless you can mandate the use of sasl-enabled clients and have a
kerberos infrastructure (perhaps in the form of an AD domain) you are
left with using either legacy jabber auth or passwords+tls. In the
latter case you need a way to change passwords from the xmpp-server
which doesn't store them.

	MVH leifj



More information about the ejabberd mailing list