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

Simo simo at samba.org
Thu Feb 1 00:45:04 UTC 2018


On Thu, 2018-02-01 at 12:23 +1300, Andrew Bartlett via samba-technical
wrote:
> 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. 

If a domain is compromised it is really easy to load a new custom CA
cert in the trust store and mint as many cert as you need to pass
validation.

> 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. 

Yes, auditing would be a much better thing to do, esp if audit logs are
shipped to a write-only server that is otherwise segregated from the
domain controller (identity/trust wise).

Simo.



More information about the samba-technical mailing list