Sólo tienes que configurar las siguientes opciones:

{ldap_servers, ["localhost"]}.    % List of LDAP servers
{ldap_uidattr, "uid"}.            % LDAP attribute that holds user ID
{ldap_base, "ou=People,dc=example,dc=org"}. % Search base of LDAP directory
{ldap_rootdn, ""}. % LDAP manager
{ldap_password, ""}. % Password to LDAP manager

La clave está en ldap_uidattr que debe indicar el atributo que contiene el nombre de usuario sin el dominio. ¿En el es quema que utilizas existe un atributo como ese?

Si no es tu caso, tienes un problema. Existe la siguiente opción:

{ldap_uidattr_format, "%u@example.org"}

que indica que el atributo en ldap_uidattr no contiene sólo el nombre de usuario, sino una dirección de correo completa. Así ejabberd debe saber como extraer el nombre de usuario del atributo. Sin embargo yo nunca he usado dicha opción, por lo que no se si funciona.

Saludos

—
May the Free Software Force be with you…

Hola

Muchas gracias por tan rápida respuesta.

El tema está en que el esquema que uso para autenticar usuarios de otros servicios (concretamente los usuarios de correo) el el authldap.schema, que es el que utiliza el Courier (Objectclass CourierMailAccount).

Los usuarios se encuentran debajo de:
cn=usuarios,dc=dominioprincipal,dc=com
Está tambien el roodn que es: cn=admin,dc=dominioprincipal,dc=com con su correspondiente clave.

Los usuarios (de correo) tienen un campo que es mail que tiene el formato:
usuario@dominio.com
Donde dominio.com es cualquiera de los dominios para los que sirve el servidor de correo.

Yo lo que quiero es que todos los usuarios que tengan correo en ese servidor (cualquiera de los dominios) tenga tambien un usuario registrado en Jabber

El probado a poner el ldap_filter=%u@%d y otras miles de combinaciones, pero nada.
Tampoco me queda claro de donde el jabber lee la clave del usuario, ya que hsta ahora yp habia especificado (al autenticar con courier, o con SASL) el campo userPassword del objectclass CourierMailAccount…

Asi que… humm se me están abando los recursos…. Si me podéis ayudar os estaría agradecido “ad eternum”

Un saludo

Melo

La opción ldap_filter es utiliza para añadir alguna condición a la búsqueda de los usuarios, de forma que sólo tendrían cuenta en jabber los que cumplan cierta condición.

Como te dije en el mensaje anterior, la opción que deberías usar es ldapuidattrformat. Lo que ocurre es que no puedes poner ldapuidattrformat=%u@%d porque la única variable de sustitución que se puede utilizar es %u. Por tanto, necesitas que todos los usuarios tengan el mismo dominio.

Sin embargo no desesperes pues al menos veo 3 soluciones a tu problema:

1. Puedes configurar en ejabberd un servidor virtual para cada domino que sirve el servidor de correo. Como ya sabrás ejabberd admite ser configurado con varios servidores virtuales (de forma similar a lo que hace apache con los VirtualHost). Tendrías que configurar un servidor virtual para cada dominio de correo servido y en cada uno añadir la opción ldapuidattrformat=%u@dominio.com con dominio.com el domino de los usuarios servidos en cada servidor virtual concreto.

2. Pasate a ejabberd 2.0.0. Lamentablemente por el momento sólo hay una beta de esa versión de ejabberd (tendrías que bajartela del SVN y compilarla). Pero es una versión que añade una opción denominada ldapuids que permite indicar una lista de pares {ldapuid, ldapuidattrformat}. Así podrías indicar algo como: [{“mail”, “%u@dominio1.com”}, {“mail”, “%u@dominio2.com”}, …]

3. Pasar de authldap y utilizar authexternal. Nosotros en GULiC hemos querido hacer algo un poco especial y al final tuvimos que dejar de utilizar authldap. Ahora mismo utilizamos authexternal, el cual se configura con un script que será invocado para autenticar a los usuarios. Dentro del script (que se puede programar en el lenguaje que tu quieras) puedes implementar la autenticación como prefieras. Por ejemplo, nuestro script se conecta al LDAP y autentifica a los usuarios por un procedimiento distinto al que utiliza el ejabberd con auth_ldap.

Sobre la clave de usuario, el procedimiento de autenticación del ejabberd es el siguiente:

1. Se conecta, se busca al usuario (por ejemplo, el que tiene uid=pepe) y se obtiene el DN.
2. Ejabberd intenta conectarse el ldap con el DN encontrado y la password de usuario.

Eso significa que la password debe estar almacenada en userPassword.

Saludos

—
May the Free Software Force be with you…

Gracias aplatanado!

Es la primera vez que me meto en GuLiC y la verdad es que es un lujo, y mas siendo canarios Cuando tenga el manual completo de mi servidor de correo/IM, si queréis os lo paso, y asi “vamos construyendo”

Sobre lo que comentas, creo que me voy a decantar, de momento, por la opcion 1) configurando un virtual host por dominio. Sobre esto se me antojan unas preguntillas:

1) Entonces tengo que poner una configuración de LDAP, indepiente para cada dominio servido?

{authmethod, ldap}.
{ldapservers, [“miip”]}.
{ldapuidattr, “mail”}.
{ldapuidattrformat, “%u@dominio1.com”}.
{ldapbase, “ou=usuarios,dc=dominioprincipal,dc=com”}.
{ldaprootdn, “cn=admin,dc=dominioprincipal,dc=com”}.
{ldap_password, “miclavedeldap”}.
¿Eso se puede poner por separado para cada dominio, verdad?

2) Las claves se almacenan en userPassword, pero no es el userPassword del core.schema, sino el del authldap.schema, que es el que se consulta para el correo. ¿Sabrá encontrarlo sin especificarlo en ningún lado?

3) Los usuarios de un virtualhost se podrán ver en el roaster de los usuarios de otro virtualhost? Hay alguna manera de poner eso de manera estática, para que el administrador decida que usuarios aparecen en el roaster de los demás?

4) Cuando he usado la autenticación “internal” tengo que registrar a cada usuario manualmente, o bien con ejabberdctl, o bien con un cliente, tipo Psi, cocinella, etc.
Habría alguna forma de que ya estén registrados los usuarios de correo (del LDAP), sin además tener que registrarlos en el Jabber? Si no se puede se me ocurre que en el script que da de alta a los usuarios añadir una línea cpm ejabberdctl que de de alta dicho usuario.

Como me salga bien el servidor, os paso un manual de configuración paso a paso… del “producto” que estoy configurando, al que he llamado Merkurio 1.0

Un saludillo y gracias nuevamente.

Melo

1) Entonces tengo que poner una configuración de LDAP, indepiente para cada dominio servido?

Si. Las opciones para configurar el ldap se pueden poner dentro de la configuración de cada servidor.

Sería algo así:

{host_config, "dominio.com",
 [
  {auth_method, ldap},
  {ldap_servers, [“miip”]},
  {ldap_uidattr, “mail”},
  ...
  {modules,
   [
   ...

para cada servidor virtual.

2) Las claves se almacenan en userPassword…

Lo encontrará perfectamente. El ldap busca el atributo userPassword por el nombre, independientemente del esquema del que venga.

3) Los usuarios de un virtualhost se podrán ver en el roaster…

Cualquier usuario podrá añadir a su roster a los de otro virtualhost. Si lo que quieres es que los usuarios tengan un roster preconfigurado por el admin con una lista de personas ya suscritas, tendrás que mirar el módulo modshareroster.

4) Cuando he usado la autenticación “internal”

Con el ldap no hace falta registrar a los usuarios en jabber. Desde el momento que tengan una entrada en el ldap podrán conectarse al servidor jabber sin que el admin tenga que hacer nada.

Lo del manual estaría muy bien para colgarlo por aquí y que así otros puedan consultar esa información.

Un saludo.

—
May the Free Software Force be with you…

Gracias de nuevo.

En cuanto tenga un hueco lo pruebo, y te comento.
Lo malo de todo esto es que en los logs no deja nada…solo pone “legacy autenticacion failed” o algo asi… pero bueno, ya os cuento.

Por cierto, tengo la sospecha de que el modulo shared_roster no esta soportado para LDAP, creo haberlo leido no sé donde…

Un saludo

No. El mod_shared_roster almacena los grupos en la bd de ejabberd, por lo que no tiene nada que ver con el LDAP. Se configura desde la interfaz web.

Lo que no está soportado en la versión que tu tienes es el mod_shared_roster_ldap, que toma los grupos de usuarios que comparten roster del ldap. Sin embargo, en GULiC si lo usamos porque nos hemos bajado el código fuente del módulo y lo hemos compilado. Así que es perfectamente posible utilizarlo.

Saludos.

—
May the Free Software Force be with you…

Hola de nuevo.

He conseguido autenticar los usuarios de uno de los dominios contra el LDAP, aunque para ello he tenido que añadirle un ldap_filter
, pero gracias por la idea inspirada que me diste de una config por dominio

La cosa quedo tal que asi:

%% Hostname
{hosts, [“dominioprincipal.com”]}.
{hostconfig, “dominioprincipal.com”, [{authmethod, ldap},
{ldapservers, [“localhost”]},
{ldapport, 389},
{ldapuidattr, “mail”},
{ldapuidattrformat, “%u@dominioprincipal.com”},
{ldapbase, “ou=usuarios,dc=dominioprincipal,dc=com”},
{ldapfilter, “(&(!(quota=-1))(objectClass=CourierMailAccount))”},
{ldaprootdn, “”},
{ldap_password, “”}]}.

Nota: Los buzones que tienen quota -1 están deshabilitados, asi que tampoco chatean )

Ahora queda meterle el resto de los dominios, pero ya es muy tarde y lo dejaré para mañana

Curiosamente el único cliente que me ha funcionado es el jwchat, no me funcionó ni el Psi, ni el Cocinella… De todas formas yo sólo quería ponerle un cliente web, asi que ni me preocupo de los demás

Lo que veo en el jwchat es que solo puedo meter el usuario, pero no el JID completo en el login… Intuyo que para que los usuarios de los otros dominios tengan su cliente jwchat, tengo que crearme un virtualhost separado con una “instancia” de jwchat con su propia configuración para cada virtualhost… ¿Me equivoco? Ello no impedirá supongo que puedan agregar a los usuarios de los otros dominios en su roster…no?

Otra cosa que veo es que con la autenticación LDAP, tal como la tengo, no puedo ponerle, por ejemplo un nick (y otros datos de contacto), ya que la info LDAP que tengo no tiene esos campos.. tendría que modificar el objectclass CourierMailAccount… pero en esta version del “producto” … paso

Un saludo

Melo

Curiosamente el único cliente que me ha funcionado es el jwchat, no me funcionó ni el Psi, ni el Cocinella… De todas formas yo sólo quería ponerle un cliente web, asi que ni me preocupo de los demás

Seguramente el problema sea que no le has dicho a esos clientes que utilicen la autenticación en plano. Con LDAP no vale otro tipo de autenticación.

Lo que veo en el jwchat es que solo puedo meter el usuario, pero no el JID completo en el login

En jwchat se el nombre y el servidor se ponen en sitios separados. El nuestro está configurado de forma que pone Server y al lado una lista desplegable con los dominios soportados. Debajo pone Username, y es donde los usuarios ponen su nombre de usuario. Por tanto, no necesitas un virtualhost para cada dominio.

https://jabber.gulic.org/

CourierMailAccount es un objectClass que se denomina de tipo auxiliar. En una misma entrada se pueden poner varios auxiliares y uno estructural. Por ejemplo sería interesante que los usuarios también tuvieran la clase inetOrgPerson (y todas de las que hereda) para que puedas poner la información personal.

Si lo haces puedes activar el JUD de Jabber (modvcardldap) (sólo necesitas uno para todos los virtuahost). Esto permite que unos usuarios se busquen a otros y puedan mirar su información personal.

Saludos

—
May the Free Software Force be with you…

Gracias… vayamos por partes.

Primero voy a optimizar lo de los diferentes dominios, voy a intentar eso del menu desplegable, y despues miraré si puedo optimizar lo de los vcard…

Oye, muchas gracias por toda la ayuda que me estas prestando.

Ya le he metido un nuevo dominio… pero…
Como configuro el jwchat para que salga ese menu desplegable con todos los dominios?
Un saludo

Creo que nosotros sólo pusimos

servers_allowed:['gulic.org', 'jabber.gulic.org']

en config.js

—
May the Free Software Force be with you…

Funciona así, perfecto.

Ahora tengo que jugar un poco con el jwchat. A ver si puedo modificarle un poco la página de bienvenida para personalizarla un poco.

Y más tarde probaré a añadirle la nueva clase a los usuarios a ver si puedo integrar el vcard tambien en LDAP, de esta forma quedará tdo de puta madre y muy compacto.

En una versión posterior (muy posterior) voy a intentar agregarle el OpenXChange, y autenticar contra el Active Directory de la empresa para la que vaya el bicho… pero eso ya será otra historia……..

Ahora voy a trabajar un poco (en mi trabajo real, el remunerado) jeje, que llevo toda la mañana liado con Merkurio

Un saludo