Re: Contribution: Active Directory Password Cache (ITS#5042)

[ando@sys-net.it]

s.hetze@linux-ag.de wrote:

> I don't see the benefit of delegating the password cache mechanism to
> saslauthd or a possible replacement. Wouldn't I have to implement each
> possible password store anyway?

> If I understand it correct, the {SASL} userPassword mechanism delegates
> authentication to saslauthd.
> saslauthd can easily authenticate against Kerberos and AD and it is
> possible let it cache the password for its own authentication purposes.
> If I want the sambaNTPassword attribute to be available (to be able to
> run samba as a NT4 PDC independent of AD ) or if I want to have the
> password additionally cached as MIT Kerberos credential, I would need
> to implement both individually one way or another.
> So why not going the short way and let the overlay module do this?


The {SASL} userPassword delegates authentication to SASL; then, by 
configuring SASL to use saslauthd, SASL delegates authentication to 
saslauthd, but it can be delegated to anything else.

I think the point is: you should isolate what your piece of software is 
originally contributing, and what it's "reinventing".  The original 
contribution, as far as I understand, is the capability to cache 
athentication rather than always propagating it.  This capability is not 
currently present in OpenLDAP.  What is already present is the SASL, 
which is an abstraction layer for authentication; think of it as a 
superset of Kerberos, which is the only authentication method you're 
considering in your piece of software.

At this point, it sounds like that your contribution could be 
__entirely__ reworked into simply adding caching capabilities into the 
current {SASL} password scheme (implemented in servers/slapd/sasl.c), 
preserving the logics you're using right now.  You'd probably need to 
define your own "cachedUserPassword" attribute to temporarily store the 
cached credentials, unless something like this:

userPassword: {SASL}user
userPassword: {<hash>}<hashed password>

allows the {SASL} module to fetch the next value of the userPassowrd and 
treat it as the cached value.  The rest would be adding some TTL mech, 
configurable via back-config, and that should be it.

Yet another option would be to allow per-entry caching, by defining a 
new {CACHED-SASL} scheme.  This way, one could fine-grain decide whose 
credentials can be cached and whose can't, letting the two cases share 
most of the code.  I'd allow {SASL} to be cached as well, in case the 
administrator just wants to allow all {SASL} auths to be cached.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------