Рекомендации по защите Active Directory Best Practices for Securing Active Directory

Область применения. Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Этот документ содержит ряд практических методик, помогающих ИТ-специалистам защитить корпоративную Active Directoryную среду. This document provides a practitioner’s perspective and contains a set of practical techniques to help IT executives protect an enterprise Active Directory environment. Active Directory играет важную роль в ИТ-инфраструктуре и позволяет обеспечить согласованную и безопасную работу с сетевыми ресурсами в глобализированной и взаимосвязанной среде. Active Directory plays a critical role in the IT infrastructure, and ensures the harmony and security of different network resources in a global, interconnected environment. Обсуждаемые методы основаны на опыте организации Microsoft Information Security and риски (ИСРМ), которая может быть обеспечена для защиты активов ИТ-отделов корпорации Майкрософт и других подразделений корпорации Майкрософт, а также для выбора нескольких клиентов Microsoft Global 500. The methods discussed are based largely on the Microsoft Information Security and Risk Management (ISRM) organization’s experience, which is accountable for protecting the assets of Microsoft IT and other Microsoft Business Divisions, in addition to advising a selected number of Microsoft Global 500 customers.

Windows server security best practices

Authored by: Rackspace Support

DISCLAIMER FOR MANAGED OPERATIONS CUSTOMERS

To ensure that Rackspace has access to your server when needed, we request that you do not change the following configurations as you consider security best practices:

When connecting to your server, Rackspace Support logs in as the user rack by using Remote Desktop Connection to the public IP address over port 3389.

Rebuilding existing servers or building a new server from a snapshot requires that Administrator logins are enabled, and port 445 is not blocked in the Microsoft® Windows® firewall.

If you must change these values, contact an administrator at Rackspace to make the changes in a way that does not impact our ability to provide you with a Fanatical Experience®.

This article provides some general security best practices to consider when you set up a Microsoft Windows server that interacts with the public Internet. Although these best practices apply to any server in general, this article specifically addresses Rackspace Public Cloud Servers running Windows.

Use local firewall rules

By default, Rackspace Public Cloud Servers do not have a firewall device. For servers that interact with the public Internet with no firewall device, the Windows firewall is the only protection between your server resources and your private data and anyone with access to an Internet connection.

Disable as many rules on the firewall as possible. Disabling rules means that fewer ports are open and listening over the public interface, which limits the server’s exposure to anyone trying to gain access to it.

For those ports that must be open, limit access to the server by whitelisting IP addresses in those specific rules. Add the IP address from your local home or office computer to the whitelist, even if your internet service provider (ISP) provides dynamic public IP addresses that change over time. You can make changes to the firewall rules as needed from the Cloud Control Panel by logging in to the server remotely via the console and adding a new IP address.

By limiting access to the server via IP address whitelisting, you can ensure that users who need access to the server have it, but those who don’t are blocked from those open ports. The most typical ports that need to be open in the Windows firewall for web hosting on a cloud server are as follows:

Port	Service
80 HTTP	IIS sites or web application
443 HTTPS	Secure IIS sites or web applications with SSL

We recommend locking down the following ports via IP address whitelisting on the public interface to limit brute-force attacks or exploitation attempts against commonly-named accounts or services on the server:

Port	Description
3389	Remote Desktop Connectivity, for logging in remotely to the server
21 FTP	For the secure transfer of data between local geographic locations and the cloud server
990 FTPS (Windows)	For the secure transfer of data between local geographic locations and the cloud server incorporating an SSL certificate
5000-5050 FTP	Passive ports for FTP communication
1433 SQL	Default port used for SQL communication
53 DNS	Default port used for DNS requests

Consider what you share

Consider what data is available to others via file sharing. We do not recommend enabling Windows file sharing because the ports open on the firewall (ports 445 and 139) expose the server to unwanted connection attempts.

Some customers use their servers to host back-office software such as QuickBooks®, PeachTree, Microsoft Office® (Outlook® for Remote Desktop sessions), or other third-party software solutions. Sometimes customers want to configure mapped network drives to allow them to easily move data from their local computers to their cloud server by way of a drive letter on the local computer. However, we do not recommend this practice. Your server is only as secure as the weakest password.

Additionally, be careful about the software that you allow your users to download and install on your server. Every software package installed increases the exposure of your server to attack.

Password policy

Whether or not you have provisioned a cloud server with a hardware firewall, as previously stated, your server is only as secure as the weakest password that has access to it. Follow these tips for passwords:

Use strong passwords of at least 12 to 14 characters that include uppercase and lowercase letters, numbers, and special characters (such as !, #, $, and %). Assigning simple passwords is extremely dangerous, especially for a cloud server that is available over the public Internet.

Set an expiration date for each user’s password. Although it is inconvenient to have to remember a new password periodically, this practice can make your data more secure.

Because our post-build automation processes depend on the default user account of Administrator, we do not recommend changing this username on your cloud servers running Windows.

Be careful who has access to the server through the Administrator account. If multiple users need admin access to the server, create multiple accounts with admin access. It’s easier to track users in the log files by looking for a specific user account than it is to try to decipher multiple log file entries under the Administrator account.

Multiple instances of Event Id 4625 in the Security Log or Event Id 1012 in the System Log can mean that someone is trying to hack into your server because these events are related to failed login attempts.

For users logging in over Remote Desktop Connection (RDC), ensure that they are logging off the server to free any used resources instead of simply closing their RDC windows, which leaves the session open on the server.

Active Directory

We typically discourage running Active Directory on a cloud server because the only protection from intrusion is the Windows firewall, and Active Directory introduces issues into a cloud server environment. Active Directory is generally better used in a dedicated server environment where servers are placed behind physical firewalls and connected over VPN tunneling through that firewall appliance.

Rackspace supports a Virtual Private Network (VPN) only if it is through a hardware firewall in a solution called RackConnect. It is easier to implement this physical firewall setup before you create servers because, at the time this article was written, the process that connects the firewall and the servers is automated during the build process. Physical firewalls are not provisioned as quickly as cloud servers and must be requested through our Hybrid teams. For more information about physical firewalls and RackConnect, see https://www.rackspace.com/cloud-connectivity/rackconnect/.

If you do install Active Directory on a cloud server, we recommend that you run two domain controllers in case one fails (imaging is currently unavailable for domain controllers). We also recommend locking down DNS to prevent DNS amplification attacks.

SQL Server instances

For servers running Microsoft SQL Server®, lock down the SQL port 1433 to listen over the internal interface only, preferably listening only for connections from a list of known IP addresses of other servers needing to access SQL Server on the server. You can allow SQL port 1433 to listen over the public interface, but you must limit this rule to only the IP addresses of the computers where the developers are connecting to the databases on the server.

If you don’t limit these connections to the server, port 1433 is exposed and outside hackers will attempt a brute-force attack on the server over this port. These types of attacks cause high network traffic, slow the server’s performance, and even bring down sites if an important account gets locked out. By limiting access to this port, you mitigate these issues before they start.

For servers running SQL Server Standard or SQL Server Web editions, we recommend configuring maintenance plans to dump the data from the live database files into flat files that you can back up off the server and to clean up the backups so they do not fill your hard drive.

Windows updates

Ensure that Windows updates are enabled, and be mindful of the state of your server— ensure that your Windows operating system (OS) is patched. Patch Tuesday, which occurs on the second Tuesday of each month in North America, is the day on which Microsoft regularly releases security patches. Customers must decide how best to implement a patching strategy that keeps their servers up-to-date. By default, Rackspace Cloud Servers check for updates between 2 AM and 4 AM every day.

Server backups

Set up some type of disaster recovery plan. One option that we offer is to create cloud server images nightly and write them to your Cloud Files containers with a default retention of seven days. You take a snapshot of the server and store the image in Cloud Files for use in creating new server instances or rebuilding the existing server from that image.

We also offer file-level backup through Cloud Backups. We don’t recommend backing up the entire C: drive because live files that are locked cause the backup job to complete with errors. Furthermore, the Windows system files are contained in the base images provided by us or in any custom images taken of the servers, so you don’t need to back up that data on a daily basis. We do recommend backing up the C:\inetpub (IIS) directory and any other user data that needs to be backed up. Additionally, if you configured SQL Server maintenance plans to dump the live data into flat files for backups, we recommend that you also include those directories in the backup.

Check backup jobs to ensure that they complete successfully and that the backups are valid. Create a new server instance from an image to ensure that the image is valid, and restore a file from Cloud Backups to verify that the data backed up is restored.

Note: Not all servers can benefit from Cloud Images. Specifically, you cannot image servers that use Boot from Volume configurations. Additionally, while a server image can be useful, images should never be considered the only source of backup because the image process does not verify the file integrity. Rackspace strongly recommends file-level backups for your most important data. Thus, you should consider the best solution for disaster recovery for your business. You can review the differences between Server Images and Cloud Backup in this article: Rackspace Cloud Backup vs. Cloud Server Image Backups

The last attack surface exposed to the Internet is the code. You and your developers must ensure that your code is enforcing proper authentication and authorization. For example, you should not allow a web application to be executed with administrator-level privileges. File authorization should be carefully defined, and all inputs on the application should have the best validation possible to prevent hackers from exploiting the web application and gaining control of the server.

The following sites provide information about improving ASP.NET security:

Conclusion

Depending on the use case, customers might have other more specific needs to address when leveraging our Cloud Servers service to meet their hosting needs. However, these general recommendations are a good start when considering security while creating Windows servers, cloud or otherwise.

Share this information:

©2020 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License

Best practices for securing Active Directory Federation Services

This document provides best practices for the secure planning and deployment of Active Directory Federation Services (AD FS) and Web Application Proxy. It contains information about the default behaviors of these components and recommendations for additional security configurations for an organization with specific use cases and security requirements.

This document applies to AD FS and WAP in Windows Server 2012 R2 and Windows Server 2016 (preview). These recommendations can be used whether the infrastructure is deployed in an on premises network or in a cloud hosted environment such as Microsoft Azure.

Standard deployment topology

For deployment in on-premises environments, we recommend a standard deployment topology consisting of one or more AD FS servers on the internal corporate network, with one or more Web Application Proxy (WAP) servers in a DMZ or extranet network. At each layer, AD FS and WAP, a hardware or software load balancer is placed in front of the server farm and handles traffic routing. Firewalls are placed as required in front of the external IP address of the load balancer in front of each (FS and proxy) farm.

AD FS requires a full writable Domain Controller to function as opposed to a Read-Only Domain Controller. If a planned topology includes a Read-Only Domain controller, the Read-Only domain controller can be used for authentication but LDAP claims processing will require a connection to the writable domain controller.

Ports required

The below diagram depicts the firewall ports that must be enabled between and amongst the components of the AD FS and WAP deployment. If the deployment does not include Azure AD / Office 365, the sync requirements can be disregarded.

Note that port 49443 is only required if user certificate authentication is used, which is optional for Azure AD and Office 365.

Port 808 (Windows Server 2012R2) or port 1501 (Windows Server 2016+) is the Net.TCP port AD FS uses for the local WCF endpoint to transfer configuration data to the service process and Powershell. This port can be seen by running Get-AdfsProperties | select NetTcpPort. This is a local port that will not need to be opened in the firewall but will be displayed in a port scan.

Azure AD Connect and Federation Servers/WAP

This table describes the ports and protocols that are required for communication between the Azure AD Connect server and Federation/WAP servers.

Protocol	Ports	Description
HTTP	80 (TCP/UDP)	Used to download CRLs (Certificate Revocation Lists) to verify SSL certificates.
HTTPS	443(TCP/UDP)	Used to synchronize with Azure AD.
WinRM	5985	WinRM Listener

WAP and Federation Servers

This table describes the ports and protocols that are required for communication between the Federation servers and WAP servers.

Protocol	Ports	Description
HTTPS	443(TCP/UDP)	Used for authentication.

WAP and Users

This table describes the ports and protocols that are required for communication between users and the WAP servers.

Protocol	Ports	Description
HTTPS	443(TCP/UDP)	Used for device authentication.
TCP	49443 (TCP)	Used for certificate authentication.

For additional information on required ports and protocols required for hybrid deployments see the document here.

For detailed information about ports and protocols required for an Azure AD and Office 365 deployment, see the document here.

Endpoints enabled

When AD FS and WAP are installed, a default set of AD FS endpoints are enabled on the federation service and on the proxy. These defaults were chosen based on the most commonly required and used scenarios and it is not necessary to change them.

[Optional] Min set of endpoints proxy enabled for Azure AD / Office 365

Organizations deploying AD FS and WAP only for Azure AD and Office 365 scenarios can limit even further the number of AD FS endpoints enabled on the proxy to achieve a more minimal attack surface. Below is the list of endpoints that must be enabled on the proxy in these scenarios:

Endpoint	Purpose
/adfs/ls	Browser based authentication flows and current versions of Microsoft Office use this endpoint for Azure AD and Office 365 authentication
/adfs/services/trust/2005/usernamemixed	Used for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint.
/adfs/services/trust/13/usernamemixed	Used for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint.
/adfs/oauth2	This one is used for any modern apps (on-prem or in cloud) you have configured to authenticate directly to AD FS (i.e. not through AAD)
/adfs/services/trust/mex	Used for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint.
/adfs/ls/federationmetadata/2007-06/federationmetadata.xml	Requirement for any passive flows; and used by Office 365 / Azure AD to check AD FS certificates.

AD FS endpoints can be disabled on the proxy using the following PowerShell cmdlet:

Extended protection for authentication

Extended protection for authentication is a feature that mitigates against man in the middle (MITM) attacks and is enabled by default with AD FS.

To verify the settings, you can do the following:

The setting can be verified using the below PowerShell cmdlet.

The property is ExtendedProtectionTokenCheck . The default setting is Allow, so that the security benefits can be achieved without the compatibility concerns with browsers that do not support the capability.

Congestion control to protect the federation service

The federation service proxy (part of the WAP) provides congestion control to protect the AD FS service from a flood of requests. The Web Application Proxy will reject external client authentication requests if the federation server is overloaded as detected by the latency between the Web Application Proxy and the federation server. This feature is configured by default with a recommended latency threshold level.

To verify the settings, you can do the following:

1. On your Web Application Proxy computer, start an elevated command window.
2. Navigate to the ADFS directory, at %WINDIR%\adfs\config.
3. Change the congestion control settings from its default values to .
4. Save and close the file.
5. Restart the AD FS service by running net stop adfssrv and then net start adfssrv . For your reference, guidance on this capability can be found here.

Standard HTTP request checks at the proxy

The proxy also performs the following standard checks against all traffic:

• The FS-P itself authenticates to AD FS via a short lived certificate. In a scenario of suspected compromise of dmz servers, AD FS can «revoke proxy trust» so that it no longer trusts any incoming requests from potentially compromised proxies. Revoking the proxy trust revokes each proxy`s own certificate so that it cannot successfully authenticate for any purpose to the AD FS server
• The FS-P terminates all connections and creates a new HTTP connection to the AD FS service on the internal network. This provides a session-level buffer between external devices and the AD FS service. The external device never connects directly to the AD FS service.
• The FS-P performs HTTP request validation that specifically filters out HTTP headers that are not required by AD FS service.

Recommended security configurations

Ensure all AD FS and WAP servers receive the most current updates The most important security recommendation for your AD FS infrastructure is to ensure you have a means in place to keep your AD FS and WAP servers current with all security updates, as well as those optional updates specified as important for AD FS on this page.

The recommended way for Azure AD customers to monitor and keep current their infrastructure is via Azure AD Connect Health for AD FS, a feature of Azure AD Premium. Azure AD Connect Health includes monitors and alerts that trigger if an AD FS or WAP machine is missing one of the important updates specifically for AD FS and WAP.

Information on installing Azure AD Connect Health for AD FS can be found here.

Additional security configurations

The following additional capabilities can be configured optionally to provide additional protections to those offered in the default deployment.

Extranet «soft» lockout protection for accounts

With the extranet lockout feature in Windows Server 2012 R2, an AD FS administrator can set a maximum allowed number of failed authentication requests (ExtranetLockoutThreshold) and an observation window s time period (ExtranetObservationWindow). When this maximum number (ExtranetLockoutThreshold) of authentication requests is reached, AD FS stops trying to authenticate the supplied account credentials against AD FS for the set time period (ExtranetObservationWindow). This action protects this account from an AD account lockout, in other words, it protects this account from losing access to corporate resources that rely on AD FS for authentication of the user. These settings apply to all domains that the AD FS service can authenticate.

You can use the following Windows PowerShell command to set the AD FS extranet lockout (example):

For reference, the public documentation of this feature is here.

Disable WS-Trust Windows endpoints on the proxy i.e. from extranet

WS-Trust Windows endpoints (/adfs/services/trust/2005/windowstransport and /adfs/services/trust/13/windowstransport) are meant only to be intranet facing endpoints that use WIA binding on HTTPS. Exposing them to extranet could allow requests against these endpoints to bypass lockout protections. These endpoints should be disabled on the proxy (i.e. disabled from extranet) to protect AD account lockout by using following PowerShell commands. There is no known end user impact by disabling these endpoints on the proxy.

Differentiate access policies for intranet and extranet access

AD FS has the ability to differentiate access policies for requests that originate in the local, corporate network vs requests that come in from the internet via the proxy. This can be done per application or globally. For high business value applications or applications with sensitive or personally identifiable information, consider requiring multi factor authentication. This can be done via the AD FS management snap-in.

Require Multi factor authentication (MFA)

AD FS can be configured to require strong authentication (such as multi factor authentication) specifically for requests coming in via the proxy, for individual applications, and for conditional access to both Azure AD / Office 365 and on premises resources. Supported methods of MFA include both Microsoft Azure MFA and third party providers. The user is prompted to provide the additional information (such as an SMS text containing a one time code), and AD FS works with the provider specific plug-in to allow access.

Supported external MFA providers include those listed in this page, as well as HDI Global.

Hardware Security Module (HSM)

In its default configuration, the keys AD FS uses to sign tokens never leave the federation servers on the intranet. They are never present in the DMZ or on the proxy machines. Optionally to provide additional protection, these keys can be protected in a hardware security module attached to AD FS. Microsoft does not produce an HSM product, however there are several on the market that support AD FS. In order to implement this recommendation, follow the vendor guidance to create the X509 certs for signing and encryption, then use the AD FS installation powershell commandlets, specifying your custom certificates as follows:

• CertificateThumbprint is your SSL certificate
• SigningCertificateThumbprint is your signing certificate (with HSM protected key)
• DecryptionCertificateThumbprint is your encryption certificate (with HSM protected key)

—>