Hi,
I'm writing to you on behalf of the Pasteur Institute's (Paris,
France) IT team. We're currently using dovecot-0.99.10.5_2 on a
FreeBSD 5.3. We're planning to upgrade to dovecot-1.x with an openLDAP
user and password database and patch it at the same time to include
some authentication feature we're using :
Since most of our user currently don't use dovecot at all and still
authenticate on a DEC alpha running OSF1 [digital unix] V5.1 732, an
authentication profile is maintained for each of them on the system.
This user profile is kept in the protected password database,
accessible only to trusted programs acting on behalf of the trusted
computing base (TCB).
Some TCB fields are useful to us so we're planning to use their LDAP
attibute equivalents and we wrote a custom LDAP shema that includes
those which were missing from the standard openLDAP distribution [see
details below].
So we're planning (in fact are about to) patch dovecot-1.x in order to
take those LDAP attribute (matching the TCB field of interest to us)
into account. To do so, we wrote some documentation (still in a draft
state) to extend our understanding of dovecot architecture and
authentication process.
Of course, we're going to give it (patch + doc) back to you and make
it freely available. But we'd like to know if you :
- were already working on such a patch or planning to do so
- were interested, once done (by us or you) to include it into the
official release, since it could interest some other person who
runs digital unix with TCB authentication
Thanks
--
Thomas Hummel | Institut Pasteur, Paris, France
<hummel at pasteur.fr> | P?le informatique - syst?mes et r?seau
--------
Here are some details about which attribute we're planning to use and
their TCB equivalents
uidNumber ~ u_id
uid ~ u_name
userPassword ~ u_pwd
shadowLastChange ~ u_succhg
shadowExpire ~ u_expdate
shadowMax ~ u_life
shadowWarning ~ u_exp [ shadowWarning = u_life - u_exp]
plus the one we wrote :
maxTries ~ u_maxtries
[ maximum number of consecutive unsuccessful login attempts to the
account that are permitted until the account is disabled ]
numUnsucLog ~ u_numunsuclog
[ number of unsuccessful login attempts to the account. It is reset
when a successful login to the account occurs.]
Lock ~ u_lock
[ A boolean indicating if the account is locked ]
On 7.3.2005, at 12:49, Thomas Hummel wrote:> So we're planning (in fact are about to) patch dovecot-1.x in order to > take those LDAP attribute (matching the TCB field of interest to us) > into account. To do so, we wrote some documentation (still in a draft > state) to extend our understanding of dovecot architecture and > authentication process. > > Of course, we're going to give it (patch + doc) back to you and make > it freely available. But we'd like to know if you : > > - were already working on such a patch or planning to do soI wasn't, and I doubt anyone else was either.> - were interested, once done (by us or you) to include it into the > official release, since it could interest some other person who > runs digital unix with TCB authenticationI'm not sure if I understood this correctly. How does TCB and LDAP fit together? Does TCB simply provide LDAP view for its data? So is your patch only about handling the extra LDAP fields, or is it about providing some completely TCB-specific code (and LDAP being something else)? In any case, if it's entirely TCB-specific I doubt I'd include it in the release, as there would be only a few users for it. I could put it in the web site though and add some pointers in documentation that there are other authentication plugins available as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050308/4c3cf510/attachment-0001.bin>
On Tue, Mar 08, 2005 at 12:03:07AM +0200, Timo Sirainen wrote:> I'm not sure if I understood this correctly. How does TCB and LDAP fit > together? Does TCB simply provide LDAP view for its data? So is your > patch only about handling the extra LDAP fields, or is it about > providing some completely TCB-specific code (and LDAP being something > else)?LDAP and TCB are two different things. We simply want to handle extra LDAP attribute (i.e. in addition of uid, homeDirectory, uidNumber, gidNumber and userPassword) because they are meant to provide the same extra (and valuable) authentication info that the TCB fields did (thus providing a way to know that, for instance, a user user agent has made 20 consecutive attempts to log in with an incorrect password and to lock it's account for that reason). We'll let you know when we're done anyway. Thanks. -- Thomas Hummel | Institut Pasteur <hummel at pasteur.fr> | P?le informatique - syst?mes et r?seau