a) Did you know there are some things in your AD Forest (or Domain) that can only be performed by a certain user?

b) Even though your user account might be a member of the "Domain Admins" or "Enterprise Admins" group, there are things you won't be able to do, unless you're logged on with the "First" Administrator account.

c) For example, if all your Global Catalogs are offline, logons will be denied due to the fact the DCs can't do Universal Group membership enumeration. The only user that can logon in that scenario is "The Administrator", so you can troubleshoot the problem.

d) This is a very common situation during a forest/domain outage.

Yeah! Remember that account the DCPROMO wizard created with your first domain controller, some very long years ago?? That one you probably renamed and changed the password to something really crazy that no one would ever guess (or perhaps you even lost the password)! THAT ONE! That account is actually very special! So let's make sure we identify that user account and set a new and secure/complex password to it. You should also define a policy around who has access to that account's password, how and when (i.e. dual custody, put it in a safe, etc.)

Alright, so let's get down to some details before we jump into finding out that user. My first question would be: "So how does AD or Windows keep track of who is that really important user account"?

Well, accounts in Windows and AD have SIDs (Security IDs) and that's how we assign and keep track of permissions. SID are usually ended by random numbers. However, some accounts have special SIDs that never change and those are called the "Well Known SIDs". Some examples are:

• SID: S-1-1-0
  Name: Everyone
  Description: A group that includes all users, even anonymous users and guests. Membership is controlled by the operating system.
• SID: S-1-5-11
  Name: Authenticated Users
  Description: A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.
• SID: S-1-5-21-domain-500
  Name: Administrator
  Description: A user account for the system administrator. By default, it is the only user account that is given full control over the system.

If you like formal definitions, I did some copy and paste from MSDN, though it doesn't make a lot of sense to me.. (so I took the liberty to add some of my comments in the end of each sentence. I hope it makes more sense that way!)

• security identifier
  (SID) A data structure of variable length that identifies user, group, and computer accounts. Every account on a network is issued a unique SID when the account is first created. Internal processes in Windows refer to an account's SID rather than the account's user or group name. (Luis...) It's something like S-1-5-21-xxx or S-1-5-21-xxxxxx-xxxxxx-xxxxxxxx-500 and is stored in AD as the objectSID attribute.
• relative identifier
  (RID) The portion of a security identifier (SID) that identifies a user or group in relation to the authority that issued the SID. (Luis...) The last few digits of the SID, which differentiates two or more users from the same domain. For a certain domain, all users share pretty much the same SID, only the very last few digits are unique.

Notice from above that for a certain system (Windows computer or an AD domain), any SID ending with -500 will be by default the built-in administrator and that's why the "almighty administrator account" in AD is also referred to as "the dash 500 account".

The next natural question I have is: "So how do you determine which of your Active Directory accounts is really the -500 administrator?" Easy enough, just follow the steps below:

1. Logon to a DC or any domain joined computer with Support Tools or RSAT installed
2. Open LDP.EXE from the Start Menu
3. Click the Connection menu and select Connect (you can leave this window blank and it will connect to the closest DC).
4. Click OK
5. Click the Connection menu again and select Bind (you can leave this window blank and it will use the current user's credentials)
6. Click OK
7. Click the View menu and select Tree.
8. Select the Domain from the list and click OK.
9. Expand the nodes to see the OUs. Navigate around until you find any user account (could be yours, it doesn't matter)
10. Press CTRL+N to clear the screen
11. Double clicking any existing user account looking for the ObjectSID attribute in the right hand pane. It should look like objectSID=S-1-5-21-xxxxxx-xxxxxx-xxxxxxxx-xxx. Write down that SID.
12. Now right click the DC=domainname,DC=domain node from the left pane, and select Search.
13. Make sure Base DN is DC=domainname,DC=domain and scope is set to Subtree.
14. Change the filter to:
    (objectSID=S-1-5-21-xxxxxx-xxxxxx-xxxxxxxx-500)
15. Click Run, and should see the user’s name and location in the background (right pane). You are lookin for the distinguishedName attribute. That's it.

IMPORTANT: Be careful that by resetting this user's password you could break other systems that might be using these credentials, even though you shouldn't be doing that!

Also Double click the user and make sure it belongs to Enterprise Admins (Member Of tab). Make sure the user is not disabled or locked (Account tab)

That's it for the first article from the AD DR Series.. More to come soon

-LuisTog

-----------------------------

Sources:
Well Known SIDs
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379649(v=vs.85).aspx

Well-known security identifiers in Windows operating systems
http://support.microsoft.com/kb/243330

Life is not perfect and sometimes the situation requires for you to put a firewall between Domain Controllers. I’m not here to discuss the reasons that require you to do so, but I must tell you that restricting AD DS traffic (firewall) is not something we recommend and used only when really necessary (avoided whenever possible). But once again, if there’s nothing you can do, let’s at least make sure all the vital traffic is indeed going through. I hope this guide is helpful to you!

There are at least two options that can be used to allow replication when there are network traffic filters (aka firewall) in the network, across two DCs. Both will be detailed here:

1. Use registry keys on the DCs to force communication over specific ports (AD DS Replication, FRS Replication or DFS-R and Netlogon) and open a few extra ports for additional RPC communication.
2. Use IPsec to restrict the traffic to two ports only (IP 50 and IP 51)

a. Full encryption (ESP) should be implemented, but you might want to consider using AH only (headers), so the traffic can be inspected if necessary (or required)

b. Kerberos can be used for authentication, but that requires port 88 (TCP/UDP) to be opened as well. You can use Certificates for the same purpose, which requires a CA installed, but keep you from opening an extra port in the firewall.

We’ll be assuming here that there’s no client traffic crossing the firewall, only AD replication. This means that if all of the DCs in either side fail, no authentication will be available at that side of the firewall, as the client traffic will be blocked across the firewall. If your scenario require authentication traffic to go thought the firewall, additional ports might be needed.

Please notice that if you’re restricting DC replication through a firewall because one of your DCs is in a perimeter (DMZ) network, consider deploying RODCs to achieve a higher security level. Check the following guide for more information about Deploying RODCs in the Perimeter Network: http://technet.microsoft.com/en-us/library/dd728035.aspx

Restricting DC traffic using registry keys

Configure your firewall to allow the following ports:

1. TCP/UDP 53 (DNS Name Resolution)
2. TCP/UDP 88 (Kerberos)
3. UDP 123 (Time Sync)
4. TCP 135 (RPC Endpoint Mapper)
5. TCP 49152 (AD REPLICATION. See Registry Key 1 below)
6. TCP 49153 (NETLOGON. See Registry Key 2 below)
7. TCP 49154 (FRS or DFS-R REPLICATION. See Registry Key 3 below)
8. TCP 5722 (DFS-R Replication)

Then set the following registry keys on your Domain Controllers. Once you’re done, reboot the DCs for the settings to take effect. In theory, since the KCC controls the replication topology and not you, you should apply these changes on all your DCs, in case they ever need to replicate with each other. However, for security reasons, you can just configure it on the DCs facing both sides of the firewall:

Registry key 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Registry value: TCP/IP Port
Value type: REG_DWORD
Value data: 49152 (This value needs to be specified in decimal format)

Registry key 2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registry value: DCTcpipPort
Value type: REG_DWORD
Value data: 49153 (This value needs to be specified in decimal format)

Registry key 3
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTFRS\Parameters
Registry value: RPC TCP/IP Port Assignment
Value type: REG_DWORD
Value data: 49154 (This value needs to be specified in decimal format)

If you’re using DFS-R, you want to run the following command instead:
dfsrdiag StaticRPC /port:49154 /Member:<serverFQDN>

References:
Restricting Active Directory replication traffic and client RPC traffic to a specific port
http://support.microsoft.com/kb/224196

How to configure RPC dynamic port allocation to work with firewalls
http://support.microsoft.com/kb/154596

How to restrict FRS replication traffic to a specific static port|
http://support.microsoft.com/kb/319553

Service overview and network port requirements for the Windows Server system
http://support.microsoft.com/kb/832017

Restricting DC traffic using IPSec

IPSec provides a way to easily encapsulate and carry traffic over a firewall. IPSec can also increase security between the DCs using mutual authentication (Kerberos or machine certificates). That way, DCs can guarantee to whom they are communicating with before any actual information exchange occurs.

However, there’s a key decision that must be made at this point - whether to use Certificates or Kerberos for IPSec Authentication. If using Kerberos, you won’t be able to perform the DCPROMO behind the firewall, as the computers must be a member of the domain. If instead you want to use certificates, you need a CA (AD CS) to obtain a certificate for each DC.

For IPSec replication, configure your firewall to permit the following:

1. TCP/UDP 53 (DNS Name Resolution)
2. TCP/UDP 88 (Kerberos)
3. UDP 500 (IKE)
4. IP 50 (IPSec ESP)
5. IP 51 (IPSec AH)

Note that IPSec will not work through network address translation (NAT) devices. Because IPSec uses IP addresses when computing packet checksums, IPSec packets whose source addresses were altered by NAT are discarded when they arrive at the destination.

So let’s move on and start configuring the DCs. In our example scenario here, there are 3 DCs running Windows Server 2008 R2, but you can run a mix of 2003, 2008 and 2008 R2, as the configuration is pretty much the same. Two DCs are inside the corporate network (DC1 and DC2) and one DC is outside the perimeter (DC4).

We’re going to configure the IPSec policy on all 3 DCs, so they use IPSec transport mode to communicate with each other. Note that we are not creating IPSec tunnels, but using IPSec transport mode - end-to-end IPSec – instead.

Configuring the Servers

NOTE: To make this setup easier, I promoted all DCs in the same network (no firewalls) and tested replication to make sure no problems existed before continuing with the IPSec policy creation.

Starting with DC1, run the following steps to create an IPSec policy for replication, along with a corresponding IP filter list and filter action.

1. Open Start | Administrative Tools | Local Security Policy.

2. Right-click IP Security Policies on Local Machine (in the left-hand pane of the MMC) and select Create IP Security Policy.

3. Click Next and provide your IPSec Policy with a name

4. Do not check the box and click Next.

5. Now make sure “Edit Properties” is checked and click Finish.

6. Now at the IPSec Policy Properties (DC Replication), you can see no rules are in effect. You want to create a new rule, so click Add…

7. Click Next and make sure “This rule does not specify a tunnel” is selected. Click Next.

8. Select “Local Area Network (LAN)” and click Next again.

9. In the IP Filter List screen, click Add…

10. The IP Filter List window will open. Click Add and follow the wizard to create three filters, from <My IP Address> to all other DCs that will participate in this communication, including DC1 itself. This will make sure all traffic from all DCs is forced to use IPSec. In this example, we have three filters, from DC1 to DC1, DC2 and DC4. Make sure the Mirror check box is selected, and the filter includes all Ports and Protocols. Click OK when done.

11. Back to the IP Filter List Screen, select the newly created filter and hit next.

12. Now we need to create a Filter Action. In the Filter Action screen, click Add…

13. Name the filter DC Replication Action

14. Select “Negotiate Security” and click Next

15. Make sure you select “Do not allow unsecured communication” and click Next

16. And now to the first important choice: the security implemented with IPSec.

a. In the screen shown above, if you select “Integrity and encryption”, ESP will be in effect, using Protocol IP50. It means all packages matching the filter list will be encrypted and then a checksum generated to protect against tampering. By default SHA1 is used for Integrity and 3DES for Encryption, as you can see below:

b. Some companies’ security departments require the ability to inspect network packages, and if that’s your case, you probably don’t want to encrypt the payload, but only enforce only Data and Address integrity (header checksum). In this case, select the Custom… option and use the following options:

17. Back to the Filter Action Screen, select the newly created Action and hit next.

18. Now it’s time for the second decision! Are you going with Kerberos Authentication or Certificates? In this example, we’ll use Kerberos, as all Domain Controllers are already operational, and Kerberos is available. So click Next.

a. Please check http://technet.microsoft.com/en-us/library/bb742429.aspx#EEAA for instructions on how to configure a CA (AD CS) and obtain a computer certificate for IPSec Authentication.

b. If using certificates, you also might want to check the following document http://social.technet.microsoft.com/wiki/contents/articles/584.active-directory-replication-over-firewalls.aspx#DCPromoIPSec to understand how to force Kerberos packets to be encapsulated by IPSec.

19. Click Finish.

20. You will be taken to the IPSec Policy Properties again, where the DC Replication Rule is already selected. Just click OK to confirm.

21. Finally, you need to turn on (or assign) the policy to the DC. So back to the Local Security Settings Window, right-click the DC Replication policy and select Assign.

22. IPSec processing happens immediately. There is no need to reboot the server.

Now that we are done with DC1, since every domain controller requires a similar IPSec policy, it is necessary to repeat all above steps for the remaining DCs. Regardless of whether the controller is in the internal network, the perimeter network, or the external network, you must configure its IPSec policy so that all communications with all other domain controllers are through IPSec. Not only does this allow the knowledge consistency checker to build a replication topology that ignores the firewall, it also secures all IPSec replication between every server.

Testing the IPSec Policy

Once you’re done with configuring all servers, we want to make sure replication is taking place and no important packets are being dropped by the firewall. In this scenario, I’ve used Hyper-V as the virtualization platform, and an extra computer running Forefront TMG to act as the firewall. I’ve also installed NETMON 3.4 to make sure packets could be inspected if using AH only.

1. From DC1, open AD Sites and Services (dssite.msc), expand the site that contain your DCs and find DC1.

2. Expand NTDS Settings and select all Replication Connection objects on the right-hand side panel.

3. Right click the Connection Objects and select “Replicate Now”

4. You should get the following message, indicating replication is working

5. Repeat that for all DCs, so you force a full replication cycle. You can also open a cmd window and type “repadmin /replsum /bydest”, which should give up an output similar to the screen shown below:

6. You can also create a file on SYSVOL (C:\Windows\Sysvol\domain) and see if it replicates to all other DCs. This tests the FRS Replication.

7. From a NetMon 3.4 window you can see the traffic going through as we’re using AH only in this example.

8. You can also notice no packet drops in the firewall

References:
IKE: Internet Key Exchange
ESP: Encapsulated Security Payload
AH: Authenticated Header

Active Directory Replication Over Firewalls
http://social.technet.microsoft.com/wiki/contents/articles/584.active-directory-replication-over-firewalls.aspx

How to Enable IPSec Traffic Through a Firewall
http://support.microsoft.com/kb/233256

Step-by-Step Guide to Internet Protocol Security (IPSec)
http://technet.microsoft.com/en-us/library/bb742429.aspx