Toujours en vue de la migration de mon système de messagerie vers Blue Mind, je ne parviens pas à forcer l’authentification de mes utilisateurs via un login simple, sans le @nomdedomaine.fr.
Il me semble avoir pourtant joué avec les bonnes options du main.cf
y’a t’il un petit truc particulier en base ou autre propre à BM ?
Il est tout à fait possible que j’ai oublié de jouer avec un fichier de conf cyrus ou postfix.
Ma question sur le forum BM est plus dans le sens: est ce qu’un paramètre de Blue Mind (en base ou fichier de conf) fait qu’une authentification par login simple (sans domaine), ne fonctionne pas ?
Oui, je me suis mal exprimé, mais c’était le sens de ma question.
Il ne va pas être possible de s’authentifier sans indiquer la partie @domain.tld. Blue Mind est multi-domaine et il est nécessaire d’indiquer le domaine lors de l’authentification.
Il est possible d’indiquer un domaine par défaut dans le fichier /etc/bm/bm.ini, via la directive default-domain=domain.tld, mais ceci ne sera qu’une “aide” à la saisie dans le formulaire d’authentification (ce qui sera réellement envoyé au serveur aura la forme login@domain.tld si ce qui est saisie dans le formulaire est de la forme login).
Ça ne s’appliquera pas au niveau de l’authentification SMTP, ou il sera toujours nécessaire d’indiquer login@domain.tld.
C’est vraiment très pénalisant pour moi. il n’y a vraiment aucun moyen de contourner cette façon de faire ?
En analysant les logs de /var/log/bm/core.log lorsque je tente de me connecter avec mon utilisateur, BM retrouve bien mon utilisateur dans l’annuaire ldap et semble bien accepter loe couple login/mot de passe, mais ensuite, il tente de concaténer mon user avec le domaine global.virt et refuse alors la connection:
2013-12-16 13:28:49,947 o.a.d.l.c.a.LdapNetworkConnection INFO - There is no future associated with the messageId 2, ignoring the message
2013-12-16 13:28:49,953 n.b.s.l.i.h.ImportLdapAuthenticationService INFO - Found: cn=Alexandre MAGNAT,ou=Users,o=Mecaprotec,dc=mecaprotec,dc=fr, searched for extId ‘f1e11b6a-f5f1-1032-9880-07a6e8dc93a8’, u: amagnat@domain#2. bmSearch: 1ms, ldapSearch: 7ms.
2013-12-16 13:28:49,955 n.b.c.s.a.i.AuthenticationRegistry INFO - Validate password using service net.bluemind.system.ldap.importation.hooks.ImportLdapAuthenticationService: YES in 12ms.
2013-12-16 13:28:49,978 n.b.c.s.NginxAuthHttpServlet INFO - [amagnat] will use cyrus backend 172.16.1.229, done in 40ms.
2013-12-16 13:28:49,982 n.b.c.s.a.i.AuthenticationRegistry INFO - Validate password using service net.bluemind.core.server.auth.impl.DatabaseAuthenticationService: NO in 0ms.
2013-12-16 13:28:49,982 n.b.c.UserManagement INFO - UserManagement.validate: access refused to login: ‘amagnat’ domain: ‘global.virt’, auth type: BM DB
2013-12-16 13:28:49,983 n.b.c.s.SyncServlet INFO - handler responded to login/validate in 2ms.
Il suffirait juste qu’il tente de concaténer avec mon domaine par défaut mecaprotec.fr …
Ce n’est pas si simple, il y a d’autres implications. Blue Mind est multi-domaine, il est possible de mettre en place des aides à la saisie/configuration, mais la notion de domaine est nécessaire.
Sur quels aspects est-ce “très pénalisant” ?
Comment arrivez-vous dans cette situation, vous avez activé la directive default-domain=domain.tld ? Vous vous authentifiez sur le formulaire ou au niveau SMTP ?
C’est très pénalisant en vue de la migration du système de messagerie actuel (postfix/cyrus) vers Blue Mind. Actuellement, les utilisateurs de ma société s’authentifient (avec un client loues type Outlook ou Thunderbird) avec un couple login/mot de passe, sans le @domain.tld
Pour migrer de façon transparente, j’ai besoin de pouvoir reproduire le même schéma d’authentification.
Comment arrivez-vous dans cette situation, vous avez activé la directive default-domain=domain.tld ? Vous vous authentifiez sur le formulaire ou au niveau SMTP ?
Qu’avez-vous ajouté au niveau postfix ?
Pardon, j’ai oublié de répondre à un bout du post.
J’ai effectivement joué avec la directive default-domain mais celle ci ne rajoute le “@domain.tld” que sur le formulaire d’accès du webmail. Je l’ai désactivé pour le moment.
Je fais mes tests depuis un client thunderbird configuré en imap/smtp classique mais également depuis le webmail.
J’ai modifié les valeurs de postfix smtpd_sasl_local_domain ainsi que "defaultdomain: " de /etc/imapd.conf mais sans succès.
Ça ne pourra pas fonctionner si simplement, même si vous passez l’authentification, cyrus ne trouvera pas la BAL de toto, car les BAL sont de la forme toto@domain.tld.
Il faudrait chercher du côté de la reconfiguration automatique des clients. Ce cas nécessite d’être étudié, mais il doit-être possible de faire quelque chose.
Quel(s) client(s) lourd(s) utilisez-vous ?
Pour le moment, les utilisateurs sont sous Outlook, mais l’idée est de les migrer sous Thunderbird. J’ai déjà préparer la partie configuration automatique des clients thunderbird (qui se fait à la volée via un script php et un annuaire ldap.)
Je voulais faire une migration par étape, cad, migrer mon serveur de messagerie d’abord, puis migrer les clients mail de mes users ensuite…
Au cas où quelqu’un d’autres chercherait à faire la même chose, j’ai réussi à me dépatouiller de tout ça en jouant avec les headers. L’équipe BlueMind utilise Nginx comme proxy d’authentification au niveau pop/imap. j’ai donc joué avec le proxy pour modifier, ou pas, à la volée, la variable Auth-User en y rajoutant ou pas, le nom de domaine par défaut.
Au niveau smtp, c’est de l’authentification Posftix/ sasl classique, donc j’ai ajouté smtpd_sasl_local_domain = domain.tld dans /etc/postfix/main.cf
ça me permet donc, le temps de la migration de serveur, de conserver un même type d’authentification pour migrer de façon quasi transparente mes users.