Issue 5042 - Contribution: Active Directory Password Cache
Summary: Contribution: Active Directory Password Cache
Status: VERIFIED SUSPENDED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: contrib (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-12 17:06 UTC by s.hetze@linux-ag.de
Modified: 2020-04-17 16:39 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description s.hetze@linux-ag.de 2007-07-12 17:06:41 UTC
Full_Name: Sebastian Hetze
Version: 2.3.30
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Sebastian-Hetze-pgk-070712.tgz
Submission from: (NULL) (212.21.78.130)


Hi *,

in your FTP incoming you find a piece of software that we would like to
contribute
to the slapd-modules collection.

We hope you find it useful and we would very much like to receive feedback
about
useability, ideas for improvements and (in the very unlikely case of occurance
;-)
bugreports and fixes.


Best regards

  Sebastian Hetze

------------------------------------------------------------------------------------


Active Directory Password Cache
===============================


Active Directory does not provide any means to read user credentials on any
public
API. It is possible, to install additional libraries as password sniffer to
catch and forward cleartext passwords on changes. In case you cannot or simply
dont
want to install such libraries, the Active Directory Password Cache overlay
is your option.

The Active Directory Password Cache overlay allows to mirror user account
credentials without any modification on the AD server. It only takes one
occasional simple bind authentication against the OpenLDAP server.

If the credential has not been mirrored yet, the overlay uses the
krbPrincipalName
and the password provided by the user to perform a Kerberos init against the
Active Directory. A successful Kerberos init guarantees a correct password for
this principal, and therefor the bind finally succeeds.

Within this overlay operation, the password gets encrypted with the default
OpenLDAP hash alorithm and stored as userPassword attribute. There is an option
to update the sambaNTPassword also (using code borrowed from Howard Chu's
smbk5pwd overlay). All following simple bind authentications will first try
these cached credentials, making the OpenLDAP server independent from AD.

In case the user changes its password on the Active Directory server, the old
password stays valid in OpenLDAP until the user first presents the new password
for an simple bind. Within this bind operation, the overlay performs another
Kerberos init and updates the cached credentials in OpenLDAP.

Comment 1 ando@openldap.org 2007-07-12 19:08:06 UTC
moved from Incoming to Contrib
Comment 2 Gavin Henry 2007-07-19 09:49:02 UTC
Hi,

This looks like it is in the correct format for our contrib section. Just
testing is needed. As I don't have access to an Active Directory server I can't
test.

Anyone else?

Gavin.
Comment 3 s.hetze@linux-ag.de 2007-07-30 13:42:40 UTC
Hi Gavin,

I just uploaded a patch for my contribution as
Sebastian-Hetze-070630.patch (sorry for the wrong date)

The adpwc as contributed has a dependency to samba3.schema
to be present, which is fixed with this patch.
The patch also makes adpwc fold realm names to upper case
since AD stores them mixed case and gives tickets upper case.
I introduced a new config option adpw-cache-keep-realm-case
to keep the old behaviour if needed.

It looks like I cannot add this patch to ticket #5042, so
I ask you to attach it if possible.

Thanx alot,

  Sebastian

On Thu, Jul 19, 2007 at 09:48:58AM +0000, Gavin Henry wrote:
> Hi,
> 
> This looks like it is in the correct format for our contrib section. Just
> testing is needed. As I don't have access to an Active Directory server I can't
> test.
> 
> Anyone else?
> 
> Gavin.

-- 
Sebastian Hetze
Mitglied des Vorstands
Linux Information Systems AG
Ehrenbergstr. 19, D-10245 Berlin

Fon: +49 30 726238-0, Fax: +49 30 726238-99
s.hetze@linux-ag.com, http://www.linux-ag.com
----------------------------------------------------------
Sitz der Gesellschaft: Stefan-George-Ring 8, 81929 München
Amtsgericht München: HRB 128 019
Vorstand: Rudolf Strobl, Sebastian Hetze
Aufsichtsrat: Michael Tarabochia (Vorsitzender)

Comment 4 ando@openldap.org 2007-08-06 19:32:27 UTC
Sebastian,

Thanks for the contribution.

I have a few comments (also gathered from others):

1) you should provide patches against HEAD code; there has been some
limited changes in the API related to overlay initialization and so.

2) you could try to rework the overlay to avoid any specific reference
to Active Directory, since your cache should apply to any remote system
implementing Kerberos V.  It could be abstracted even more, to act as a
replacement of saslauthd, by allowing it to auth via LDAP, pam and more,
not just Kerberos.

3) you should add a (configurable) TTL, so that the cache could
eventually be notified of an account lockout at the remote server's side.

4) you should add support for dynamic configuration, so that the module
can fit into the new configuration paradigm for possible release with 2.4.

5) you should follow coding guidelines (indentation and so) as in most
of the code.

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


Comment 5 Kurt Zeilenga 2007-08-06 19:55:11 UTC
On Aug 6, 2007, at 7:31 PM, ando@sys-net.it wrote:

> Sebastian,
>
> Thanks for the contribution.
>
> I have a few comments (also gathered from others):
>
> 1) you should provide patches against HEAD code; there has been some
> limited changes in the API related to overlay initialization and so.
>
> 2) you could try to rework the overlay to avoid any specific reference
> to Active Directory, since your cache should apply to any remote  
> system
> implementing Kerberos V.  It could be abstracted even more, to act  
> as a
> replacement of saslauthd, by allowing it to auth via LDAP, pam and  
> more,
> not just Kerberos.

s/to act as a replacement/to defer external authentication to saslauthd
or the like/

In slapd(8), we deferred verification against external password  
stores to saslauthd
via the {SASL} userPassword mechanism, thus avoiding needing to  
implement
and support each possible external password store (such as a KDC).   
This module
should likewise avoid supporting (some subset of) external passwords  
stores.
saslauthd(8) can easily be extended (or replaced) to support additional
password stores as needed.  As provided in Cyrus SASL today, it  
supports both
LDAP and Kerberos as external password stores.

>
> 3) you should add a (configurable) TTL, so that the cache could
> eventually be notified of an account lockout at the remote server's  
> side.
>
> 4) you should add support for dynamic configuration, so that the  
> module
> can fit into the new configuration paradigm for possible release  
> with 2.4.
>
> 5) you should follow coding guidelines (indentation and so) as in most
> of the code.
>
> p.

Comment 6 s.hetze@linux-ag.de 2007-08-07 09:13:15 UTC
Hi Pierangelo,

thanx for your comments.

On Mon, Aug 06, 2007 at 09:32:27PM +0200, Pierangelo Masarati wrote:
> Sebastian,
> 
> Thanks for the contribution.
> 
> I have a few comments (also gathered from others):
> 
> 1) you should provide patches against HEAD code; there has been some
> limited changes in the API related to overlay initialization and so.

No problem, I will look into that shortly.

> 
> 2) you could try to rework the overlay to avoid any specific reference
> to Active Directory, since your cache should apply to any remote system
> implementing Kerberos V.  It could be abstracted even more, to act as a
> replacement of saslauthd, by allowing it to auth via LDAP, pam and more,
> not just Kerberos.

Actually, the software was built and tested agains MIT and Heimdal
Kerberos V in the first place, so there is no dependency on AD
whatsoever. The reference to AD is more a marketing issue. I assume
more users looking for an AD password cache than for an Kerberos V
password cache. So I would perfer to keep it.

> 
> 3) you should add a (configurable) TTL, so that the cache could
> eventually be notified of an account lockout at the remote server's side.

I tried to avoid introduction of new attributes for the module. Do you
have any suggestions how this TTL should be stored? Adding pwdPolicy
from ppolicy seems a bit like an overkill to me.

> 
> 4) you should add support for dynamic configuration, so that the module
> can fit into the new configuration paradigm for possible release with 2.4.

I'll look into that.

> 
> 5) you should follow coding guidelines (indentation and so) as in most
> of the code.

I did not find any guidelines other than "Adapt your style to match that
of the block, file, directory, or package that you are working in."
Can you point me to a more detailed explanation of the required
indentation?


Regards,

  Sebastian

Comment 7 ando@openldap.org 2007-08-07 09:41:58 UTC
s.hetze@linux-ag.de wrote:

>> 2) you could try to rework the overlay to avoid any specific reference
>> to Active Directory, since your cache should apply to any remote system
>> implementing Kerberos V.  It could be abstracted even more, to act as a
>> replacement of saslauthd, by allowing it to auth via LDAP, pam and more,
>> not just Kerberos.
> 
> Actually, the software was built and tested agains MIT and Heimdal
> Kerberos V in the first place, so there is no dependency on AD
> whatsoever. The reference to AD is more a marketing issue. I assume
> more users looking for an AD password cache than for an Kerberos V
> password cache. So I would perfer to keep it.

I understand this, and I think it's just fine to advertise it like that, 
but in the code I'd prefer to avoid, for example, naming all variables 
after "ad" something.  Perhaps s/adpwc/extpwc/ would be a little bit better?

>> 3) you should add a (configurable) TTL, so that the cache could
>> eventually be notified of an account lockout at the remote server's side.
> 
> I tried to avoid introduction of new attributes for the module. Do you
> have any suggestions how this TTL should be stored? Adding pwdPolicy
> from ppolicy seems a bit like an overkill to me.

Well, that could be a parameter that is provided through the 
configuration (caching TTL, optional negative caching TTL, and so).  It 
doesn't need to be stored in the entry, or in a subentry, since dynamic 
configuration would allow to modify it run-time anyway.

>> 4) you should add support for dynamic configuration, so that the module
>> can fit into the new configuration paradigm for possible release with 2.4.
> 
> I'll look into that.

If you need help, please holler.  However, I see that for such a simple 
(from a configuration point of view) module, looking into smbk5pwd 
should suffice.

>> 5) you should follow coding guidelines (indentation and so) as in most
>> of the code.
> 
> I did not find any guidelines other than "Adapt your style to match that
> of the block, file, directory, or package that you are working in."
> Can you point me to a more detailed explanation of the required
> indentation?

There isn't actually, but looking into any "recent" piece of code would 
suffice; things like: use tabs for indent, leave spaces in brackets and 
so... not a big deal, though.

Cheers, 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
---------------------------------------


Comment 8 s.hetze@linux-ag.de 2007-08-07 09:57:18 UTC
Hi Kurt,

On Mon, Aug 06, 2007 at 12:55:11PM -0700, Kurt Zeilenga wrote:
> >2) you could try to rework the overlay to avoid any specific reference
> >to Active Directory, since your cache should apply to any remote  
> >system
> >implementing Kerberos V.  It could be abstracted even more, to act  
> >as a
> >replacement of saslauthd, by allowing it to auth via LDAP, pam and  
> >more,
> >not just Kerberos.
> 
> s/to act as a replacement/to defer external authentication to saslauthd
> or the like/
> 
> In slapd(8), we deferred verification against external password  
> stores to saslauthd
> via the {SASL} userPassword mechanism, thus avoiding needing to  
> implement
> and support each possible external password store (such as a KDC).   
> This module
> should likewise avoid supporting (some subset of) external passwords  
> stores.
> saslauthd(8) can easily be extended (or replaced) to support additional
> password stores as needed.  As provided in Cyrus SASL today, it  
> supports both
> LDAP and Kerberos as external password stores.
> 

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?


Regards,

  Sebastian

Comment 9 s.hetze@linux-ag.de 2007-08-07 10:29:32 UTC
Hi Pierangelo,


On Tue, Aug 07, 2007 at 11:41:58AM +0200, Pierangelo Masarati wrote:
> s.hetze@linux-ag.de wrote:
> 
> >>2) you could try to rework the overlay to avoid any specific reference
> >>to Active Directory, since your cache should apply to any remote system
> >>implementing Kerberos V.  It could be abstracted even more, to act as a
> >>replacement of saslauthd, by allowing it to auth via LDAP, pam and more,
> >>not just Kerberos.
> >
> >Actually, the software was built and tested agains MIT and Heimdal
> >Kerberos V in the first place, so there is no dependency on AD
> >whatsoever. The reference to AD is more a marketing issue. I assume
> >more users looking for an AD password cache than for an Kerberos V
> >password cache. So I would perfer to keep it.
> 
> I understand this, and I think it's just fine to advertise it like that, 
> but in the code I'd prefer to avoid, for example, naming all variables 
> after "ad" something.  Perhaps s/adpwc/extpwc/ would be a little bit better?

Renaming the variables is no problem. What would you say extpwc stands
for? I can imagine to call the module krb5pwc and head the README
"Kerberos V/Active Directory Password Cache"

> 
> >>3) you should add a (configurable) TTL, so that the cache could
> >>eventually be notified of an account lockout at the remote server's side.
> >
> >I tried to avoid introduction of new attributes for the module. Do you
> >have any suggestions how this TTL should be stored? Adding pwdPolicy
> >from ppolicy seems a bit like an overkill to me.
> 
> Well, that could be a parameter that is provided through the 
> configuration (caching TTL, optional negative caching TTL, and so).  It 
> doesn't need to be stored in the entry, or in a subentry, since dynamic 
> configuration would allow to modify it run-time anyway.
> 

If I understand it correct, you suggest to let the cached password
expire after some configurable time. To achieve this, I would need to
keep a timestamp when the password was cached.
Is there any other way than to add an attribute holding this timestamp?
...
Actually, I could make this feature depend on the {ad|krb5}pw-cache-mode=any
and use the sambaPwdLastSet attribute.

> >>4) you should add support for dynamic configuration, so that the module
> >>can fit into the new configuration paradigm for possible release with 2.4.
> >
> >I'll look into that.
> 
> If you need help, please holler.  However, I see that for such a simple 
> (from a configuration point of view) module, looking into smbk5pwd 
> should suffice.

Thanx for your offer, and I agree to look into the existing overlays
(again ;-)
That's the fun with free software!


Regards,

  Sebastian

Comment 10 ando@openldap.org 2007-08-07 10:32:56 UTC
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
---------------------------------------


Comment 11 ando@openldap.org 2007-08-07 10:49:02 UTC
s.hetze@linux-ag.de wrote:

> Renaming the variables is no problem. What would you say extpwc stands
> for?

EXT ernal P ass W ord C ache?

> I can imagine to call the module krb5pwc and head the README
> "Kerberos V/Active Directory Password Cache"

Right; but, this would limit yourself to Kerberos V; see my other 
posting about rather delegating auth to SASL.

>> Well, that could be a parameter that is provided through the 
>> configuration (caching TTL, optional negative caching TTL, and so).  It 
>> doesn't need to be stored in the entry, or in a subentry, since dynamic 
>> configuration would allow to modify it run-time anyway.
>>
> 
> If I understand it correct, you suggest to let the cached password
> expire after some configurable time. To achieve this, I would need to
> keep a timestamp when the password was cached.
> Is there any other way than to add an attribute holding this timestamp?
> ...
> Actually, I could make this feature depend on the {ad|krb5}pw-cache-mode=any
> and use the sambaPwdLastSet attribute.

Right; I think a specific operational attribute would be better.

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


Comment 12 ando@openldap.org 2007-08-07 11:04:13 UTC
ando@sys-net.it wrote:

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

For this purpose, it might be necessary to change the API of password 
scheme handling, so that it gets passed a pointer to the entire entry, 
read-only locked, so that attributes like the "cachedPwd" and the 
"cachedPwdTimestamp" can be fetched and used.

With respect to updating them, we might need to add some means to 
schedule internal modifications to be performed as soon as the entry 
lock is released.  Thoughts?

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


Comment 13 Kurt Zeilenga 2008-03-04 05:55:04 UTC
changed notes
Comment 14 OpenLDAP project 2014-08-01 21:03:27 UTC
IPR okay
Should not appear to be AD-specific (we market open standards, not AD
compatibility)
Comment 15 Quanah Gibson-Mount 2020-04-17 16:39:05 UTC
suspending, no updates after 13 years to address points made.