Implementing access management in Windows servers

The concept of building a solid access foundation is critical as it relates to server management as part of the overall infrastructure. You must consider everything, from physical access to the servers to protecting unified management consoles for managing multiple virtual servers at once. In the next few sections, we will discuss physical access and user access to the infrastructure and the importance of each. Next, we will discuss privileged isolation through a tiered model approach and provide an overview of privileged access management (PAM) and privileged identity management (PIM) solutions. Implementing these tools will help you provide a robust system of server access management. It is highly recommended that you become familiar with the topics mentioned in this section and understand how critical they are when implemented in your organization. First, let's look at physical access and security.

Physical and user access security

An important factor to consider with the on-premise model is to ensure all physical access to any server locations is protected and only accessible to those defined through their role. Your Windows servers and other physical infrastructure are typically located in a server room, a closet in your office building, or in a remote facility that is under your ownership. Because of this, it is equally important that well-enforced security access controls are in place, in addition to server hardening. The physical access needs to be locked down to avoid equipment being stolen and help prevent insider attacks that could open an opportunity for malware to be installed, such as a keylogger through a USB device. Encryption needs to be enabled on all Windows servers in the event theft does occur to help circumvent any information from being stolen.

Tip

Don’t forget that your facility management and physical site access policies are just as important as your user access management to the servers.

As you make your move into the cloud world, your access management changes considerably. Physical access is now the responsibility of the cloud provider. The challenge is, how do you validate they are protecting your data with the utmost standards? This is where your contracts come into play, but more importantly, your due diligence, as it relates to audit requirements and SaaS questionnaires being provided by the cloud provider. We will cover audits in more detail in Chapter 13, Testing and Auditing.

The next consideration with the cloud model is management planes. On-premises deployments allows management solutions to be isolated from the internet and only accessible from your corporate network. With the cloud, the management pane and unified portals are internet-accessible and provide a single pane where you can access all your resources in one place, including your Windows servers. The downside? Anyone who compromises your access could have the keys to the kingdom. This is where a very stringent access policy is needed for your privileged identities. You need to ensure your regular user accounts are separate from your privileged accounts and that you enforce extremely strong access controls on your privileged accounts – no exceptions! The number of privileged accounts in your environment should be limited. Role-based access control (RBAC) needs to be defined if you wish to carve out a scope of who needs to access what resource.

Tip

Ensure that you separate privileged accounts from standard user accounts. No employee should ever use their regular identity to administer the environment.

Next, let's look at securing access using privileged access management, just-in-time access, and privileged identity management.

Privileged Access Management, Just-in-Time Access, and Privileged Identity Management

Continuing from the previous tip on identity, let's introduce three critical access models that need to be considered for implementation within your server environment. Privileged Access Management (PAM), Just-In-Time (JIT) access, and Privileged Identity Management (PIM) are all privileged access models that provide an additional layer of protection to your admins while they access your infrastructure. These models help ensure that privileged user accounts are only available as needed, have an expiration date regarding their usage, and are fully audited and monitored when accessing Windows. Privileged accounts can be your weakest link if they're not protected properly and investing in these models should be a requirement.

We will cover each of these models in full detail in Chapter 7, Identity and Access Management.

Equally as important as implementing an access management solution is creating a segregation layer between your servers. To do this, organizations architect a tiering model to isolate different groups of servers based on its criticality to the infrastructure. In the next section, you will learn about using a tiered model and what it means for privileged access security.

Using a tiered model for privileged access

The concept of the tiered model is to isolate and build layers of containment between the Windows systems in your environment. This is accomplished through Active Directory (AD) Organizational Units (OU) by designing a structure that is pided into three or more parent containers. They are labeled tier 0, tier 1, and tier 2. Tier 0 contains the systems, accounts, and security groups of the highest security concern such as domain controllers, Azure AD connect servers, and identity management systems. The goal of this isolation or "tiered" approach is to prevent escalation by provisioning account access to only the tier they need access to in order to perform an operation. If an account from a lower tier gets compromised, its elevation will be restricted to its assigned tier or lower in the model. For example, a user account in tier 1 will only access systems in tier 1 or tier 2. They wouldn't be allowed access to tier 0. Let's review each of the tiers in a three-tier model in more detail.

Tier 0

Tier 0 (top level) typically contains a small number of assets and those deemed critical to your infrastructure. Admins in tier 0 usually have administrative rights to each level tier below. Here, an actor can exhibit domain dominance if breached and have direct control over your environment. We would want to limit the use of and accessibility to tier 0 servers as much as possible and limit the number of accounts with provisioned access. Further logon and access restrictions should also apply to assets in tier 0 to ensure only clean sources are accessing them, including the restriction to the use of non-critical functions from these servers such as checking email or browsing the internet. Organizations should deploy a privileged access management solution within the server environment. The PAM solution must include password rotation, an approval request flow process, auditing logs, session recording, and even remote RDP or SSH launchers where credentials are hidden.

Tip

To take this a step further, restrict the use of non-critical functions such checking email or browsing the internet. Implement application control policies through Windows Defender Application Control to prevent unauthorized software from running. You can also limit access to systems by funneling traffic through SSH proxies from a PAM solution.

Tier 1

Tier 1 is your middle tier and contains systems such as business servers, file servers, web application servers, and database servers. Administrators with access to tier 1 will be able to control servers in both tier 1 and tier 2. These servers need to be protected with similar precautions as the ones outlined for tier 0. When architecting the organizational structure of the tiered model, create child Organizational Units (OU) nested under the tier 1 parent and label them by business unit, application name, or function. Group policy can be used to define restricted groups that explicitly grant access permissions to security groups created and named to fit the labeling schema. Group members have access rights to RDP and only log on interactively to these defined tier 1 servers and not all servers in the tier 1 hierarchy. This provides more granularity and levels of organization. It may be necessary to restrict the use of non-critical functions from these servers such as checking emails or browsing the internet. Certain precautions need to be taken in the event an account becomes compromised. A best practice is to implement a PAM solution where an administrator is required to check out a different account to access these systems altogether. Once the account is checked back in, the password is immediately rotated. This creates a separation of privileges.

Tier 2

Tier 2 (bottom level) will contain more common devices seen in the everyday workplace. This includes end user workstations, laptops, printers, and virtual desktops. This tier is used by your level 1 support desk and field IT employees. Tier 2 administrators should only be allowed to log on to assets that are in tier 2 or lower if they exist. In Chapter 7, Identity and Access Management, we'll discuss implementing access management in more detail, including a discussion around local administrative access to workstations. Depending on your environment, the approach may differ, as there are unique considerations for each environment.

The following screenshot shows an example of an OU structure that is recommended to support the tiered model approach. As you can see, in tier 0, there are separate OUs for admin accounts and server objects. This helps when creating policies that are either user targeted or computer targeted:

Figure 3.5 – An example OU structure of a tiered model approach

Now, let's look at some important things to consider.

Important considerations

Regardless of how many tiers are in the access model, there are important considerations worth discussing. Coupled with the tiered approach, each consideration – inpidually or combined – can add a substantial layer of security to your Windows systems. Let's take a look:

• For RDP and interactive logon scenarios, the source should be restricted to a privileged access workstation (PAW) or isolated management environment requiring a form of biometric or multifactor authentication.
• Network restrictions should be considered in tier 0 access scenarios by locking down incoming RDP connections and other management ports to sources from known VNETs, subnets, and workstations.
• When designing your tiered solution, be mindful and think about built-in security groups with escalated permissions such as Enterprise Admins, Domain Admins, Schema Admins, and Server Operators, to name a few.
• Local accounts can also become a problem if they’re not managed properly and are an easy way for someone to create a backdoor without your knowledge. A PAM solution with discovery alert rules can be used to notify security teams when these accounts are created. If you’re leveraging local accounts in an Active Directory domain, you can also implement Microsoft’s Local Admin Password Solution (LAPS) to rotate passwords.
• Implement fine-grained password policies per tier to enforce stricter password requirements for administrative accounts.
• Leverage security baselines and group policy to further restrict access using defined restricted groups. Lock down logon types where credentials are exposed such as remote desktop or RunAs (interactive) so that they only come from trusted sources such as a PAW.

By using services from the Azure cloud, privileged access workstations can be deployed using a virtualized desktop service such as Windows Virtual Desktop or Citrix. Azure also has PaaS offerings available to cater for this scenario, such as the Azure Bastion service. Azure Bastion allows you to securely RDP or SSH directly to virtual machines over SSL, eliminating the need to expose your servers directly to the internet. This can all be done directly in the Azure portal, with no additional infrastructure. For on-premises installations, an enhanced security administrative environment (ESAE) can be used to administer the production forest.

Enhanced security administrative environment

The next design we will review is the ESAE administrative forest model. At a high level, you will set up a separate Active Directory forest that will be used for administrative purposes only. In this forest, you will build your user accounts and groups that will be provided with privileged access in the production user forest to complete any administrative tasks. To enable cross-forest access, one-way trust is created from the production user forest to the administrative forest. This allows the privileged administrator accounts to manage the production user forest. With this approach, you can completely isolate your privileged accounts from your standard user accounts, reducing the risk of compromise with elevated access within your production environment. This architecture, which is outlined in the following diagram, is also used by Microsoft's cybersecurity professional services teams to protect its customers:

Figure 3.6 – The ESAE model

There is a lot more involved in setting up these models for your environment. To review additional details on both the tiered model and ESAE model for privileged access security, visit https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material.

Tip

Both models require time and investment to implement correctly. It is easy to fall back and apply elevated access to standard users and over permission accounts to meet deadlines and so on. Don’t fall into this trap! Ensure you spend time implementing these models correctly from the ground up and clearly define the account provisioning process. Enforcing these models will help ensure success with your security and hardening.

Now, let's recap and talk about access management best practices.

Access management best practices

Securing access to your environment can be a long and complex journey with many considerations to keep in mind. Security is an ever-evolving space due to the complexity and frequency of cyberattacks. New tools and services are regularly becoming available for organizations to help drive their business and are for those that simply don't have the resources, funds, or capabilities to deploy the solutions needed to protect them. Here is a high-level list of best practices to keep in mind when thinking about the scope of privileged access for your Windows servers and business services:

• Enforcing multi-factor authentication (MFA) should be at the top of the list. Require MFA for all cloud-based accounts using Azure MFA or another provider. For on-premise servers, you can install Azure MFA Server and have finer control over MFA methods.
• Deploy a Privileged Access Management (PAM) solution.
• Use just-in-time access to assign permissions dynamically and avoid permanent assignment for your privileged accounts. Helpful services include Azure Privileged Identity Management (PIM) coupled with Azure Security Center just-in-time access.
• Have an effective account provisioning and deprovision process. Automate disabling accounts when employees leave the company.
• Frequently audit privileged accounts in your environment.
• Limit the number of administrators. Always consider job role and function when provisioning administrative accounts and ensure the principal of least privilege applies.
• Separate administrative accounts with regular user’s accounts. This will help mitigate credential exposure if the administrator’s workstation becomes compromised.
• Limit access to email and internet browsing when applicable from privileged systems.
• Enforce strict fine-grained password policies on administrative accounts.
• Limit the amount of emergency “backdoor” accounts and monitor their usage.
• Ensure any changes to the environment go through an approval process by a change advisory board. This can include access to highly sensitive systems.

Go here for additional information on securing privileged access: https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access.

Now that you have an understanding of the different models used for access to Windows workstations and servers, next, we will discuss the tools used to help manage them. Although some are common, it is important to be aware of their utility when building baselines and hardening Windows.