DCSync fails against renamed domains about mimikatz

[gentilkiwi]

Amazing :)
Thank you @MichaelGrafnetter and @rmbolger !
I even didn't know that a domain could be renamed :)

Luckily the kull_m_rpc_drsr.h file is ready to embed the dwReplEpoch :)

typedef struct _DRS_EXTENSIONS_INT {
    DWORD cb;
    DWORD dwFlags;
    //GUID SiteObjGuid;
    //DWORD Pid;
    //DWORD dwReplEpoch;
    //DWORD dwFlagsExt;
    //GUID ConfigObjGUID;
    //DWORD dwExtCaps;
} DRS_EXTENSIONS_INT, *PDRS_EXTENSIONS_INT;

I'll take a look, maybe this week end !

[rmbolger]

Glad to help. And yeah, domain renames are definitely rare and can be cumbersome if you have a lot of services already running against it. But I think the process has been officially supported since at least AD 2003.

[speidy]

Cool :) thanks for updating
בתאריך יום ו׳, 29 באפר׳ 2016 ב-0:58 מאת Ryan Bolger <
[email protected]>:

Glad to help. And yeah, domain renames are definitely rare and can be
cumbersome if you have a lot of services already running against it. But I
think the process has been officially supported since at least AD 2003.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#35 (comment)

[MichaelGrafnetter]

Well, the documentation on dwReplEpoch clearly says that

This value is set to zero by all client callers.

Lessons learned: Do not trust the documentation. ;-) On the other hand, mimikatz or DSInternals do way more than a regular client caller.

[gentilkiwi]

Or we must read the all the documentation :D

If the client is a DC, it reads the value of msDS-ReplicationEpoch from its nTDSDSA object and assigns this value to the dwReplEpoch field of the DRS_EXTENSIONS_INT structure; otherwise, it sets the dwReplEpoch field of the DRS_EXTENSIONS_INT structure to zero.

On my side I tried to minimize this struct size to minimize error on input... at least we must now go to this field ;)

[rmbolger]

This is the first time I've read this deep into the replication protocol. And I'm confused about their "client" and "server" terms. Can't decide whether they mean a generic client/server like caller/endpoint...or more specifically a replication client vs a replication server. And since mimikats is impersonating a server in this case, it would need to follow the second sentence.

The server sets this value by assigning the value of msDS-ReplicationEpoch from its nTDSDSA object.

But because we're only a fake server, we don't actually have an nTDSDSA object of our own to check. So we need to cheat, check the target DC's value, and match it.

[gentilkiwi]

I think it will not be a problem because we must get uuidDsaObjDest from NtdsDsaObjectGuid so I presume it will be easy to get dwReplEpoch from this previous bind.

[rmbolger]

Here's a better reference in the docs for IDL_DRSBind.

The client uses pextClient to pass a properly initialized DRS_EXTENSIONS_INT structure to the server. If the client is a DC, it reads the value of msDS-ReplicationEpoch from its nTDSDSA object and assigns this value to the dwReplEpoch field of the DRS_EXTENSIONS_INT structure;

[MichaelGrafnetter]

Of course that by client they mean Windows 7, which uses IDL_DRSCrackNames extensively. That is the security problem of this protocol: It mixes DC-DC, client-DC and admin-DC communication, so you cannot block it by firewall.

[gentilkiwi]

Damned, even MS can update its code ;)
https://community.office365.com/en-us/f/156/t/172670 -> http://social.technet.microsoft.com/wiki/contents/articles/18429.dirsync-directory-sync-tool-version-release-history.aspx#AO5