A few months ago, we had an issue where an employee (for god knows what reason) decided to rename one of the conference room Mac minis to the same name as one of our domain controllers. The result was that the domain controller was demoted to a member server and pissed off a bunch of people.
We're running Windows Server 2008 R2 at the moment but I am currently migrating to 2012 R2.
Can anyone offer advice on how to lock this down so no one with a Mac or Linux machine can rename their machines to existing Windows domain machines? I don't want to have to go through this again :)
Thank you
The solution is to lock down who has the permissions to rename a domain-joined machine (modify permissions to Active Directory computer objects), and make sure those that do have these rights are careful/know what they're doing. By default, domain admin rights are needed to join a computer to the domain, or rename a domain-joined computer.
A naming convention where people aren't likely to rename machines to the same name as an Domain Controller or other server might be in order too, but that's a different question.
As to what happened:
The domain controller didn't demote itself. The computer object in Active Directory for the domain controller was basically overwritten/replaced with the one for the Mac mini because it has the same name. Basically, if you think of AD like a file system, and computer objects like files ... what happens if you move a file into a folder which has an existing file of the same name? The one file overwrites the other. Same basic thing here.
I've never seen this happen with a domain controller before, but have seen it lots with member computers in other environments. On member computers, when this happens, attempting to log on with domain credentials gives the infamous broken security trust relationship error - because the computer object in Active directory doesn't match the computer. The quickest solution to this with member computers is to login with local credentials, disjoin the computer, rename it, and rejoin it.
With a domain controller... not sure that would work, because there's no local credentials. You may have to enter DSRM (Directory Services Restore Mode) and do an authoritative restore, or, if that's not a good option, simply treat this domain controller like any other failed, unreachable domain controller and re-image it, and then go through the steps to clean it up from Active Directory.