Temporary Admin

As you might expect, much that is new in Windows Server 2016 relates to cloud strategies and Microsoft products, whether this be using public cloud offerings with Windows Azure and Office 365, establishing a private cloud with Hyper-V, or linking up your private cloud with public clouds to create a hybrid. Of course, several new features are offered beyond the cloud – in particular, for secure administration. Companies can implement these features immediately after rolling out the new server, without having to update or modify the entire server landscape.

To boost security in the enterprise and support state-of-the-art management in distributed and tenanted environments, Microsoft offers Privileged Access Management (PAM) [1] with the Active Directory service on Windows Server 2016, which means improved management of accounts with special privileges.

The Basics in Place

The Windows security model is complex, and it needs to be to meet a wide variety of requirements. After installing a new server, you will see that it already has some local security groups, such as the local Administrators, Server Operators, Backup Operators, and others. Enterprise networks rely on the Active Directory service. Again, some groups are set up by default by the directory service for management purposes. Enterprise Admins and Domain Admins have the widest ranging authorizations; Account Operators can manage users, computers, and groups, and Domain Users at least allow administrators to restrict the use of resources to users of the domain.

These default groups are typically too generic in larger environments, and even in smaller environments administrators would do well to look into delegation. Although segregation of Active Directory infrastructure management (replication, domain controller, DNS, central policies) and data management (organizational unit structure, group structure), or even self-administration of group or specialist applications, are standard on larger networks, companies of all sizes need to decide what authorizations are required for specific service accounts. For example, it is okay for a VoIP communications solution to manage phone numbers, phone devices, and the matching properties. However, the telephony administrators should not be capable of making changes in other departments.

In other words, every enterprise needs a concept of the administrative role that clarifies the following questions:

• What (administrative) roles exist in the enterprise?
• What administrative interfaces or tools are used for administration purposes?
• What privileges are required where and at what levels?
• What departments or persons should be able to perform the tasks of the respective roles?

When it comes to security in the enterprise, you need to distinguish between inadvertent mistakes and deliberate actions. A good administration concept will help in both cases. To provide protection as well against both inadvertent actions and attacks by viruses, trojans, and other malware, it is important for admins to work with two accounts: A normal user account without escalated privileges is used for working on Office documents, processing email, and browsing the Internet, and an account with advanced privileges, preferably using Run As , is reserved for management consoles and interfaces. Unfortunately, this is not always taken seriously.

PAM Overview

The idea behind PAM is that administrative groups, whether predefined or self-designed, are kept empty and not used on a permanent basis – especially if current activities do not require administrative privileges. In the enterprise, privileged users can typically extend their authorizations if they can justify what they need it for (e.g., to manage a specialist application). However, they may only need these authorizations at certain times – for example, to install or update the specialist application. It is very rare to find processes in place that revoke these rights when the users no longer need them.

PAM takes a different approach: Administrative groups are left empty; administrators and other privileged users can request authorizations for a limited period of time. The request process can be modified in an enterprise-specific way; for example, existing permanent owners of administrative roles receive their privileges automatically, whereas specialist application supporters or project staff need to pass through an approval process. You can define other criteria, such as a requirement for multifactor authentication (e.g., by sending a security code to the requester's cellphone). The authorization is only valid for a predefined period of time.

PAM entails a number of conditions and extends existing technologies. First, PAM needs a forest whose Active Directory is running on Windows Server 2016. Although this would typically mean that large-scale enterprises would be unable to deploy the feature in the foreseeable future, because migrating would involve testing every single application and thus take a lot of time, this is not true here. To use the security features offered by PAM correctly, PAM runs in a dedicated forest, which only has a trust relationship with your production environment (Figure 1). In most environments, a single server would be fine for PAM, but for reasons of redundancy and the ability to restore, you will likely want to deploy at least two servers. The new PAM environment offers the following benefits:

• The forest used for PAM is free from legacy ballast. In existing environments, administrators can never be sure whether their predecessor assigned dedicated privileges to specific accounts, or whether malicious code has affected the domain controller.
• Security can be ensured by segregating the management of the PAM forest from that of the production forest. This means that not even domain administrators can work around the policies defined in the PAM environment.
• Physical security plays a special role for critical systems in particular. This is easier to achieve for a small number of systems than for many distributed systems.
• The PAM environment can be deployed very quickly, whereas migrating a production environment would typically take a great deal of time.

Figure 1: Privileged Access Management gives admins privileges from another forest – but only temporarily.

As experienced admins will already have guessed, PAM requires the highest forest functional level, which in turn requires a matching functional level in the domain, but it makes the conversion easier. PAM has been integrated as an optional feature – just like the Recycle Bin for Active Directory in Windows Server 2008 R2. In terms of the conversion, this means that the administrator can first promote the domain level and then the forest level.

If all this works out, you can then enable the Privileged Access Management Feature (Figure 2). After doing so, you can no longer disable it, very much like the Recycle Bin. The first two steps (promoting the domain of forest levels) can be reverted, however, as long as you have not enabled the PAM feature. In other words, admins can proceed step by step, even though the processes are not critical because of the requirement for a dedicated forest. The reasoning behind the forest level of the new feature is easily found if you look at how it works and the underpinning technologies.

Figure 2: PAM can be enabled as a feature of a Windows Server 2016 forest.

Function and Technologies

When you enable the Privileged Access Management Feature again, much like the Active Directory Recycle Bin, another column is added to the link table of the Active Directory database. This column can be used to set an expiry date for the link (see the box "Changes to the Active Directory Database"). This means that each link (i.e., the relation between a group and a group member) between an employee, their superior, and so on can be set up so that the link only remains valid up to a point in time that can be defined in advance.

Figure 3: Extending the Active Directory database allows time limits to be applied to escalated user privileges.

When a user of the domain logs in to a computer that is also a member of the domain (or a trusted domain), the Security Accounts Manager (SAM) creates a list of Security Identifiers (SIDs) for the user and all groups in which the user is a member.

The same thing happens when the Kerberos ticket (Ticket Granting Ticket, TGT) is renewed; it expires every 10 hours by default. When the user attempts to access the resource, the user's list of SIDs is referenced to grant, restrict, or deny access.

Two new aspects have been added to the process to support PAM. SAM knows the group membership expiry date and only adds SIDs to the user's token if they are still active.

The Kerberos TGT issued to the user contains the expiry time matching the shortest group membership. After this, and in a way that is completely transparent to the user, a new TGT is requested, and a group membership expires abruptly. In contrast to acting group memberships, this revocation does not need to be replicated by the Active Directory domain controllers; each domain controller has the details of when the group membership terminates and can manage it separately.

These requests are handled by the Microsoft Identity Manager (MIM) [2], the successor to the Forefront Identity Manager (FIM). MIM consists of several components, one of which is very important for our topic in this article: an engine for synchronizing directory service data (i.e., keeping user data identical in various Active Directories, cloud services, SAP, etc.); it has been extended to include an option for synchronizing user passwords as well. A self-service portal exists for users, so they can apply for group memberships, among other things. This is extended for PAM.

MIM lets users request authorizations. If the users meets the requirements, or the workflow was approved, they are granted group membership for a temporary period of time. To allow this to happen, the administrative groups are shadows in the PAM forest, where they are listed as "Shadow Principals." Shadow Principals are given the same security identifier (SID) because the group has its own forest. Now, when the user logs in (or the user's Kerberos ticket is renewed), the user also receives the SID of the group that has access to the required resources in the forest.