[Samba] Authentication Auditing

[Arthur Ramsey]

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.

-- 
Arthur Ramsey
System Administrator
Mediture
arthur_ramsey at mediture.com
952.400.0323


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.