Secure Your Active Directory Windows Server

If a server that you manage is permitted to access or maintain U-M sensitive institutional data, it should be hardened to meet the minimum expectations below. Check out the Sensitive Data Guide and the Responsible Use of Information Resources (SPG 601.07) for for more general guidance on data types and usage.

Information Assurance (IA) recommends that you begin the process of hardening university servers, workstations, or databases by running the Center for Internet Security's Configuration Assessment Tool—CIS-CAT. The tool will scan your system, compare it to a preset benchmark, and then generate a report to help guide further hardening efforts. See CIS-CAT for U-M Systems for information about the UM-specific version of the tool.

IA provides access to Group Policies to be used as a starting point for securing AD-connected Windows computers and user accounts. GPOs are provided "as-is" as templates for system administrators to use as a guide for creating their own policies. Use of these GPOs does not guarantee compliance with U-M IT standards or other contractual and regulatory requirements. You are responsible for performing assessments of your systems to ensure compliance. See Group Policy Resources for requirements and best practices for using the GPOs referenced on this page.

  • Ensure that Group Policy inheritance is not blocked.
  • All shared GPOs can be self-created rather than directly linked by using Group Policy Management Tools (GPMT) to back up the IA GPO, then importing the backup into a self-created GPO.


Configuration and Management

Set a system use or logon notification that references SPG 601.07.

Responsible Use of Information Resources (SPG 601.07) is available online.

Configure a Logon Notification for Active Directory

Shared GPO:

  • Shared-ITS_IIA-ProperUseBannerMesg
  • Navigation:\UMICH\Administration\IIA\Shared-GPOs\Setting_Specific

Enable previous logon display at login.

Configure Previous Logon Display for Active Directory

Shared GPO:

  • Shared-ITS_IIA-DisplayPreviousLogonInfo
  • Navigation:\UMICH\Administration\IIA\Shared-GPOs\Setting_Specific

Set your screensaver to activate after 15 minutes (or less) of inactivity and require your password to unlock it.

Configure a Password-protected Screensaver for Active Directory

Shared GPO:

User Configuration:

  • Shared-ITS_IIA-Passwd-protected-scrnsaver-UserConfig
  • Navigation:\UMICH\Administration\IIA\Shared-GPOs\Setting_Specific

This GPO will set users' GPO preferences to require a screensaver. Users can choose their own screensaver, but cannot select none.

Computer Configuration:

  • Shared-ITS_IIA-Passwd-protected-scrnsaver-ComputerConfig
  • Navigation:\UMICH\Administration\IIA\Shared-GPOs\Setting_Specific

If creating your own GPO, configure the Force Specific Screensaver setting, otherwise other settings in the GPO will not be applied. This setting prevents the user from choosing their own screensaver.

Install and use anti-virus software.

For servers built into U-M's Active Directory (UMROOT) and/or university-owned systems, IA recommends System Center Endpoint Protection (SCEP) for anti-virus protection. SCEP configuration should include:

  • On-access scanning
  • On-demand scanning
  • Scheduled scanning (full/weekly)
  • Automatic definition updates (daily)

Members of the U-M community can download SCEP for Windows servers via M+Box.

Run Windows Server Security Configuration Wizard.

Here is information about the Security Configuration Wizard. Check Microsoft Support for specific instructions for these settings for your version of Windows.

Disable any unused or unnecessary features of the server or the service or application. Server Manager can be used to disable many of these features.

Update promptly. Update the service or application within 30 days of an official security patch release by a vendor.

Configure Windows Update for Active Directory

UMROOT Domain: Membership in the UMROOT domain automatically configures Windows Update. It is likely configured to download, notify the user, and automatically install Windows updates on a regular schedule.

Shared GPO:

  • Shared-ITS_IIA-Windows_Update
  • Navigation:\UMICH\Administration\IIA\Shared-GPOs\

Assign a Static or reserve a DHCP IP address and register a DNS name for your server.

Using ITS DNS is recommended. In addition, set up reverse DNS for each IP address(es) on the server. Include email contact information in the DNS record.

Avoid running local versions of services that ITS provides centrally (such as DHCP, NTP, and DNS) as they may create vulnerabilities for exploit or attack.

Request an SSL server certificate and enable its use by the web server.

Request an SSL certificate from UMWeb. Do not use default certificates in production.

Configure network time synchronization.

Membership in the UMROOT domain automatically configures and syncs Windows Time Service.

Back up your data.

The university offers the MiBackup service for server backups. The Sensitive Data Guide entry for MiBackup Service provides detail about which types of data can or cannot be backed up using MiBackup.

Backup recommendations:

  • Determine a backup schedule that works for you based on how frequently the data stored on the system changes.
  • The most recent full backup of the system should be stored off-site in case of disaster.
  • Run one full backup of the system once a week, and differential backups on every other day. Schedule the backups for times when the system is not in use to ensure that all files are captured and performance issues are avoided.
  • Test system restores using the backups on a regular basis.

Locate servers in an ITS-maintained data center using a service such as MiDatabase or MiServer, or at least maintain security and power.

ITS offers data center services and virtualization services like MiServer and MiDatabase

If you are unable to use these, follow these expectations:

  • Secure physical server access. Keep your server in a physically locked space. Do not keep your server in a publicly accessible location.
  • Maintain constant power. For the safety of the server equipment and the data stored on it, use an uninterruptible power source to supply power to the server.

Dispose of safely and securely.

Before selling, returning or disposing of your server hardware at Property Disposition, securely erase the data. See Prepare Devices for Disposal.

Access and Accounts

Require a password for access to your computer.

Follow these guidelines for a strong password. Unauthenticated access should not be permitted, whether by unauthenticated web servers, anonymous ftp servers, or open network shares which allow access to the server's file system.

Note: Membership in the UMROOT domain automatically configures this password policy.

Change default or vendor-supplied passwords to secure and unique passwords.

Use a secure file system that allows permissions to be set to restrict access, such as NTFS.

Use low-permissions accounts whenever possible.

  • Create specific accounts for each service or application limited to the access privileges necessary for the service to run.
  • Avoid using administrative level accounts to run services.
  • Accounts that access or administer the server should have the minimum permissions necessary to conduct the appropriate functions.

Require centralized authentication.

Avoid using local accounts for authentication into any service or application hosted on your server. Instead, use a centrally-managed account in a system such as Active Directory. Do not allow authentication with shared accounts.

De-provision regularly.

Implement account lifecycle management procedures to remove access of employees and collaborators that no longer require access to the server or applications.

Force session timeouts.

Regularly disconnect sessions idle more than two hours using a scheduled task or other methods.

Enable two-factor authentication, especially if the system will be storing sensitive data.

To implement two-factor authentication with Shibboleth, see Configuring Your Service Provider for Two-Factor Authentication (S4396).


Configure service audit logging for the server system and each unique service or application housed on the server.

Log authentications for services or applications housed on the server using a centralized logging system. Enable login auditing of failed and successful login attempts.

Configure file level access logging for the server file system.

Increase audit log size to accommodate the increased activity occurring on a server.

Configure Increased Audit Log Size, File Level Access Logging, and Login Auditing

UMROOT Domain:

  • Membership in the UMROOT domain automatically configures logging of file-level access, failed and successful login attempts, and increased audit log sizes.
  • UMROOT is set to audit only failures of file-level access, as auditing success can cause performance issues. IA recommends testing your configuration if you decide to audit both successes and failures.
  • Consider configuring the settings manually for local system accounts as well, in the event of a system compromise and local account creation.

Shared GPO:

  • Shared-ITS_IIA-ADV-Auditing-Server
  • Navigation:\UMICH\Administration\IIA\Shared-GPOs\CIS_MS-Benchmark-based

Configure notifications to alert the system owner or administrator when the system stops or restarts.

Report security incidents.

If your server or associated devices are compromised, stolen, or otherwise accessed in an unauthorized manner, report a security incident.


Disable unused optional network connections such as Wi-Fi or Bluetooth.

Limit network access to the service to LAN or U-M campus networks using a local or gateway firewall. Run a port scan of the system to confirm that ports are properly protected.

Require VPN connections to access the service from off-campus or non-LAN IP networks.

Connect securely to the server.

Do not use insecure or clear text protocols to connect to the server. If those methods must be used, restrict server access to specific IP addresses or the U-M campus network.

Restrict access to remote access management cards or interfaces using firewall or other network restrictions to U-M campus networks and require use of the U-M VPN for off-campus access.

Other Things to Consider

Monitor file system modifications for unauthorized changes using a binary file integrity check service such as tripwire.

Enable encryption.

You can encrypt the hard drive (full disk encryption), partitions on the hard drive, or files and file directories. Hard drive encryption can be set up during the installation of the operating system. Microsoft provides instructions for enabling file encryption.

Restrict boot source in BIOS.

Configure BIOS to disable boot from CD/DVD, external devices (USB), or from a floppy drive if the physical security of the server could be compromised. Additionally, consider setting a BIOS password to further restrict access to the system.

Configure BIOS Boot Restrictions and Set a Password

  • Restart your system and access BIOS.
  • On the Boot tab, set the first boot device to be the local hard drive. Disable booting from other boot devices.
  • On the Security tab, set a supervisor password.

Regularly scan the server for vulnerabilities.

IA offers free monthly vulnerability scans.

Check the Sensitive Data Guide to confirm that your server is eligible to access or maintain the type(s) of sensitive data it is storing or processing.

Checking the Sensitive Data Guide is especially important if your server is a virtual machine.

If you are accessing or maintaining Credit Card or Payment Card Information (PCI) or Protected Health Information (PHI) on your server, you should consult with IA to determine if your server is approved.

Centrally manage anti-virus and update utilities, especially if the server network is large or distributed. Send anti-virus logs to a centralized logging system such as splunk.

Use appropriate settings or controls to ensure that sensitive data accessed or maintained by your server cannot be cached to client systems connecting to your server.

Additional Resources for Securing Windows Servers

Last Updated: 
Wednesday, October 23, 2019