Securing Administrator Access to Internal Windows Servers

Securing Administrator Access to Internal Windows Servers

Contents 1. Introduction... 3 2. PKI implementation... 3 Require two-factor authentication for computers... 3 Require two-factor authentication for users... 5 3. OTP implementation... 5 4. Emergency cases... 6 5. Conclusion... 7

1. Introduction The present document contains some advice on securing the administrator access to internal servers in a Windows environment with two-factor authentication. It can be used to secure access to sensitive servers such as Domain Controllers, Active Directories, Certificate Authorities or databases. 2. PKI implementation Strong authentication can be enforced either at the user level or at the computer level. In both cases, the user trying to authenticate with a simple password will be denied access and the following error message will be displayed. Error message displayed when a user authenticating with a password has been denied access Require two-factor authentication for computers It can be set as a Domain GPO or Local GPO. Below is an example of a GPO applied to a computer APP1. 2-factor authentication GPO applied to a computer

To enforce smart card authentication, enable Interactive logon: Require smart card in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options as shown below. Configuring the GPO to require smart card When the GPO is not defined, the local policy Interactive logon: Require smart card can be set in Local Policies -> Security Options. This setting is not available on Domain Controllers. Configuring the local computer policy to require smart card

Require two-factor authentication for users This can be set in the AD user account properties by enabling Smart card is required for interactive login as shown in the screenshot below: Active Directory settings to require a user to authenticate with a smart card When this option is enabled, Windows sets the user account with a very complex password which is not disclosed to the user. Because some less sensitive applications may not support smart card authentication, the administrators may have 2 accounts, one requiring smart card which gives access to sensitive server and a normal user account. 3. OTP implementation An OTP implementation is similar in many ways to the PKI implementation. The GPO can be used in the same way to enforce strong authentication to a resource but it can t be set at the user level. The AD setting can also be used if the OTP server is not configured to delegate the password verification to the AD. As shown below, OTP and PKI authentication can even live side-by-side:

Windows Logon with OTP and PKI authentication tiles Here are a few points to take in consideration when choosing between OTP and PKI for strong authentication for this use case: - The PKI implementation requires a physical device to be connected to the client/remote client. - The OTP Windows Logon supported only on Windows 7 and Windows Server 2008 R2. - The OTP Windows Logon is not compatible with RDP yet. We are working on solving this technical issue with Microsoft. - The OTP Windows Logon does not support offline authentication. PKI smart card credentials are cached and can be used even if the network is down. 4. Emergency cases It is important to ensure the availability of the strong authentication infrastructure to ensure the system is accessible at all times. For the PKI implementation, it means, for example, to have the CRL (Certificate Revocation List) always accessible. For the OTP implementation, it means, for example, having an OTP server in the same physical location as the resource being accessed in case the inter-communication between datacenters is down. In some rare cases, the strong authentication may not be available and a fall back will be required. For example, all the network cards on a server are failing and the machine cannot access the CRL or the OTP server. - For the PKI implementation, a smart card with a long life certificate (eg: 10 years) can be created and stored in a safe. If the administrator certificates were not renewed in time, this emergency card can be used. - If the smart card is required at the user level, a special user with a known extremely complex password can be created and its credentials stored in a safe. The password can also be split and stored in two different locations. In case of emergency, this account can be used to access the server. - As a last resort, booting in safe mode or booting from a Linux CD can also be used. This does not apply to Domain Controllers.

5. Conclusion Requiring PKI smart card authentication at the user level makes it easier to recover from a situation where the strong authentication is not available but it requires the administrators to be careful managing the user accounts that can access these servers. Requiring strong authentication (PKI or OTP) at the computer level is a safer way to ensure nobody can access a resource with a single factor of authentication but it may be more complex to recover from the unavailability of the strong authentication system.