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 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.

 
ldap_authentication.txt · Last modified: 2007/01/18 11:01 (external edit)
 
DBMail is developed by Paul J Stevens together with developers world-wide