--Nerd Alert--
Last night I migrated from an old failing Windows 2003 file server to a shiny new[er] one. I got the printers, the shares, the permissions, and all the stuff you'd expect. Yay success!
Except somehow I managed to overlook that it was also the site's DHCP server. Oops. Fortunately Microsoft makes a handy-dandy DHCP migration tool that exports all the old databases and imports them into the new environment. Which is great so long as you include it as part of your planning process. Trying to run it after the fact results in spectacular failure.
I took the old server out of the domain, renamed it, re-IP'ed it, and rejoined it to the domain "just in case" we needed it. Rejoining it should also, in theory, deal with any lingering SID issues that might abound in a globally-distributed domain where replication intervals can become an issue.
Once that process was done, I removed, renamed, re-IP'ed, and rejoined the new server, using the old servers name and IP address. Simple server swap, right?
But now I needed to install DHCP services on the new one, which should have come up deactivated and required an Enterprise Admin account to activate. It didn't. It came up hot and is serving out addresses without explicit activation. That's crazy!
The whole point of needing an Enterprise Administrator to activate a DHCP server is to eliminate the risk of internal poisoning of your namespace. If any local site admin with privileges to add or remove a computer to the domain can activate a DHCP server, then you have no security. Somehow Microsoft's engineers believe that "security" for a core infrastructure service should be based on IP address and not SID.
No comments:
Post a Comment