[ejabberd] mod_vcard_ldap

dragon_sphere at vdsworld.com dragon_sphere at vdsworld.com
Thu Oct 21 19:10:46 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
>
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd
>
Actually I agree with you completely here.  That is why my OpenLDAP server
is not setup to be seen by the world just the server that is running
ejabberd.  With that said I went a completely different route to allow
users to change their own passwords.  I deployed Apache+SSL+PHP and I have
a set of PHP scripts that allow the users to change their own passwords. 
This method allows them to navigate to the Apache web server with SSL
launch the PHP script which talks to the LDAP server locally and enter
their uid, old password, and new password*2 and submit the change.  The
ejabberd server is setup with ldap authentication + SSL only and will
authenticate the users.  Since I am in a closed environment I can do this.
 I personally know all the users on my ejabberd server.  I am currently
using ejabberd 0.7.5 so the newer methods for encryption on the wire is
employed and I have it as a requirement.  BTW I block access to the ldap
server at the router and none of the config files are setup for internet
access so all this is behind an infrastructure that I can control.  Also
ldap is setup such that it only allows the administrator full access to
all records and the users only have access to their records.  Now if there
was a MySQL or some other DB besides the method for keeping this
information built into ejabberd then I would be very happy to use it but
my knowledge of Erlang is very limited and I don't really have time to
learn another programming language.
  Once I get everything cleaned up I will be posting my config files and
network diagrams allong with links to the software that I am using so
others in the list will be able to at least get this far.  I feel that I
still have a long road to go down but for now this is working.  It's not
pretty but it does work and is not that hard for the end user to use.
  Now for the use of AD.  I really don't want to lock myself into having
to use Windows.  If later on I decide to use Linux or some other flavor
of *nix then I still can and I will not have to do alot of work to move
the users since I would prob. use OpenLDAP on those platforms as well.

So with all this said how exactly do you setup and use kerberos with
ejabberd?  What are the requirements for the server and the client?  I
have done some reading but I have not setup kerberos before.  I know that
MIT came up with this and I understand some of it's logic that I read
about but I don't understand how to tie it to a specific non-related
service like ejabberd or even if this is required.  Where does the
chalenge happen for the ticket granting ticket and how does kerberos know
how to grant access to ejabberd?  I guess I should try to install this to
see first hand how this would work.  I really like the idea behind it
because the users would only have to submit their credentials "login" once
and the services are granted as they go but I don't want to use anything
that is built into Windows if I can help it.  I like the idea of using
stuff that is more or less cross platform or at least have other OS
choices for future moves.

Basicly I can spell kerberos but I don't think I am pronouncing it right?

Thanks for all your help and info it's been very educational.
Thanks,
JKinsey



More information about the ejabberd mailing list