Virtualdomains and LDAP
in [Postfix]
|
From: Patrick Ben Koetter on 24 Jul 2010 11:49 * Pavel Dimow <paveldimow(a)gmail.com>: > if postfix append the "primary" domain value then it's quite ok with me, I > guess it's not a performance penalty for postfix? I have never measured and I believe it is not worth doing so. The performance penalty should be negligible. > I can then use auth_default_realm in dovecot and problem should be solved. All roads lead to Rome. ;) p(a)rick > > On Sat, Jul 24, 2010 at 2:38 PM, Patrick Ben Koetter <p(a)state-of-mind.de> wrote: > > * Pavel Dimow <paveldimow(a)gmail.com>: > >> Hello, > >> > >> > >> I know that this is maybe question for more LDAP oriented users, but I hope > >> someone here can help me. I have a postfix with one "primary" domain and > >> dozen virtual domains. The problem is that users from primary domain use only > >> their username (without domain part) for SASL authentication and all > >> other users > >> (from virtual domains) are using username(a)somedomain as username. > >> Now my DIT is organized something like > >> > >> ou=people,o=somedomain.com,dc=acmecorp > >> ou=people,o=virtualdomain.com,dc=acmecorp > >> > >> > >> The question is how can I perform a search for a "primary" domain when I don't > >> have a domain part? Is there anyway that I can "append" a default domain when > >> %d is empty or I can make some sophisticated filter_search? > > > > You can create a search filter that only searches for the localpart. But what > > if you have identical localparts in your local and your virtual domains and > > your search finds the localpart in > > "ou=people,o=virtualdomain.com,dc=acmecorp" first (first match wins)? You > > would have to create two separate searches and evaluate the local one first. > > > > It is probably better and more failsafe configuring Postfix to append a domain > > value if a client didn't send one like this: > > > > smtpd_sasl_local_domain = somedomain.com > > > > This way any search will only take place in > > "ou=people,o=somedomain.com,dc=acmecorp". This puts the burden to provide FQDN > > usernames to virtual users, but they should already know and nad have > > configured their systems apropriately. > > > > p(a)rick > > > > -- > > All technical questions asked privately will be automatically answered on the > > list and archived for public access unless privacy is explicitely required and > > justified. > > > > saslfinger (debugging SMTP AUTH): > > <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/> > > -- All technical questions asked privately will be automatically answered on the list and archived for public access unless privacy is explicitely required and justified. saslfinger (debugging SMTP AUTH): <http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
From: Victoriano Giralt on 26 Jul 2010 08:24
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/24/2010 02:52 PM, Pavel Dimow wrote: > Hi Victoriano, Hi Pavel. > are those searches in LDAP slower? I have made no measures but LDAP indexes are made so the translate attribute values into DNs, so, if you index your DIT properly, speed differences should be negligible if at all existant. > For example, is it much slower when you start search at > dc=acmecorp instead of ou=people,o=somedomain.com,dc=acmecorp ? Should not. - -- Victoriano Giralt Systems Manager Central ICT Services University of Malaga SPAIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org/ iD8DBQFMTX5jV6+mDjj1PTgRAkyHAJ45kA/tbg6ito6HKwqw5wd3DlJKOACgngLY eoJw6V59dB/JLlFZt18Tjao= =bAMI -----END PGP SIGNATURE----- |