At 10AM +0100 on 14/11/12 you (Marco Gatti) wrote:
2012/11/13 Ben Morrow ben@morrow.me.uk:
At 2PM +0100 on 13/11/12 you (Marco Gatti) wrote: <snip>
I'll try to give more details. I have to build a multiple domain mail server with the use of windows AD authentication. I've managed to add some extra filed in the AD schema like this:
mail1: account1@example1.com box1: /example1.com/account1/ enabled1: TRUE quota1: 1000000
mail2: account2@example2.com box2: /example2.com/account2/ enabled2: TRUE quota2: 1000000
This isn't a good schema to use for this. The mail1, mail2 &c attributes represent the same property of different addresses, so they should be the same attribute on different objects.
I don't know much about AD's LDAP server, is it straightforward to create brand new objectclasses? If I were doing this in an ordinary LDAP server I might create a class of objects which looked like
mailboxAddr: account1@example1.com mailboxLocation: /example1/account1 mailboxEnabled: TRUE mailboxQuota: 1000000with mailboxAddr as the RDN, and then give each user a multi-valued mailbox attribute with the addresses that user has access to.
You mean multi-valued mailboxAddr, mailboxLocation, and so on? How can I extract a single one and be sure it's correct?
No. I mean you want separate objects for the mail accounts, completely distinct from the user objects (under a different branch of the LDAP tree). Each 'mail account' object has one Addr, one Location and so on. Then, each user who should have access to one of these accounts has a multi-valued 'mailbox' attribute pointing to the mail accounts that user can see. Something like (I don't really know how AD schemas work...)
dn: mailboxAddr=account1@example.com,ou=Mailboxes,dc=example,dc=com
mailboxAddr: account1@example.com
mailboxLocation: /example/account1
dn: mailboxAddr=account2@example.com,ou=Mailboxes,dc=example,dc=com
mailboxAddr: account2@example.com
mailboxLocation: /example/account2
dn: sAMAccountName=bob,ou=People,dc=example,dc=com
sAMAccountName: bob
mailbox: account1@example.com
mailbox: account2@example.com
dn: sAMAccountName=bill,ou=People,dc=example,dc=com
sAMAccountName: bill
mailbox: account2@example.comIf your 'mail account' attribute is sometimes called 'mail1' and sometimes called 'mail2' how do you expect to search for it?
There could be 10 or 50 of them for each AD user. If I use NTLM or PAM authentication (after joining the AD) I have to use AD usernames to login with dovecot and I don't know how then to deal with different email addresses configured per user. If I use LDAP lookup I have to use the email address as username but then if different AD users have to access the same email account how dovecot can manage it???
If you want the user to be able to log in and see just one address at a time you have to have the user tell dovecot which user and which address they want when they log in. Since (usually) the only fields you have are 'user' and 'password', they will need to stuff both components into the user field somehow; perhaps by logging on with a user name of
user@domain.ad!account1@example.comYou would then need (probably) to write a checkpassword userdb script to split this into username and account name, verify the user is authorized for the account, look up the mailbox location using the account name, and pass the username back to be checked against the password. So, it could be done, but it would be messy and users would get it wrong all the time.
Since users don't configure mail clients on their own it could be a solution!
If users don't know how to choose which username they are logging in with how will they choose which account they want to look at?
I *think* this is simpler than I thought: I think Dovecot's 'master user' stuff will work for this. You need to set up a master user passdb which looks up %u (or %n) as the AD account name and also checks that that user has a 'mailbox' attribute (whatever you decide to call it) of %{login_user}.
Alternatively, you could have the user log in with their ordinary AD account name, and then present them with *all* the email accounts they have access to, as separate (trees of) folders. <snip> All accounts in a tree sounds bad since users won't clearly understand which is which.
OK, if you say so. ISTM that having a number of top-level folders called (e.g.) 'account1@example.com' with the mail for account1@example.com in is much easier to deal with than magic usernames, but you know your users.
Ben