s3-passdb: Try to unlock the account if it is locked out
abartlet at samba.org
Wed Sep 1 16:53:53 MDT 2010
On Wed, 2010-09-01 at 10:01 +0200, Andreas Schneider wrote:
> On Tuesday 31 August 2010 23:03:38 Andrew Bartlett wrote:
> > On Tue, 2010-08-31 at 11:16 -0400, Jim McDonough wrote:
> > > On Mon, Aug 30, 2010 at 10:44 AM, Simo Sorce <idra at samba.org> wrote:
> > > > The branch, master has been updated
> > > >
> > > > via 20e7b4e s3-auth: The unlock of the account is now done by
> > > > the get_sampwnam call. via c5cfad1 s3-passdb: Try to unlock the
> > > > account if it is locked out. via 2ab0b63 s3-passdb: Added a
> > > > pdb_try_account_unlock function. via 9dd7e7f s3-auth: Use
> > > > SamInfo3_for_guest to create guest server_info.
> > > >
> > > > from 5f419ea packaging: Build with -O3
> > >
> > > The account locking code is hereby yours!!!
> > >
> > > /me runs and hides from bmarsh
> > I'm a little worried by these changes, because we only just finished
> > removing the magic from passdb that did unexpected things behind
> > ordinary-looking interfaces. (That is, the calls out to sid_to_gid() in
> > the set_primary_group_id() wrapper.)
> > Is it really the best idea for a read operation 'get_smbpwnam()' to make
> > write calls to the database?
> I've researched this on a Windows 2008 Server. You can login to the system
> again after the lockout duration which means netr_LogonSamLogon is unlocking
> the account. But a samr_QueryUserInfo doing the same, as Administrator or as
> diffent user. I've first implemented it in the samr_OpenUser call, but then it
> is possible that there are more functions.
I don't see how this implies that the query or login calls should do
write operations - if you read over AD's LDAP, are the values similarly
updated? Should LDAP search operations also do writes if we matched or
harmonised this code with Samba4?
> Microsoft doesn't document this in the samr or netlogon function and I don't
> think that they have implemented it there. It is for sure deeper in the code
> which would be passdb in Samba. That's the reason I've implemented it there.
I think there is another approach, which would not change the database
on read operations and explain why you don't see this documented.
Instead of 'trying to unlock' the account on read operations, the read
should simply return the calculated value of the ACB flags and
ACB_AUTOLOCK if the account is locked (based on the same criteria that
you use the 'unlock' the account automatically).
The login code can then read this calculated value. You will notice if
you play with SAMR that other bit that seem to be calculated in the SAMR
server and AD LDAP server - that is, they cannot be unset, even by the
I know this seems like a subtle distinction, but considering the Samba
can be backed by read-only LDAP servers (which then require us to chase
referrals back to writable servers for each modification), I think we
should avoid doing writes to update such calculated values.
BTW, A good way to tell if Windows is updating it's data store, or if
the value is calculated, is to watch the replication traffic.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part
More information about the samba-technical