Externally Sealed Off

Cautious Use of Administrator Account

For secure AD environments, it makes sense to limit the use of accounts with increased privileges as much as possible. You should only log in with the administrator account that is set up for the respective server service. If a workstation is suspected of being compromised or insecure, it is highly advisable not to log on to the system with the administrator account. In general, it makes sense to avoid logging on to computers that are connected to the Internet. In other words, the administrator workstations tasked with managing the environment should not be connected to the Internet.

In general, it is better to work with normal user accounts rather than administrator accounts by default anyway. The administration of the environment should be done at special workstations that are exclusively for administration purposes. The Log on as … rights are not recommended in secure environments, because the logon data is stored temporarily on the computer. Particularly secure administrator workstations should therefore only be used for administrative work. Administrator's should use a different workstation for nonadministrative work.

An added advantage of this division is that only the programs required for administration are installed on the administration workstations, which can be protected by group policies. For example, Microsoft previously offered the Security Compliance Manager [2] to create templates for group policies (Figure 1).

Figure 1: Tools such as Security Compliance Manager (now retired [3]) made it possible to operate AD environments more securely.

In principle, it makes sense to use multifactor authentication for the administrator accounts. Moreover, it is advisable to use temporary administrator accounts. In such an infrastructure, administrator accounts only have the right to perform a specific management task for a limited period of time. Once the task has been completed or the time has elapsed, the rights are removed.

Read-Only DCs

In locations where DCs are not located in protected server rooms, read-only domain controllers (RODCs) should be used. RODCs receive the replicated information from the normal DCs and do not accept changes from administrators. Thus, an RODC only receives information and cannot write any information into AD. This feature allows you to run DCs in smaller branch offices, where the DCs are not protected, without compromising a company's security.

An RODC protects AD from password spying. It knows all objects in AD, but only stores the user passwords that you explicitly specify. If such an RODC is stolen and an attacker attempts to read passwords from the controller's database, the accounts of the remaining domain are protected. Writable DCs do not set up a replication connection to RODCs, because a replication can only take place from normal DCs to RODCs. RODCs set up replication connections to the writable DCs that you specify when upgrading.

In the Active Directory Users and Computers snap-in, you right-click the Domain Controllers organizational unit (OU) and select Pre-create Read-only Domain Controller account from the context menu. Then, run the wizard to create a new DC in the data center and assign it a computer account. An administrator can then install this server in the branch office. The server is automatically assigned the function of the RODC.

An RODC offers a complete AD, but without storable passwords, because the associated folder is write protected. When using RODCs, the following procedures apply:

1. A user logs on to the RODC location.

2. The RODC checks whether the user's password has been replicated to the server. If so, the user is logged on.

3. If the password is not available on the RODC, the login request is forwarded to a fully fledged DC.

4. If the registration is successful, a Kerberos ticket is assigned to the RODC.

5. The RODC now issues the user their own Kerberos ticket, with which this user works. Group memberships and group policies are not sent wirelessly. This information remains on the RODC.

6. Next, the RODC tries to replicate this user's password into its database from a DC. Whether or not this succeeds depends on the respective group membership.

7. The process starts again from step 2 the next time the user logs on.

The administrator account passwords in AD are never stored on an RODC. Because of their importance, these passwords are excluded from possibly being replicated to the write-protected DC. If the wireless connection between the branch office with the RODC and a normal DC is lost, no logon takes place at the domain. The RODC then behaves like a normal member server, and only a local logon to the server is possible.

If you install the DNS service on an RODC, the server becomes a read-only DNS server. The same restrictions apply here as for an RODC. A read-only DNS server only accepts changes from normal DNS servers and does not accept any changes itself. A read-only DNS server is available to users as a normal DNS server for queries, but does not support dynamic DNS registration. If a client tries to register, the DNS server will tell it that the update is not accepted. In the background, the client can try to register on a normal DNS server, which then replicates the changes back to the read-only DNS server.

In the event of the theft of an RODC, the administrator must remove the computer account of the stolen DC. A selection window is displayed, which resets the passwords of users and computers replicated on the RODC.

Even if a thief is able to read the data from the RODC, it is worthless, because a reset has been carried out in the meantime. During this process, AD does not delete the user and computer accounts – just the passwords. Additionally, the data not only can be reset, but the wizard has an option to export the accounts.

Securing the DNS System

Microsoft has already introduced Domain Name System Security Extensions (DNSSEC) with Windows Server 2008 R2. Zones can be signed digitally online in Windows Server 2016. DNSSEC can be fully integrated into AD, including the ability to enable dynamic updates for protected zones. Windows Server 2016 supports official standards such as NSEC3 and RSA/SHA-2 for digital signing of DNS zones and also supports DNSSEC on RODCs. If an RODC with Windows Server 2016 finds a signed DNS zone, it automatically creates a secondary copy of the zone and transfers the data from the DNSSEC-protected zone.

Advantageously, branch offices can also resolve data backed up with RODCs without endangering the zone's signature and data. DNSSEC can be created from the zone's context menu, and the zone is signed by an assistant. The wizard allows manual signing, an update of the signing, and a signature according to automatic settings. With Windows Server 2016, signed zones can also be replicated to other DNS servers in the network.