LDAP Authentication
Author: Paul Stevens 67ti6i67i
introduction
Ldap support is feature complete. It provides all of the api defined in auth.h. Dbmail-users is fully functional running in ldap mode.
There are some outstanding cleanup issues:
- updating the last_login field in auth_validate
- add run-time configuration switch to dbmail-users
ldap dbmailUser objects
| sql field | dbmail.conf | ldap field |
|---|---|---|
| username | cn_string | uid |
| user_idnr | field_nid | uidNumber |
| client_idnr | field_cid | gidNumber |
| password | field_password | userPassword |
| aliases | field_mail | |
| maxmail_size | field_quota | mailQuota |
sql dbmail_users
The mailstorage database should also hold some user information. It makes sense to copy some user information into the database. The easiest way to do this is by simply calling the code from authsql as we create, update and delete users. At the moment accounts thus managed have their passwords disabled. This means you won't be able to use accounts created as sql shadow accounts later as real accounts after you have switched back to authsql.
There's actually no good reason to keep these sql shadow accounts stripped bare, other than to discourage such switching back and forth. Let's kiss ok. I'm no bofh, really 
Remember the main motivation for keeping such shadow accounts is twofold: scorekeeping aka quota management and data integrity.
At minimum we need:
| user_idnr | curmail_size |
But it seems better to include the userid (uid) as well for clarity sake.
synchronization
In keeping both ldap and sql accounts in sync there's one design problem I haven't fully explored yet, and that is the unique-ness of keys in sql versus the non-uniqueness of ldap fields. The filtering logic of authldap still needs some redesigning. Part of that will entail adding a runtime configuration entry for setting those filters.