Re: Solution seems to be obvious
From a disaster recovery standpoint. NEVER use AD on anything you will need to restore your network. I know of one location that had a VBlock with the AD server running in a VM. They could not login into the Vblock to bring up the AD server (did not set to auto start).
Never EVER use the same password on your backup you use on anything else.
Build a backup proxy, Pull the source and place the backup. Backup and Source can't talk. Don't trust MS, use vlans and ACL or firewall rules.
And....
I got so pissed at every program I install wants to phone home or become useless due to an unwanted update that you can't even tell if there is a virus outbound connection that I wrote a program that every time the screen saver comes on, it changes the gateway to an address not used. If there is a local thing I need my computer to do at that time, I add a static route. I keep a running log of when the system logged in and out so I can easily verify it use and list of current process that use an internet connection. After logging in and the gateway comes back online, it is like turning on the kitchen light and watching roaches scurry for their hiding places. They get added to the "route to null" list.
Oh, and by the way, Micro$oft application firewall does not block this stuff.