DC-replication auditing and control (was: Re: New attack on Active Directory)

Andrew Bartlett abartlet at samba.org
Wed Jan 31 23:23:18 UTC 2018


On Wed, 2018-01-31 at 10:18 -0800, Jeremy Allison via samba-technical
wrote:
> On Wed, Jan 31, 2018 at 08:54:52AM -0500, Simo via samba-technical wrote:
> > On Tue, 2018-01-30 at 09:36 -0800, Jeremy Allison via samba-technical
> > wrote:
> > > https://blog.alsid.eu/dcshadow-explained-4510f52fc19d
> > > 
> > > I'm still reading, but thought people on this list
> > > might want to get familiar with it.
> > > 
> > > Don't know if it affects Samba yet.
> > 
> > It gets old fast when people mark as "attack" what is clearly not, sad!
> 
> Yep, realized that once I'd finished going through it.
> Already updated the list with that info.
> 
> TL;DR "Compromised server is compromised" :-).

I actually think there could be significant value in refusing to
replicate to and from a server that doesn't present some additional,
outside AD, authentication.  

I've been toying with the idea that we should (optionally) lock Samba
down to replicate over TLS-secured ncacn_http with client and server
certificates.  That way a new DC can't be introduced without (manually)
getting a client and server cert from a locked-down CA. 

However, there is also a real security bug here in a sense:

No auditing happens regarding replicated data (as it assumed to already
be audited), so while the system is compromised nobody can see how.  Of
course an attacker with root on the DC can just modify the DB directly,
but really good auditing support would have the other DCs make logs
about those changes. 

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







More information about the samba-technical mailing list