Logging onto the domain controller consoles to administer DDNS, DHCP, Active Directory, and its critical services will be prevented (in fact, only members of Server Operators can log on to a DC and restart it). As mentioned earlier, this practice of logging on directly to servers is also discouraged on MS Exchange, SQL Server, SMS Server, and other leading Microsoft server technologies. These servers should be managed from secure administrative workstations, or using an enterprise service account (see Table 12-10).
There are many different types of administrative activities taking place on a daily basis that require access to AD. These activities include GP management, user and group account management, AD publishing, site management, event log monitoring, replication monitoring, and so on. These activities are typically shared among several engineers in a large IT environment, and thus logging onto DC consoles is neither practical nor safe.
Apart from the default administrative tools that are installed on a DC during promotion and bootup into Active Directory, many more client applications may be required to administer to AD. The netlQ tools and the new Microsoft GP Management Console are good examples. A number of tools are also needed by help desk personnel, who, in any event, are not members of any group that permits local logon to a DC.
lnstalling all manner of administrative utilities on DCs also creates the potential for viruses to infiltrate the DCs, hostile code that can cause denial of service attacks on AD, and application incompatibility that can cause problems on the server.
Active Directory employs client-server database architecture (the same architecture that underpins MS Exchange and a number of other Microsoft technologies), so the MMC applications used to administer to both AD and Exchange should be opened from a client desktop.
Because administering AD from the console is also prevented, AD tools, Exchange tools, GP tools, security tools, the SMS Administrator consoles, SQL Enterprise Administrator, and Query Manager tools, and so on, will be installed on all engineer workstations.
Tools will be restricted to certain engineers through Group Policy, but most administrative tools will be installed on workstations (including help-desk workstations). This practice enables an engineer to be elevated to a certain level and immediately gain access to the required tool. It also enables another administrator to open a tool using Run As from a machine whose original owner cannot.
This practice of administering from workstations also enables us to actually restrict DC logon and direct DC server administration (such as restarting the server, applying service packs, and upgrading hardware) to trusted administrators who do not necessarily need to have AD administrative privileges. It also enables us to prevent direct logon to DCs by denying the right to log on to DCs (by enabling this policy setting in GP and specifying the groups to which this applies).
ln addition, the data-streams between the workstations and the DCs, and servers such as SQL Server, can be compromised by sniffing the network and tapping into the text-based LDAP or tabulated data-streams (TDS). As a result, a number of AD domains have been victims of replay and denial of service attacks resulting from attacking the TDS and RPC traffic.
The best solution and practice is to create lPSec tunnels to the servers and secure them with Certificate Services (or using local certificates as a temporary solution before a CA is put in place). While this implies additional overhead on the workstation, the amount is negligible. LDAP signing can (and should) be included in the architecture. See "Locking down Domain Admins" in Chapter 14 for more information.
Was this article helpful?