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 as promised.. the install guide.. or at least some small tips as the installation is not that hard..
First of all, we are going to use a three server architecture. One server for the databases, one for the administration and monitoring and a group policy server.
To start, we need to create some groups in Active Directory, the service account for SQL and a service Account for the MBAM compliancy part. Create the following groups in AD and the following service accounts:
Read more
So everybody should enable firewall policies in order to keep their environment secure. Best practice is to manage the firewalls through policies.. keep a default policy to enable the firewall and do not allow incoming connections.. then based on server role add exceptions and ports. That way, each server added to the domain is secured by the firewall by default, but additional policies can enable applications to receive traffic.
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..
So I tried to install the FIM RC (u3) in a demo environment, and what a hush hush was that.. My setup was fairly easy, all (except SQL) on a single box.. offcourse reading is not my best skill, but the install went fine.. and the portal was ready for the administrator account (installed it with). It opened on the fim server without a problem, but getting it to work remotely, that was another problem..
The guide tells you to register SPN’s for the Kerberos to work if the FIM Portal and FIM service are on seperate servers, but ALSO if you want to use the FIM password reset extension.. however registering the http/servername to a service account renders the remote login useless.. you will receive an HTTP Error 401. The requested resource required used authentication.
If you where to google (or bing) on that error code the links tell you to disable Kernel Mode kerberos in IIS.. well that kinda did NOT do the trick either and although the Sharepoint site comes up then, the FIM portal dies..
When installing MOSS in an 2008R2 environment, you will notice that the Best Practices Analyser for Sharepoint will not run.. now this is not only to the fact that the BPA is running on the 2008R2 environment, it’s when the entire sharepoint farm is running on 2008R2. One option is to have a single 2008/2003 server on the same farm and point to that, or wait for the next release of BPA for Sharepoint.
The error received would be: Failed to retrieve the configuration database connection string from machine ‘<insert machinename>’ due to the following error: Failed to retrieve the configuration database connection string from machine ‘<insert machinename>’
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