[Samba] Authentication Auditing

[Arthur Ramsey]

I forgot to share my settings.

# samba-tool domain passwordsettings show
Password informations for domain 'DC=mediture,DC=dom'

Password complexity: on
Store plaintext passwords: off
Password history length: 6
Minimum password length: 7
Minimum password age (days): 1
Maximum password age (days): 90
Account lockout duration (mins): 5
Account lockout threshold (attempts): 20
Reset account lockout after (mins): 5

Thanks,
Arthur

On 10/05/2016 11:32 AM, Arthur Ramsey wrote:
> Hello,
>
> I believe there may be a bug with accounts getting erroneously locked 
> in v4.4.5+.  I've checked at all the Internet facing services to find 
> the source of account lockout and I've done packet captures at the 
> DCs, but I cannot find the source of lockout.  I've got several 
> accounts locking out for seemingly no reason including some service 
> accounts where the passwords aren't user entered.  I've got the 
> lockout threshold set pretty high, 20, so users typing in a bad 
> password isn't too realistic.  I has happened even to my own account.  
> Without auditing I'm not sure how to prove this is a bug.  Is anyone 
> else on this list seeing mysterious locking on v4.4.5+?
>
> Thanks,
> Arthur
>
> On 07/13/2016 12:08 PM, Jeremy Allison wrote:
>> On Tue, Jul 12, 2016 at 11:07:04PM -0500, Arthur Ramsey wrote:
>>> Hello,
>>>
>>> I'm looking for a way to log the following attributes for all
>>> authentication activity (LDAP bind, Kerberos, SMB / CIFS, etc.).
>>>
>>> I would like to see:
>>>
>>>   * Principle name (user name)
>>>   * Source IP
>>>   * Timestamp (including at least seconds if not milliseconds)
>>>   * Authentication result (success / failure)
>>>   * Reason for failure: bad password, account lockout, account expired,
>>>     password expired, etc.
>>>
>>> I believe vfs_full_audit can take care of CIFS activity (without
>>> failure reason?).  The samba logs at level >= 3 show Kerberos
>>> authentication result, principle name, timestamp and reason for
>>> failure, but not source IP.  I cannot find any way to monitor LDAP
>>> bind, which is the most important in my case.  Though I doubt I'm
>>> alone: LDAP authentication seems to be the most popular choice for
>>> integrating with Active Directory, but esp. with Samba domain
>>> controller.
>>>
>>> I cannot connect with Event Viewer as documentation suggests I can.
>>> I get an error, "The procedure number is out of range(1745)". No
>>> corresponds errors observed at server side.
>>>
>>> I searched man pages, wiki and mailing lists, but didn't find any 
>>> solution.
>>>
>>> Certainly a lack of auditing ability is a significant barrier to
>>> enterprise adoption of Samba based domain controllers?
>> +1 on this. IMHO the correct way to implement this is to
>> log events into the eventlog tdb, and then provide tools
>> to access/audit.
>>
>> Inside smbd we have the eventlog API:
>>
>> source3/lib/eventlog/eventlog.c
>>
>> public definitions here:
>>
>> source3/lib/eventlog/proto.h
>>
>> We need to define the events we want to log, and
>> then add the API's to add them to the eventlog.
>>
>> We need to move the above implementation to the
>> top level so it's callable by the samba and smbd
>> binaries.
>>
>> At this point we can start implementing the
>> AUDIT ACE's in smbd to log access on a per-object
>> basis.
>>
>> tdb is 32-bit only, so this may be too small
>> for a large domain. If we hide the logging behind
>> APIs we can move to a more scalable backend
>> later.
>>
>> I'm not sure how to ensure the samba rpc server
>> exports the remote event log RPC's in the same
>> way that smbd currently does, I'm going to
>> have to look into that.
>>
>> This would make an excellent Google Summer of Code
>> project IMHO. It's going to take a little while
>> to get there, but I think this is the right way
>> to do things.
>>
>> Cheers,
>>
>>     Jeremy.
>

This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the Mediture Privacy Officer at privacyofficer at mediture.com.