[PATCH] Updated Add detailed authentication logging for NTLM authentication.

Andrew Bartlett abartlet at samba.org
Thu Mar 2 22:16:46 UTC 2017


On Thu, 2017-03-02 at 12:43 +0100, Stefan Metzmacher wrote:
> Am 02.03.2017 um 04:57 schrieb Andrew Bartlett:
> > On Thu, 2017-03-02 at 16:48 +1300, Gary Lockyer wrote:
> > > Produce detailed authentication logs for NTLM authentication, of
> > > both
> > > successful and unsuccessful attempts.  Patch includes changes to
> > > ensure
> > > that all the required fields are passed through to the logging
> > > routines.
> > > 
> > > Updated to:
> > > 	log successful authorizations
> > > 	log password type for authentications
> > >         replace talloc_steal with talloc_move in
> > >             source4/smbd/service_named_pipe.c
> > > 	separate the auth logging into it's own file
> > > 
> > > 
> > > Subsequent patches will log kerberos authentication and
> > > produce machine parsable json log entries.
> > 
> > Thanks Gary.  We also need to remember password changes!  (The
> > always
> > forgotten attack vector :-)
> 
> I haven't looked very closely, but is some places I had the
> impression
> that a later patch fixes a problem in a former patch.
> In order to understand the flow better, it would be useful to have
> this
> sorted out and every single commit complies and is supposed to
> work without crashing with NULL pointer deferences.

Thanks.  Each commit does compile (we have been using your rebase/x
make -j trick), and they are meant to operate, but we will look again
for any more cases we need to implement. 

> Typically it's better to pass new unused arguments from the top,
> before they get used at the bottom.
> 
> I guess you also need to be prepared that a dcerpc bind negotiates no
> presentation context, it's possible to use a dummy uuid and just
> do the authentication.

Very interesting.  I'll cover that - but what happens in Samba then,
can the user re-use the authentication on another UUID? (it is
important to know this for auditing.)

> We may also want to distinguish between the different LogonSamLogon
> levels (interactive vs. network at least).

A very good idea.  We have an unused parameter that would be ideal for
that. 

> I'm also wondering why the log functions gets the user supplied info
> but not the full auth_session_info.

At the point that we see the user_supplied_info, we don't get the
auth_session_info, this is generated later.  Because of the differences
between the source3 and source4 auth subsystems, I can't even pass in
the user_info_dc etc, so we just pick out some key parameters. 

> The output format should also be flexible, we can't guarantee that
> we'll generate the exact output forever.

Indeed!  This work is just the first step, designed to be practical to
read, the full task from our clients calls for JSON (one one line),
which is the next step now we have the plumbing in place.

Thank you so much for taking the time to look at and think about this
work!

Andrew Bartlett


-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170303/f3f5c1f4/signature.sig>


More information about the samba-technical mailing list