When you create a new forest or new domain, you use the Domain Admin credentials. Through the use of the “Administrator” account you can control each and every workstation and server. You can install Exchange, System Center products and much much more. But Microsoft is probably thinking twice now about the framework they have chosen wherein the Administrator is master of your infrastructure.
As the Administrator account is so powerful, it’s a sweet spot for hackers, the target to get. And that’s probably why many people rename the administrator account to Guest (and vice versa) or something else. Many others keep the Administrator name but change the password to a very long one including special characters, but even that seems futile, by the discovery of an advanced hacking technique called Pass The Hash.
So we’ve seen how a trust is setup, and how we can manipulate the domain controllers involved, can we do the same for authentication traffic? The answer would be yes, but why is it a yes, and how is the main question.
While many believe WINS or LMHOSTS can help us on external (non-forest) trusts, we dive into a packet capture that has captured the opening of a fileshare on a remote forest.
For this demo, I have installed a resource server in the forestroot domain, and a RIVER client on the OCEANFLOOR domain.
So I was wondering the following, how do all the domain controllers know that the trust is established, since (see previous post) we cannot accurately say which domain controller is being used..
When we have the same problem with user passwords, the PDC gives the vote whether the password (just changed) for the user is valid. The same seems to apply for Trusts. When running a trace while creating the trust on a “regular” domain controller and not the PDC, we can find out how that is accomplished. For this, I have installed a domain controller called MICHDC01 which is on the (newly created) LAKES site.
In part of the the forest authentication blog post, we’ve seen that a particular path is used depending on Kerberos or NTLM authentication. We’ve also seen that domain controllers rely on other domain controllers of the forest to find the right domain (and thus object in the AD). The question now is, which domain controller of the other forest is used to authenticate the user? What happens during a trust creation, do we really need the PDC emulator? Will LMHOSTS still help us, like it did in the old days?
Those questions we will answer in this series of authentication across trusts part 2, 3 etc..
When using GPP’s to map drives, some of you will notice that some drives are not correctly mapped on the clients. Some users will receive other network mappings (they “sort of” never heard of before) and some network connections are there, but will not be re-attached (device name is already in use).
So you have implemented Active Directory 2008 .. I hope you did some investigation in backup/restore and offcourse you must update your disaster recovery documentation now.. to help you on your way Microsoft has released a new whitepaper on Forest Recovery for Windows 2008… read before and while fixing your AD.. (preferably before ) http://www.microsoft.com/downloads/details.aspx?familyid=326C8A7A-DCAD-4333-9050-A6303FF3155C&displaylang=en
If you want to implement iSCSI it’s best to keep the normal network traffic and the iSCSI traffic apart from each other. And that usually means buying a 2nd switch capable of reaching high speeds and jumbo frames. Off course for production systems I recommend spending a few bucks.. however if you only want iSCSI in you lab, there are easier ways of creating a switch!.
With the release of Windows 2008, the backup mechanism of Windows has also changed. No more NTBackup, but Windows backup, available to your 2008 system as a feature. Also part of that feature is the systemstate backup, you know the one that is utterly Important to restore Domain Controllers. Now the GUI will not let you perform a single systemstate backup (only full backups including everything) and backups can be stored on a network share. But let’s say we want a systemstate backup only?!
The introduction of Windows 2008 brought us the famous Read-Only domain controller, the domain controller without passwords (unless explicitly approved) and one-way replication. That one-way replication also applied to the SYSVOL share. Sysvol is replicated by either FRS or DFSR depending on the initial setup of the domain. If you have upgraded your domain from Windows 2000 or Windows 2003 to Windows 2008 SYSVOL is still using FRS to replicate. When you have initially deployed Windows 2008 and set the forest functional level to use the Windows 2008 standards; DFSR is used. Usually the replication of Sysvol is two-way, you can change the contents on each domain controller and those changes are replicated to all domain controllers.