[cifs-protocol] [REG:113103010905266] Behaviour of UF_LOCKOUT compared with UF_PASSWORD_EXPIRED

[Garming Sam]

On 26/11/13 11:12, Edgar Olougouna wrote:
> Thanks for sharing that you have worked this out.
> While we are it, I'd be interested to look at the traces before closing this, just to double-check there is no hidden or unexpected behavior that could result from it.
>
> Thanks,
> Edgar
>
> -----Original Message-----
> From: Andrew Bartlett [mailto:abartlet at samba.org]
> Sent: Sunday, November 24, 2013 10:00 PM
> To: Edgar Olougouna
> Cc: MSSolve Case Email; cifs-protocol at samba.org; garming at catalyst.net.nz
> Subject: Re: [cifs-protocol] [REG:113103010905266] Behaviour of UF_LOCKOUT compared with UF_PASSWORD_EXPIRED
>
> On Thu, 2013-11-21 at 04:12 +0000, Edgar Olougouna wrote:
>> Andrew,
>> Debugging NetrLogonSamLogonEx in a pass-through scenario between Windows with STATUS_ACCOUNT_LOCKED_OUT, I observed that both (account_locked_out, password_expired) bits are set in the routine that computes user account control bits. account_locked_out is set provided we are within lockout duration, otherwise the account and status will not be locked out.
>> In my testing, LogonLevel = NetlogonNetworkTransitiveInformation (0n6) and ValidationLevel = NetlogonValidationSamInfo4 (0n6).
>> Assuming this does not exhibit the behavior you experimented, I would need a debug a TTT trace taken from your repro environment.
>> Would you be able to have some spare cycles and collect repro traces in the near future so we can conclude on this?
> While trying to demonstrate this and set up the TTT trace my colleague Garming and I have worked this one out.  We can still get you traces if you want, but the situation is clearly that:
>   - the ACB_AUTOLOCK bit is computed at the time of the OpenUser, not the QueryUserInfo
>   - therefore my automated tests showed it wasn't set
>   - manual tests showed it was, because in manual tests the user is opened 'fresh' after the lockout is applied!
>
> We confirmed this by changing our tests to re-open the user directly before the query, and the 'bug' went away!
>
> We have got the environment set up to run the TTT if you like, but we are happy to write this one down as 'odd', and fix up our tests to re-open the user.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team  http://samba.org
> Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba
>
>
>
>


Hi,

I've uploaded the traces in the appropriate manner. In the Wireshark 
capture, the packets you'll probably find of interest are 159, 161 and 
166. If you need the actual test script as well, just let us know.

In the test, it opens the user using SAMR, then locks out the user and 
immediately it just queries for the user info flags, which unexpectedly 
comes up as NORMAL. Then it reopens the user and asks for the flags 
again which correctly shows that the AUTOLOCK is present. We also query 
over LDAP and show that the account is locked over LDAP.



Thanks,

Garming Sam