I’ve been working with Active Directory Administrative Center (ADAC) for a while now, but didn’t have time to look at Delegation of Control lately. Yesterday I finally came round to configuring it and was baffled by a serious issue:

After delegating Account creation to a user, installing the Remote Server Administration Tools (RSAT) on the Windows 7 Enterprise workstation of the user and adding the Active Directory Administrative Center remote management feature on it, the tool wouldn’t work. Actually, the tool would start (slow as always, but would nonetheless start), would show its window, would show the icons for the containers, users, etc, but refused to show the corresponding texts in the Active Directory Administrative Center window. (or, at times, garbling text, rendering it unreadable)

I began troubleshooting the issue.

Messed up delegation?

I previously added the user to the Account Operators group in the domain. Perhaps this issue occurred because I messed up Delegation? Perhaps the user needed more rights? Perhaps a similar bug exists in Windows Server 2008 R2 where the Account Operators for some reason don’t have read rights on the Built-In OU? I checked the security permissions of the user and Account Operators group to the Users, Computers and Built-in containers in Active Directory, using SysInternals’ ADExplorer. I found nothing out of the ordinary and decided to supply the user access to the Active Directory Users and Computers MMC Snap-in (dsa.msc) to check things. After resetting passwords on a couple of test accounts, no Access Denied errors were thrown. I ruled out Delegation of Control as the cause of this issue.

Local administrator privileges needed?

The account I used did not have administrator privileges on the workstation. When starting up the Active Directory Administrative Center (dsac.exe) with the built-in Administrator account I’ve seen User Account Privilege (UAC) prompts, so perhaps the Active Directory Administrative Center needs local administrator privileges?

Adding the user account to the local administrators group and logging off and logging on the user on the workstation, did not resolve the issue, so I reversed the local administrator group membership…

PowerShell or the .Net Framework to blame?

I then started troubleshooting PowerShell. For some reason I found the same issue in the PowerShell ISE (text not showing after typing). I redeployed Windows 7 on the machine and the issue in the PowerShell ISE would reappear. I knew then, the RSAT were not to blame. This was not an Active Directory Administrative Center error!

Since PowerShell can’t be uninstalled and reinstalled in Windows 7, I ruled out blaming PowerShell or the underlying .Net Framework for this error. (else Microsoft would have made an option available to at least reset PowerShell on Windows 7, right?)

I reckoned this might be a display issue, not a PowerShell issue.

Windows Aero doesn’t play nice?

Next thing I checked was whether there was an issue between the Active Directory Administrative Center and Windows Aero. I switched to the Windows 7 Basic theme and restart the box. This is getting dull, since this also did not resolve the issue.

Display driver to blame?

I was on a hunch though, since, next, I decided to check for a newer driver for my display adapter. Sure enough, a new driver was available. I installed the newer display driver and again restarted the box.

After the reboot, I made the user log in and let him fire up the Active Directory Administrative Center (dsac.exe).

Yes!

This time it showed the text as it should be:

Concluding

When working with Active Directory Administrative Center (dsac.exe) and Delegation of Control:

• The Active Directory Administrative Center does not require administrative privileges on a workstation to work remotely through the Remote Server Administration Tools (RSAT).
• The Active Directory Administrative Center works on top of Windows PowerShell. Windows PowerShell cannot be uninstalled in Windows 7.
• Display drivers may cause issues with text display in Windows 7. These issues may affect the Active Directory Administrative Center.

Further reading

Error message when non-administrator users who have been delegated control try to join computers to a Windows Server 2003-based or a Windows Server 2008-based domain controller: "Access is denied"

Microsoft has included numerous features in Active Directory the last couple of years. Also, more and more technologies in products like Exchange Server, SharePoint Server and the Windows client (Windows Vista, Windows 7) have an Active Directory opt-in to store information in Active Directory.

All this bountiful integration, however, comes with a price. The price in the case of Active Directory comes in three guises:

• Operating System (OS) on the Active Directory Domain Controllers (DCs)
• Active Directory Domain Functional Level
• Active Directory Forest Functional Level

The table below shows the dependencies Active Directory features, like Group Policy Preferences, the Active Directory Best Practices Analyzer and Read-only Domain Controllers, and Active Directory opt-in technologies, like BitLocker Recovery Key Storage and DirectAccess, have in regards to the list above:

Red Not Available, Orange Required Set, Green Available, Grey Depends

As we’ve seen in part 4 of this series, Active Directory Domain Services in Windows Server 2012 now sports a grand total of 145 PowerShell Cmdlets. Learning these commands and putting them to good use, might seem like a week’s worth, but actually, the PowerShell History Viewer in the Windows Server 2012 Active Directory Administrative Center (ADAC)helps you get started quickly.

To use this feature, first open the Active Directory Administrative Center (ADAC) on your Windows Server 2012-based Domain Controller, your Windows Server 2012-based Management Server or Windows 8-based Management workstation with the Remote Server Administration Tools (RSAT) installed.

In the right bottom corner of the Active Directory Administrative Center screen, click on the up arrow in the bar called “Windows PowerShell History”. This flicks up a the Active Directory PowerShell History pane. The two screenshots below show the difference between the History viewer opened (right) and closed (left):

Now, when I would create a user, I would see the equivalent of the PowerShell steps involved to do so in the PowerShell History viewer:

As you can clearly, there is minimum of four PowerShell commands involved in creating a user account. If, for instance, you would enable accidental deletion protection, that would amount to a fifth step. Another notable thing is the absence of passwords in the PowerShell History Viewer. Passwords are all filtered out for security purposes.

At the top of the PowerShell History Viewer, there’s a Search field, four commands labeled Copy, Start Task, End Task and Clear All, along with a check box called Show All and the inevitable Help link. Here’s what they do:

• Search
  Within the Search field, you can search in the PowerShell History to find a command. You can insert the first few letters of a Cmdlet and it will show you all the Cmdlets starting with these letters. You cannot search through entered values like first names.
• Copy
  Use this command to copy out selected Cmdlets. You can copy multiple Cmdlets at once by holding down the Ctrl and/or Shift buttons while making your selection.
• Start Task and End Task
  These two commands can be used to group a series of Cmdlets together for easy copying. You can give tasks meaningful names
• Clear All
  This clears the entire history of PowerShell commands in the PowerShell History Viewer.
• Show All
  This checkbox switches between showing only commands manipulating objects (off) and showing all commands, including the commands to browse around in the Active Directory Administrative Console (on). By default, this check box is off to allow for greater overview.

Concluding

The Active Directory PowerShell History Viewer makes it easy to learn the Active Directory PowerShell Cmdlets, by showing the equivalent PowerShell cmdlets, associated with actions in the Graphical User Interface of the Active Directory Administrative Center.

… and that’s not even the cutest trick up ADACs sleeve.

Further reading

PCMag: Hands on: Windows Server 8 
Active Directory Administrative Center: Getting Started  
Introduction to Active Directory Administrative Center Enhancements    
Advanced AD DS Management Using Active Directory Administrative Center 
What is Windows PowerShell History Viewer in Windows Server 2012 
Caution To Be Used With AD Administrative Center PowerShell History Viewer  
Is there a version of the AD tools that provide the PowerShell output 
ServerManager PowerShell History Viewer

A new feature in Windows Server 2008 R2 and the Windows Server 2008 R2 Forest Functional Level (FFL) is the Active Directory Recycle Bin. This feature enables administrators to restore (accidentally) deleted objects, without booting into Directory Services Restore Mode (DSRM) or reanimating objects (with loss of attributes).

How the Active Directory Recycle Bin works

isDeleted and isRecycled

The technology behind the Active Directory Recycle Bin is a new attribute: ‘isRecycled’. Since Windows 2000 Server, when an object, like a computer or user, is deleted, the attribute ‘isDeleted’ is set to true. With the Active Directory Recycle Bin enabled, after the recycle lifetime has expired, the ‘isRecycled’ attribute is also set to true. Then, after the tombstone lifetime has expired, the object is truly removed from the database.

When only the ‘isDeleted’ attribute is set, the object is recoverable through the Active Directory Recycle Bin.

PowerShell

In Windows Server 2008 R2, the only way to manage the Active Directory Recycle Bin is to use PowerShell. If you want to enable the Active Directory Recycle Bin optional feature or restore an object from the Active Directory Recycle Bin, you could only perform these actions with PowerShell.

PowerShell is useful for repeating tasks, so it makes perfect sense to perform the one-time action of enabling the Active Directory Recycle Bin and delete accidentally deleted objects with PowerShell, right?  

What’s New

In Windows Server 2012 you can enable the Active Directory Recycle Bin optional feature and restore objects from the Active Directory Recycle Bin from the Graphical User Interface (GUI). The Active Directory Administrative Center (ADAC) is the tool to perform these actions.

Enabling the Recycle Bin feature from the GUI

You can enable the Active Directory Recycle Bin from within Active Directory Administrative Center, when you’re logged on or use the remote tools with an account that is a member of the Enterprise Admins group.

This feature can be found in the action pane on the right, when the forest name is selected. Another way, is to right-click the domain name in the left pane and select the option Enable Recycle Bin … from the context menu:

You’ll receive a warning, because you won’t be able to rollback enabling the Active Directory Recycle Bin. Click OK. A second pop-up will apear, asking you to refresh the AD Administrative Center. Again, click OK. After you refresh, you will notice a new container underneath the domain root named Deleted Objects.

Restoring objects from the GUI

After you, or another Active Directory admin has deleted an object, the object will become visible in this Deleted Objects container.

Clicking on this folder will open it to display deleted objects. You may find user objects, computer objects, Organizational Units (OUs) and Fine-grained password policy settings in this container.

By right-clicking objects in this container you can restore them to their original location, or restore them to an alternative location:

That last option might come in handy when you’ve deleted a whole Organization Unit (OU) and want to restore only a few objects from that OU in a different location.

Note:
When you restore an object of which the parent object was also deleted, make sure you select the parent object too. The logic behind the Active Directory Administrative Center will restore the whole tree.

Requirements

To enable the Active Directory Recycle Bin optional feature you will first need to fulfill the Active Directory Recycle Bin requirements:

• All Domain Controllers in the forest need to run Windows Server 2008 R2 or Windows Server 2012. You can either transition your current Domain Controller to these Windows Server versions or in-place upgrade them. Alternatively you can start a new Active Directory forest from scratch and migrate your current objects in with the Active Directory Migration Tool (ADMT) or a 3rd party migration tool.
• The Domain Functional Level (DFL) of all domains in the forest need to be at least on the Windows Server 2008 R2 Domain Functional Level. (47)
• The Forest Functional Level (FFL) needs to be on the Windows Server 2008 R2 Forest Functional Level. (47)

Then, you need to unlock the new Active Directory Administrative Center (ADAC). You can do this in the following ways:

• Introduce a Windows Server 2012 Domain Controller. This server will need to be a Full Installation, not a Server Core installation. The Active Directory Administrative Center will be installed as part of the Domain Controller promotion process.
• Introduce a Windows Server 2012 Member Server and add the Active Directory Administrative Center from the Remote Server Administration Tools (RSAT) category in the Add/Remove Server Roles and Features control panel applet. For the purpose of a management server this server is best configured as a Full Installation, instead of a Server Core installation.
• Introduce a Windows 8 Professional installation to your environment and install the Remote Server Administration Tools (RSAT) update package to the installation. After that, enable the Active Directory Administrative Center from the Remote Server Administration Tools (RSAT) category in the Add/Remove Features applet in the Control Panel (right click in the bottom left corner of the screen and select Control Panel to access this feature).

After fulfilling these requirements you can scroll back up to the part in this blogpost where I explain how to enable the Recycle Bin feature from the GUI, and you’re done!

Concluding

With the Active Directory Recycle Bin now configurable through the Active Directory Administrative Center, I’m sure a lot more people will be using the Recycle Bin feature to restore objects. Not having to fumble around in a new feature on the PowerShell command-line (like in Windows Server 2008 R2) will help a lot of people.

Related Microsoft TechEd Videos

SIA319 The Evolution of Active Directory Recovery

Further reading

Two Very Important Attributes with Active Directory Recycle Bin 
Windows Server 2012: “Now Objects Restoration can be done from GUI” 
Active Directory Recycle Bin Step-by-Step Guide      
Active Directory Recycle Bin in Windows Server 2012 – Part 1: Enable 
Active Directory Recycle Bin in Windows Server 2012 – Part 2: Usage 
How to Restore Active Directory Objects on Windows Server 2012 
Windows Server 8 - Active Directory Recycle Bin  
Active Directory Recycle Bin in Windows Server 2012 RC 
Configuring Active Directory Recycle Bin in Windows Server 2012 
Windows Server 2012 – Active Directory Recycle Bin gets a GUI!

As you might be aware, every Microsoft server product has the requirement to be manageable through PowerShell and System Center. The PowerShell requirement is formulated as part of the Common Engineering Criteria (CEC).

With PowerShell available as a version 3 product (and part of Windows Server 2012) it’s time to see how the teams, responsible for the Active Directory products have built their management stories around PowerShell.

Active Directory Domain Services

The Active Directory Domain Services, that we love and loath as the core of our networking infrastructure on our Domain Controllers is manageable through PowerShell scripting. To enjoy PowerShell support in Active Directory Domain Services, it is recommended to manage your Domain Controllers from Windows Server 2012 or from a Windows 8 installation with the Remote Server Administration Tools (RSAT) for Active Directory installed. This way you can enjoy the 135 Active Directory Domain Services management-related PowerShell Cmdlets and 9 Active Directory Domain Services deployment-related PowerShell Cmdlets.

The Active Directory Domain Services team even went a few steps further and incorporated the PowerShell History viewer into the Active Directory Administrative Center (dsac.exe), that helps you discover the PowerShell magic that happens under the hood.

A couple of exceptions still exist, that make it impossible to manage Active Directory Domain Services from the PowerShell prompt completely. Tools like ntdsutil.exe, dsamain.exe, redirusr.exe and redircmp.exe come to mind, almost immediately. On the other end of the spectrum, several other functions in Active Directory Domain Services are only easily manageable with PowerShell. MSAs come to mind, quite to my own surprise...

Active Directory Lightweight Domain Services

The Active Directory Lightweight Domain Services offer specialized Domain Services, targeted at applications and perimeter networks. Their charm is you can manage the Lightweight Directory Services (mostly) with the same tools as you can manage the Directory Services in PowerShell (as long as you install the AD LDS Display Specifiers schema and Display Specifiers by importing MS-ADLDS-DisplaySpecifiers.ldf.).

Alas, the PowerShell learning ability, offered by the Active Directory Administrative Center (dsac.exe), is not available for Active Directory Lightweight Directory Services, since this management tool can not be directed to a Lightweight Directory Services installation.

Since most tools are exchangeable between Lightweight Directory Services and Directory Services, roughly the same exceptions for full PowerShell manageability exist.

Active Directory Certificate Services

Active Directory Certificate Services enable you to run Certification Authorities on Windows Servers. For Windows Server 2012, the team behind Active Directory Certificate Services has developed twelve PowerShell Cmdlets to deploy Certificate Services. Also an additional nine PowerShell Cmdlets were specifically created to manage certificates, but you can also manage these by mounting the Certificate Store as a PowerShell drive, if need be.

In versions of Windows Server earlier than Windows Server 2012, no built-in PowerShell Cmdlets were available to manage Active Directory Certificate Services, but you could rely on certutil.exe to script through them.

Active Directory Federation Services

As was the case with Active Directory Federation Services 2.0, which was a separately downloadable installation, Active Directory Federation Services 2.1, that comes bundled with Windows Server 2012, can be managed through PowerShell. A total of 48 Active Directory Federation Services-related PowerShell Cmdlets are available on Windows Server 2012, covering both deployment and management.

Active Directory Rights Management Services

As you might expect, the Active Directory Rights Management Services in Windows Server 2008 R2 and Windows Server 2012 are also PowerShell-enabled. Three straightforward Rights Management Services deployment-focused PowerShell Cmdlets (appropriately named Install-ADRMS, Uninstall-ADRMS and Update-ADRMS) and 21 Rights Management Services administration-focused PowerShell Cmdlets are at your disposal.

Related blogposts

New features in AD DS in Windows Server 2012, Part 4: New PowerShell Cmdlets 
New features in AD DS in Windows Server 2012, Part 5: PowerShell History Viewer

Further reading

Managing Active Directory with Windows PowerShell 
Active Directory Cmdlets for Windows Server 2008 R2 
AD FS 2.0 Cmdlets for Windows Server 2008 R2  
AD RMS Cmdlets for Windows Server 2008 R2   
AD CS Administration Cmdlets in Windows Server 2012 
AD CS Deployment Cmdlets in Windows Server 2012 
AD DS Administration Cmdlets in Windows Server 2012  
AD DS Deployment Cmdlet in Windows Server 2012  
AD FS Cmdlets in Windows Server 2012  
AD RMS Administration Cmdlets in Windows Server 2012  
AD RMS Deployment Cmdlets in Windows Server 2012

Microsoft introduced Dynamic Access Control (DAC) as its claims-based authorization solution. It’s revolutionary, because it enables admins to more granularly control access to file resources, based on attributes of objects in Active Directory, like department, manager and country, instead of through an elaborate and obscure group membership structure and static Access Control Lists (ACLs) on files and folders.

Tip!
More information on actually configuring Dynamic Access Control can be found here.

If you want to go and use Dynamic Access Control in your environment, I feel you should be aware of these 10 things:

1. Dynamic Access Control is a v1 product.
   While Dynamic Access Control (DAC) is available in the Release to Manufacturers (RTM) version of Windows Server 2012, by no means, this implies the feature is as ready as you need it to be to be able to run it in your production environment. Many organizations hold off on introducing Microsoft technologies until v3 to avoid problems other organizations had with (for instance) Hyper-V in Windows Server 2008, SharePoint Portal Server 2001 and archiving in Exchange Server.
    
   I should not, however, that most of the time, the culprit is not faulty code, but incompatibilities with older platforms and applications. DACs incompatibility with Windows XP for instance, means 40% of organizations cannot deploy claims-based access natively to these clients.
      
2. Dynamic Access Control is currently limited to File Services only.
   While you might look to apply Dynamic Access Control (DAC) to accommodate rich authorization scenarios, with Windows Server 2012, you will only be able to use claims for authorization on File Services only. Claims-based Access Control is not available for Microsoft Exchange or Microsoft SQL Server. The consequence is you will need to deploy both a group membership-based access control solution and Dynamic Access Control throughout your organization.    
      
3. Token bloat is just around the corner with Dynamic Access Control.
   This coexistence, even if you only have File Services in your organization and you can quickly get rid of your group membership-based authorization solution, will lead to an initial growth in the tokens of your colleagues. The improved SID Compression in Windows Server 2012 might be enough to compensate for it, but it also might not. 
      
4. Calculating the expected ticket sizes is no longer straightforward.
   If you want to calculate what the impact on ticket size would be in your situation, then you would have a hard time doing so, because Microsoft KnowledgeBase article 327825 specifically mentions the following:
       
        Dynamic Access Control adds Active Directory Claims to the Ticket. Therefore,
        calculating the expected ticket sizes is no longer straightforward. The expectation
        is that tickets that are issued by Windows Server 2012 domain controllers are
        smaller than the same tickets that are issued from older operating system
        versions. Claims add to the ticket size. However, after Windows Server 2012 file
        servers are using claims broadly, you can expect to phase out a significant 
        number of your groups that control file access to trim ticket sizes.
     
   I think point 2 adequately addresses the issues surrounding the ability to trim ticket sizes.
    
5. Dynamic Access Control offers no Deny rules, only Allow rules.
   Microsoft has shifted from a security point of view on Identity and Access Management, to an access point of view. Instead of securing an environment by limiting people access, in recent Windows (Server) releases, you will have to specifically grant access before anyone can access a resource. The most prevalent situation where you can observe this shift is the difference in standard Share permissions between Windows XP, Windows Server 2003 (R2) and more recent Windows (Server) versions.
     
   From this new point of view, as an admin you won’t have to be using deny rights or permissions. You simply allow the people with the right attributes access.
       
6. Attribute integrity is getting more important
   As a consequence, attribute integrity is getting more important. When you want to allow access to full-time employees (FTEs) only, but lack the proper processes to convert a part-time employee to a full-time one, you will inadvertently deny access to people with even the slightest skew in attributes. Even Microsoft IT faced this problem in their first tests.
   
7. Naming conventions are important when deploying Dynamic Access Control
   Attribute integrity processes depend on naming conventions for locations, departments and descriptions. without them, your claims would not make sense or might not be as specific as you want them to be, because you’d build your claims-based access through ‘contains’ rules, instead of ‘equal to’ and ‘not equal to’ rules to address the situation.
     
8. There’s no built-in way to migrate Dynamic Access Control cross-forest.
   While the rules and policies used to define Dynamic Access Control-based access are stored in Active Directory, the current Active Directory cross-forest migration tool, the Microsoft Active Directory Migration Tool (ADMT) does not support migrating these rules and policies.
     
   When you can foresee a merger, divestiture or migration, putting of your Dynamic Access Control deployment might be a good idea.
       
9. There’s no/little support by 3rd party tools for managing DAC lifecycle.
   With the Dynamic Access Control (DAC) technology on the market for a year, we’re seeing little third parties delivering Dynamic Access Control-capable management tools and/or Dynamic Access Control integration with current 3rd party management tools. 
       
   The NetApp integration with Dynamic Access Control stands in stark contrast to this and its competitors.
     
10. You’ll need a File Classification strategy to fully profit from DAC
    Managing access to unstructured data is not magically more straightforward when you use Dynamic Access Control. However, when you use the File Classification Infrastructure (FCI) technology on Windows Server 2012-based File Servers in combination with Dynamic Access Control (DAC), it’s a different story. You can then grant granular access to files based on their contents. The dark side? You will need a file classification strategy, before you can actually tap into this potential.

A while ago, I wrote a blogpost on the requirements you’d need to meet to take advantage of Active Directory features in Windows Server 2003 through Windows Server 2008 R2. Since Windows Server 2012 was released almost a year ago, it’s time to look at the requirements for Active Directory features in Windows Server 2012.

The table below shows the dependencies Active Directory features, like Active Directory-based Activation, Resource SID Compression, Exposed Distinguished Name Tags (DNTs), Deferred Index Creation, group Managed Service Accounts (gMSAs), Domain Controller Cloning, Kerberos Armoring and Dynamic Access Control (DAC) have:

¹ Active Directory-based Activation requires the Windows Server 2012 schema extensions. This means adprep.exe needs to have been run. To report on Active Directory-based Activation you will need VAMT.

² To point the PowerShell commands to a Domain Controller, this Domain Controller needs to run the Active Directory Web Services (ADWS). This is available since Windows Server 2008 R2 and as a separate download for Windows Server 2003 and Windows Server 2008. ADWS is not available for Server Core installations of Windows Server 2008.

³ You will need to meet the requirements for the Fine-Grained Password Policies to be able to use the Fine-Grained Password policies GUI. The Domain Functional Level will need to be Windows Server 2008, to be able to utilize this feature.

⁴ You will need to meet the requirements for the Active Directory Recycle Bin to be able to use this feature. The Forest Functional Level will need to be Windows Server 2008 R2, to be able to utilize this feature.

⁵ Computers used by colleagues to access the service need to run Windows XP or later. Front-end servers need to run Windows Server 2012. Back-end server accounts need to be configured with accounts that are permitted for impersonation.Back-end application servers need to be running Windows Server 2003 or later.

⁶ The Domain Controller will need to be deployed the Active Directory Module for Windows PowerShell feature installed. The Windows Server 2008 R2 Domain Functional Level is recommended for automatic password and SPN management.

⁷ To activate the Virtualization safeguards, the Domain Controller needs to be run on a VM-GenerationID-capable virtualization platform and the Integration Components / Tools need to be installed and running.

⁸ The source Domain Controller needs to be run on a VM-GenerationID-capable virtualization platform and the Integration Components / Tools need to be installed and running. A Windows Server 2012 Domain Controller with the PDC emulator (PDCe) Flexible Single Master Operations (FSMO) role should be available to the destination Domain Controller during cloning.

⁹ Requires djoin.exe on Windows 8, Windows RT or Windows Server 2012, that needs to be run by a user account with sufficient permissions to create computer accounts.

¹⁰ The RID Pool Master Flexible Single Master Operations (FSMO) needs to be run held by a Windows Server 2012-based Domain Controller for this functionality.

¹¹ When FAST is enabled, Windows 8 clients will only communicate with Windows Server 2012 Domain Controllers. This might create a pile-on effect. Therefore, ensure you have sufficient Domain Controllers to prevent authentication traffic passing Active Directory site links.

¹² File Servers with access based on claims need to run Windows Server 2012 and have the File Server Resource Manager (FSRM) Role Service installed.

Related blogposts

Active Directory Feature Requirements
List of Hypervisors supporting VM-GenerationID  
Applicability of Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs)

As mentioned earlier, I had the privilege of being invited to speak at Microsoft Serbia’s Sinergia 2014 event at the Crowne Plaza hotel in Belgrade, last October. With a little more room in my schedule, I can finally share some pictures of this event.

I flew from Amsterdam to Belgrade on Sunday October 19th. After an uneventful Air France flight over my home town, I had a layover at Paris Charles de Gaulle airport, where I had my first experiences with flying Air Serbia. Due to the 45-minute walk between terminals, I arrived in the nick of time to get boarded. I was seated in the last row on that flight.

I arrived at Nikola Tesla Belgrade Airport slightly after 10 PM. I was greeted at the airport and brought to the Crowne Plaza hotel in Novi Beograd.

This is where I met a nice (new) room and my head met a bed on the 6th floor. This is a Sleeping Advantage floor.

The next morning, after enjoying the view and breakfast, I picked up the conference bag, shirt and badge.

This was the first day of Sinergija 2014. The Keynote with Damian Caro, technical evangelist for Microsoft, was the first session presented:

According to the schedule, my first session ‘10 most common mistakes when deploying AD FS’ was up at 1PM. I decided to get ready for it by reviewing the slides, demos and presentation room. (Aegean). Then, I presented the session to a 50-person audience in a 70-person room. Fun, but alas no pictures…

After the sessions, Microsoft Serbia invited the speakers and organizers for dinner at Biber Restaurant, which gave me the opportunity to catch up with Aleksandar Nikolić and meet Romeo Mlinar.

The next morning, my presentation ‘Virtualization-safer Active Directory and DC Cloning’ was up in the first time slot:

Feeling energized from this session, I decided to get some work done afterwards in the speaker room:

As the (technical part of) Microsoft Sinergija 2014 drew to an end, everyone I knew and met left the venue. I had a nice dinner in the hotel’s restaurant and went to bed afterwards, knowing my flight back to the Netherlands would leave at 6:40 AM and I had an appointment with my chauffeur at 4 AM to drive me to the Airport.

Of course, all appointments were met and I was one of the first people at Nikola Tesla Airport that morning. Also, being the first person to board the Air Serbia flight, I was seated in Economy Comfort, in the front of my class. You gotta love these airlines…

Flying back, I realized I had a great time in Serbia and a lot of fun.

Thanks Aleksandar and Sinergija team!

Microsoft has invested three years of development time in Windows Server 2012 and has introduced a slew of Active Directory features, including claims-based authorization to files and folders, a new licensing solution, safe virtualization, Kerberos armoring, cross-forest KCD and group MSAs. I’ve published a whitepaper on this stuff last year.

Hot on the heels of the release of Windows Server 2012, Microsoft released Windows Server 2012 R2. In terms of software development cycles, you might not expect a lot of improvements in Windows Server 2012 R2; Between Windows 2008, Windows Server 2008 R2 and Windows Server 2012, the product teams at Microsoft always had a large amount of time available to plan features, build features and test them thoroughly in many different implementation scenarios.

Even I was skeptical, especially since the work that was put in Windows Server 2012; that work justifies the ‘major revision’ moniker in terms of Active Directory… The opposite is true, however: Windows Server 2012 R2 introduces many new Active Directory and identity-related features.

I will show you these new features in this article series, along with their possibilities and impossibilities, the way you can benefit from them in your own networking environment, their common pitfalls and, of course, basic best practices for deployment and management.

Join me!

Overview

In this first post, I’m providing an overview of the features.

This way, you can quickly see which features may be relevant to you and your situation, and, thus, should be the ones you might want to check out first.

Security-related features

Although Active Directory is not an insecure product or technologies, Microsoft has made some nice security improvements, that will draw the attention of every CIO:

LSASS.exe memory protection

One of the favorite demos used in the Security tracks of TechEd have been to inject cached password hashes back into the Windows security authority. Lsass.exe, acting as the Local Security Authority process was one of the locations where malicious people would be able to take password hashes from. In Windows Server 2012 R2 and Windows 8.1, Microsoft has built a memory protection feature, that helps to remove cached password hashes.

Protected Users

The Protected Users group is a new group, that accommodates the security needs of privileged user accounts. When a user or a group of users is made member of the Protected Users security group, a series of non-configurable security measures are applied, including the inability to further authenticate using older and weak authentication protocols, and use older and weak encryption protocols.

Authentication Policies and Authentication Policy Silos

Authentication Policies and Authentication Policy Silos are another means to secure an Active Directory-based environment. In contrast to the limited Log on to: management capabilities in previous versions of Windows, with Authentication Policies and Authentication Policy Silos you can create a group of computers to which a (group of) user(s) can log on to.

… and there’s more. You can also control the TGT lifetime and criteria for devices and the method used for authentication.

Management features

In terms of managing Domain Controllers, ADFS Servers and Certification Authorities (CAs), Microsoft has added some new management features.

Of course, the big news is that Windows 8.1 and Windows Server 2012 R2 come with PowerShell version 4.0. It’s big feature is the Desired State Configuration (DSC), but that largely doesn’t apply to Active Directory.

In PowerShell 4.0, however, Microsoft is including a load more PowerShell Cmdlets to manage Active Directory. Growing from 135 available Active Directory-related PowerShell Cmdlets in Windows Server 2012 to 147 available Active Directory-related PowerShell Cmdlets in Windows Server 2012 R2, twelve new Cmdlets have been introduced. These new Cmdlets allow you to manage the previously mentioned Authentication Policies and Authentication Policy Silos features through PowerShell, but also through the PowerShell history viewer, that is available in the Windows Server 2012 R2 Active Directory Administrative Center (dsac.exe).

BYO features

In the whole of Bring-Your-Own features in Windows Server 2012 R2, Workplace Join is the main Active Directory feature. It supplements Active Directory Federation Services-based claims-based access control, Work Folders, the Device Registration Service and the Web Application Proxy directly, and also brings claims-based technology to Multi-factor Authentication, System Center and Windows Intune.

Claims-based authentication is the future of Identity and Access Management (IAM). The combined family of on-premises Active Directory products and technologies (Active Directory Domain Services, Active Directory Lightweight Directory Services, Active Directory Federation Services, Active Directory Rights Management Services and Active Directory Certificate Services) and their cloud-based counterparts (Windows Azure Active Directory and Azure Active Directory Rights Management Services) aligns your networking infrastructure perfectly with this long-term trend.

Environment-wide improvements

Migrating an Active Directory infrastructure is a challenge, but Microsoft has made several steps significantly easier in the past few Windows Server iterations. Microsoft has done away (mostly) with dependencies on domain functional levels and forest functional levels, to help achieve migrations, like transitioning and in-place upgrading Domain Controllers, easier.

However, in the process, Microsoft is also doing away with older technologies, that have been around since Windows 2000 Server and have carried over with every migration, unless you’ve deliberately migrated them over.

Concluding

I will cover these environment-wide improvements, first, in the next part of these series. I’ll discuss the functional level implications for Windows Server 2012 R2, and will specifically dive into the FRS deprecation, that you might not have seen coming from miles away…

In Active Directory, all Domain Controllers are equal, but some are more equal than others. As you gain experience in managing networking environments, you’ll find the same principle is true for user accounts: all user accounts are equal, but some are more equal than others…

For instance, some colleagues to whom these accounts belong, require you to resolve an issue faster, simply because they are more important in your environment (or feel they are). They have mailboxes in a different (highly available) Exchange database that is faster to recover items from, etc.

It’s not all about importance, too. From a security point of view, accounts can also be more sensitive than others. How do we deal with these? Since Windows Server 2008, we assign more strict password policies to user accounts and groups within Active Directory with the Fine-Grained Password Policies functionality. And, you can always use Group Policies to disallow interactive logons and network logons to user accounts and groups in Active Directory on Organizational Units (OUs) with certain domain-joined devices.

Even with all these opportunities, however, there’s no way you could restrict sensitive accounts in terms of the lifetime of the Ticket Granting Tickets (TGTs), restricting more vulnerable authentication protocols (like NTLM), encryption standard to use in the pre-authentication process, the ability to be (constrainedly) delegated, or criteria for the devices they log on to.

Introducing Protected Users

To achieve these goals, Microsoft has introduced a new feature in Active Directory Domain Services (AD DS) in Windows Server 2012 R2: the Protected Users group.

The Protected Users global security group in the Users container triggers non-configurable protection on devices and servers running Windows Server 2012 R2 and Windows 8.1, and on Active Directory Domain Controllers in domains running the Windows Server 2012 R2 Domain Functional Level (DFL).

These protections come in two stages:

1. Client-side protection
   The first stage of protection is triggered when a user account with membership of the Protected Users group is used to authenticate to a Windows 8.1-based device (or up) or a Windows Server 2012 R2-based host (or up).
2. Domain Controller protection
   In addition to the client-side protection, Domain Controller protection applies, when a user account with membership of the Protected Users group is used to authenticate to a Windows 8.1-based device (or up) or a Windows Server 2012 R2-based host (or up) and the user account resides in an Active Directory domain with the Windows Server 2012 R2 Domain Functional Level (DFL).

Note:
When authentication to devices with Operating Systems prior to Windows 8.1 or servers with Operating Systems prior to Windows Server 2012 R2, no protections apply.

The table below gives you an overview of the protections available:

Note:
The default Kerberos TGTs lifetime setting of four hours is optionally configurable by using Authentication Policies and Silos, which can be accessed through the Active Directory Administrative Center (dsac.exe). This is something I’ll be discussing in the next part of this series.

Configuring Protected Users

Enabling the protection offered by membership of the Protected Users group, is as easy as making sensitive user accounts members of this group.

Requirements

To benefit from the additional protections, that membership of the Protected Users group offers, you need to comply with these requirements:

• To gain the Protected Users Security Group, the Active Directory schema needs to be extended to Windows Server 2012 R2 (version 69).
• To replicate the Protected Users group, the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role needs to run Windows Server 2012 R2.
• Users need to authenticate on Windows 8.1-based devices (or up) or Windows Server 2012 R2-based servers (or up) to a Domain Controller that runs at least Windows Server 2012 R2.
• For Domain Controller protection, the Active Directory domain needs to operate on the Windows Server 2012 R2 Domain Functional Level (DFL).

Note:
The Protected Users group can be applied to Active Directory domains that are set to a Domain Functional Level (DFL) for an operating system earlier than Windows Server 2012 R2. This allows the added security that is achieved by using the Protected Users group to be applied throughout the domain. To do this, promote the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role to Windows Server 2012 R2, and then allow the upgraded PDC to replicate the Protected Users group to other Domain Controllers. When the replication completes, the PDC can be set back to any available Domain Functional Level (if desired), and the Domain Controller-based protections are automatically applied.

Concluding

The Protected Users global security group in the Users container triggers non-configurable protection on devices and servers running Windows Server 2012 R2 and Windows 8.1, and on Active Directory Domain Controllers in domains running the Windows Server 2012 R2 Domain Functional Level (DFL).

Use membership of this group to limit the availability of outdated authentication protocols, weak encryption algorithms and delegation to sensitive user accounts.

Further reading

Protected Users Security Group
How to Configure Protected Accounts
What’s New In AD and Identity Management in Windows Server 2012 R2, Part 2
Don’t be the next Target – Protect your Active Directory
Active Directory Features in Different Versions of Windows Server
Active Directory Forest and Domain Levels
Windows 8.1 Security Improvements

Last year, I was invited to speak at ITPro | DEV Connections Greece. That was great fun, so we were delighted to see this years organization asking Adnan and me to send in some session proposals for this years event. Even better was seeing our proposals accepted.

As a bonus: Our buddy Peter also got through!

This means that this year we’ll be joining ITPro | DEV Connections Greece with three Dutch/Flemish speaking presentations.

About ITPro | DEV Connections Greece 2014

ITPro | DEV Connections Greece is an annual event, hosted by the Greek IT professional community autoexec.gr, in cooperation with the Greek developers community, dotNETZone.gr. This years event takes place on Saturday November 29, 2014 and Sunday November 30, 2014.

The event is located at the Metropolitan Expo, located next to “Eleftherios Venizelos”, Athens’ International Airport and features modern infrastructure and services.

Our presentations

Peter, Adnan and I will present three back-to-back sessions in room C3:

Peter de Tender
The desktop migration alphabet soup is… YUMMY!!

Saturday November 29, 2014 1PM C3

If you are preparing yourself for Windows 7 or Windows 8 migrations, you find an overload of acronyms ? Win8, Win8.1, MDT, SCCM, DISM, APPV, MEDV, MDOP. In this session, we’ll walk you through the acronyms, explaining what they can offer and how they can smooth your desktop migration. This will be shown not only on slides, but mainly in real live scenarios and deep-dive demos. And who knows, you might even enjoy a good cup of soup during our show.

Adnan Hendricks
Deploying Windows 8.1 or Server 2012 R2

Saturday November 29, 2014 2:50PM C3

All about deployment ! This session covers installing and configuring free tools provided by Microsoft to build your own deployment solution. Adnan will be covering reference images creation, Windows Deployment Services, Microsoft Deployment Toolkit, Lite Touch, new computer scenario, refresh old computers and how to replace old computers while keeping the user data and re-installing applications.

Sander Berkouwer
10 most common mistakes when deploying AD FS

Saturday November 29, 2014 4:15PM C3

Active Directory Federation Services (AD FS) is the Microsoft technology to bridge your on-premises Identity systems towards cloud Identity providers like Azure Active Directory. Colleagues depend on a reliable, yet cost effective deployment of AD FS and it’s our jobs as IT Pros to make it happen. This session covers the 10 most common mistakes we see in the field in organizations that have deployed AD FS. Learn from their mistakes, so you don’t have to make them.

Join us!

With Windows Server 2012 R2 and Windows 8.1, Microsoft introduced a feature in Active Directory Domain Services called the Protected Users group. You can use it to limit the availability of outdated authentication protocols, weak encryption algorithms and delegation to sensitive user accounts.

Interesting stuff, but I feel there’s some things you should know about this feature…

When you want to go and put the Protected Users group to good use in your environment, I feel you should be aware of these things:

1. Take care of client-side requirements

No matter how you look at this wonderful feature, you won’t escape the fact that to get the protection, your users need to log on to Windows 8.1 (or up) devices or Windows Server 2012 R2 (or up) hosts. Even if you’ve upgraded all the Domain Controllers to Windows Server 2012 R2 and upgraded the Domain Functional Level to Windows Server 2012 R2, when your colleagues use Windows 7 as their client Operating System (OS) or Windows Server 2008 R2 as their Terminal Servers, they won’t benefit from the protections offered by membership of the Protected Users group.

2. Take care of server-side requirements (sorta)

According to the official documentation, the Protected Users group requires the Windows Server 2012 R2 Domain Functional Level (DFL). However, the Protected Users group can be applied to Active Directory domains that are set to a Domain Functional Level (DFL) for an operating system earlier than Windows Server 2012 R2.

This allows the added security that is achieved by using the Protected Users group to be applied throughout the domain. To do this, promote the Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role to Windows Server 2012 R2, and then allow the upgraded PDC to replicate the Protected Users group to other Domain Controllers. When the replication completes, the PDC can be set back to any available Domain Functional Level (if desired), and the Domain Controller-based protections are automatically applied.

3. Protect users only

Accounts for services and computers should not be members of the Protected Users group. This group provides no local protection to these types of accounts because the password or certificate is always available on the host. Also, since Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs) use Kerberos Constrained Delegation (KCD), do not add these accounts to the Protected Users group, since their functionality will break.

4. Make Protected Users change their passwords on Windows Server 2008 Domain Controllers (or up) first

Members of the Protected Users group must be able to authenticate by using Kerberos with Advanced Encryption Standards (AES). This method requires AES keys for the account object in Active Directory. The built-in Administrator does not have an AES key unless the password was changed on an Active Directory Domain Controller that runs Windows Server 2008 or later. Additionally, any account object, which has a password that was changed at an Active Directory Domain Controller that runs an earlier version of Windows Server, is locked out.

5. You may lock yourself out

The authentication restrictions have no workarounds, which means that members of highly privileged groups such as the Enterprise Admins group or the Domain Admins group are subject to the same restrictions as other members of the Protected Users group. If all members of such groups are added to the Protected Users group, it is possible for all of those accounts to be locked out. My advice is to never add all highly privileged accounts to the Protected Users group, until you have thoroughly tested the potential impact.

6. The protection is non-configurable

The protection triggered by membership of the Protected Users group is non-configurable.

However, most of the same protection can be achieved using more configurable methods like Group Policies and Authentication Policies (to configure TGT lifetimes more granularly) and NTLM block policies.

The inability to use DES to encrypt Kerberos pre-authentication, on the other hand is automatically enforced by Windows Server 2012 R2-based Active Directory Domain Controllers, so this protection mechanism may already be applied.

The inability to delegate can also be configured on a per account basis through the Account is sensitive and cannot be delegated setting in Active Directory.

7. Group membership changes need token refreshes

It may take longer than expected for the protection triggered by membership of the Protected Users group kicks in. This is because group memberships are enumerated during logon. For the protection to kick in, immediately, log off and log back on with the user account you’ve added to the Protected Users group.

8. Membership of the Protected Users does not meddle with AdminCount

In many organizations, sensitive accounts are accumulated by running a script that checks for objects with the AdminCount attribute set to 1. Membership of the Protected Users group does not change the value for the AdminCount attribute. This might lead to incomplete reports of accounts, marked as sensitive.

9. Troubleshooting delegation

One of the protections triggered by membership of the Protected Users group is the inability to, technically, be trusted for delegation. In a situation where delegation would be failing, the first response is to check to see if Account is sensitive and cannot be delegated is set for an account. However, the graphical user interfaces (GUIs) for Active Directory Users and Computers (dsa.msc) and Active Directory Administrative Center (dsac.exe) do not reflect an inability to delegate due to membership of the Protected Users group. Next to checking the setting on the account, check for the event IDs in Event Viewer (eventvwr.msc) indicating a member of the Protected Users group has logged on.

10. Protected Users are not 100% protected

When you add user accounts to the Protected Users group, it’s not yet time to sit back, zip a coffee and enjoy the show. Membership of the Protected Users group offers protection, but it’s no 100% protection. In fact, it’s not even close to 70%, because membership of the Protected Users group doesn’t protect against a whole range of other attack vectors, like the Privilege Escalation based on Exploitation of Unauthorized Grants vector.

Concluding

Otherwise, I strongly urge you to use the Protected Users group functionality, because it adds a layer of protection in most environments.

If some of the points above are true showstoppers in your environment, Authentication Policies and Authentication Policy Silos might be a good solution. More on those, soon.

On Thursday November 18, 2014, Raymond and I delivered two 1-hour sessions at Experts Live 2014 at Cinemic in Ede, the Netherlands.

With nearly 800 attendees, Experts Live transformed the cinema multiplex with its 6 smaller auditoriums (177 seats), its grand auditorium (336 seats) and its new Expo Theatre (1030 seats) into a buzzing and cloudy IT Pro world, not just for entertainment.

Raymond and I started off with a presentation in Room 1 from 7:45 AM to 8:45 AM. This pre-keynote session on ‘Virtualizing highly-sensitive Domain Controllers on Hyper-V and Azure’ wasn’t attended by many people, but the folks who showed up got some interesting tidbits from us.

We ran for a mere 55 minutes, to give our attendees the chance to grab the best seats for the Keynote in the Expo Theatre auditorium. And they needed them. The auditorium was filled to the brink and the keynote was well worth it. The start with the Experts Live A-team parody was simply amazing.

Just before lunch, Raymond and I presented our second session ‘Windows 8.1 and Windows Server 2012 R2 Security Overview’ in the Grand Auditorium.

After lunch, attending some more sessions, preparing our presentations for sharing and helping out fellow speakers, I attended the closing keynote by Tom Coronel.

It was a great event!

As we’ve dived into the Protected Users security group, we’ll dive into Authentication Policies and Authentication Policy Silos today, as these latter two features are greatly intertwined with the functionality of the Protected Users group and have much in common. But, as we’ll find out, Authentication policies and authentication policy silos also differ greatly from the Protected Users security group.

So, let’s look at Authentication Policies and Authentication Policy Silos!

Introduction

Let’s start with some questions.

What if you wanted to control authentication settings like the Ticket Granting Ticket (TGT) lifetime, but are not happy with the built-in TGT lifetime settings (10 hours and 7 days, respectively) nor the TGT Lifetime settings for Protected Users (4 hours both)?

Or, what if you wanted to control the authentication settings for computer accounts or even service accounts? Since you can’t use membership of the Protected Users group for these types of accounts, how you would you do it?

Or even when the functionality of the Protected Users group perfectly fitted your needs, how would you control where members would actually be allowed to log on. Membership to the Protected Users group doesn’t govern that.

Introducing Authentication Policies

Using Authentication Policies in Active Directory Domain Services, you can set the Ticket Granting Ticket (TGT) lifetime. Also, you can define criteria for device accounts before users are able to sign in with a password or a certificate, and, of course, you can define criteria that users and devices need to meet to authenticate to services running as part of the account.

Introducing Authentication Policy Silos

While the Protected Users group has a pre-defined scope, Authentication Policies do not. Authentication Policy Silos in Active Directory Domain Services perform the scoping for Authentication Policies.

Note:
Alternatively, you can set an Authentication Policy only on a set of objects without using an Authentication Policy Silo, but this is not nearly as effective and might make your Active Directory Domain Services needlessly more complex to manage.

The cool thing about Authentication Policies and Authentication Policy Silos, is that unless computer or user account objects meet the criteria in the rules, a Ticket Granting Ticket (TGT) will not be issued. At all.

Requirements

To gain access to Authentication Policies and Authentication Policy Silos, you need to fulfill a couple of requirements:

• All Domain Controllers in the Active Directory domain must be running at least Windows Server 2012 R2.
• The Active Directory Domain Functional Level (DFL) must be Windows Server 2012 R2.

Note:
There are no requirements on the Active Directory Forest Functional Level (FFL).

• Domain Controllers must be configured to support Dynamic Access Control (DAC) by deploying the required settings in a Group Policy Object (GPO) targeting the Domain Controllers Organizational Unit (OU):

Enable the KDC support for claims, compound authentication, and Kerberos armoring group policy setting under Computer Configuration, Administrative Templates, System and KDC. After you enable it, its option should automatically get configured as Supported:

• After you’ve enabled the Domain Controllers to support Dynamic Access Control (DAC), domain-joined Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 installations (and up) must be configured to support Dynamic Access Control (DAC), including Kerberos compound claims (device claims).

This is easily achieved by enabling the Kerberos client support for claims, compound authentication, and Kerberos armoring group policy setting under Computer Configuration, Administrative Templates, System and Kerberos:

Deploy this setting in Group Policy Objects (GPOs) targeting the computer accounts throughout the Active Directory domain.

Setting Authentication Policies

Let me show you how to use Authentication Policies and Authentication Policy Silos in an example scenario where we’ll restrict admin access to certain workstations.

Authentication Policies and Authentication Policy Silos are created in the Active Directory Administrative Center (dsac.exe).

Note:
You cannot manage authentication policies and authentication policy silos in Active Directory Users and Computers (dsa.msc).

Creating the policies and silos

First, let’s create the authentication policy silo and authentication policy. This will provide the groundwork for scoping.

1. Open the Active Directory Administrative Center (dsac.exe).
2. Click on Authentication in the left pane.
3. In the main pane select Authentication Policies. Then, in the Tasks pane, click on New under Authentication Policies. Select Authentication Policy from the context menu.
4. Provide a Display name:. For this scenario I’ll choose Restrict Access for Admins, because that closely resembles what we’re trying to achieve here. Of course, you can use a more corporate naming scheme for the display names. Optionally, the Description: field might by the right place to note down incident registration numbers, etc.
5. Optionally, you can limit the lifetime for TGTs for objects in scope for this Authentication Policy. To do this, in the left pane, click User. Select the Specify a Ticket Granting Ticket lifetime for user accounts. option. Then, select a value between 45 and 2147483647 (2^31-1) for the Ticket-Granting-Ticket Lifetime (minutes):.
6. Press OK.
7. In the main pane select Authentication Policy Silos. Then, in the Tasks pane, click on New under Authentication Policy Silos. Select Authentication Policy Silo from the context menu.
8. Provide a Display name:. For this scenario I’ll choose Restrict Access for Admins, because that closely resembles what we’re trying to achieve here.
9. Select Enforce silo policies instead of Only audit silo policies (default).
10. Under Permitted Accounts, add the computer objects for admin workstations and the user objects for admin people.
11. Under Authentication Policy select Use a single policy for all principals that belong to this authentication policy silo.. Then, for The authentication policy that applies to all accounts in this silo: select the previously created Authentication Policy from the drop down list.
12. Press OK.

Assigning the policy

As you’ll notice in the latest screenshot, the Authentication Policy Silo is not applied at this point. Also, you won’t see check marks automatically appear in that column. We are assigning the policy silo manually. Assuming you still have the Active Directory Administrative Center (dsac.exe) open, perform these actions:

1. Click on Authentication in the left pane.
2. Under Authentication Policy Silos, select the Authentication Policy Silo we’ve created. Then, double-click it or right-click it and select Properties from the context menu.
3. Go to the Permitted Accounts section.
4. Double-click on the first item in the list of Permitted Accounts. This will open the Properties of the object.
5. In the left pane click on Silo to go to the Authentication Policy Silo portion of the properties of the object.
6. Under Authentication Policy Silo, select the Assign Authentication Policy Silo option. Then, from the drop-down list select the name for Authentication Policy Silo: you would want to apply.
7. Click OK.
8. Perform these actions for all objects in the list of Permitted Accounts. For these objects, this will set the msDS-AssignedAuthNPolicySilo attribute:

Note:
While you can use the SHIFT and CTRL buttons in the list of Permitted Accounts in the Authentication Policy and press ENTER to access their properties, you can’t assign Authentication Policy Silos to multiple objects through the Graphical User Interface (GUI). To this purpose use the Set-ADAccountAuthenticationPolicySilo PowerShell Cmdlet.

Now, as mentioned before we started to created the Authentication Policies and Authentication Policy Silos, unless the objects meet the criteria in the rules, a Ticket Granting Ticket (TGT) will not be issued. Thus, when you try to authenticate to a domain-joined Windows client, that is not in scope for the Authentication Policy Silo we created (for instance, a device other than the Admin01 through Admin04 computers in scope), you will not be able to log on with the objects in scope (the Jos Haarbos and Hans Worst user objects):

Concluding

Authentication Policies and Authentication Policy Silos enable you to flexibly define policies for user accounts, service accounts and computer accounts for authentication. You can control the scope of these policies, where accounts can log on and to which services they can authenticate to, as well as TGT settings. All within the comfort of the Active Directory Administrative Center (dsac.exe) and PowerShell.

Related blogposts

Ten things you need to be aware of before using the Protected Users Group
New features in AD DS in Windows Server 2012 R2, Part 2: Protected Users
New features in AD DS in Windows Server 2012 R2, Part 1: Introduction

Further reading

Authentication Policies and Authentication Policy Silos
Authentication Policies and Authentication Silos – Restricting Domain Controller Access

Managing an on-premises Active Directory Domain Services infrastructure through the Graphical User Interface (GUI) can get daunting. And boring. Luckily, for most repetitive tasks you can resort to the command line, or in more recent versions of Windows Server to PowerShell.

Windows Server 2012 already comes equipped with PowerShell Cmdlets to manage your Active Directory topology and objects and to deploy Active Directory Domain Services.

Windows Server 2012 R2 introduces twelve new PowerShell Cmdlets in addition to this extensive collection:

• Get-ADAuthenticationPolicy
• Get-ADAuthenticationPolicySilo
• Grant-ADAuthenticationPolicySiloAccess
• New-ADAuthenticationPolicy
• New-ADAuthenticationPolicySilo
• Remove-ADAuthenticationPolicy
• Remove-ADAuthenticationPolicySilo
• Revoke-ADAuthenticationPolicySiloAccess
• Set-ADAccountAuthenticationPolicySilo
• Set-ADAuthenticationPolicy
• Set-ADAuthenticationPolicySilo
• Show-ADAuthenticationPolicyExpression

Note:
You can observe these additions yourself, by running the Get-Command -Module ActiveDirectory and Get-Command –Module ADDSDeployment PowerShell one-liners in Windows Server 2012 R2 and comparing the output of these oneliners with the output in previous versions of Windows Server.

The names of these PowerShell Cmdlets might already give away that these are all related to the Authentication Policies and Authentication Policy Silos, discussed in detail yesterday.

Note:
When you’re expecting PowerShell Cmdlets for the Protected Users feature, that is also new in Active Directory Domain Services in Windows Server 2012 R2, don’t keep your hopes up. After you’ve met the requirements for this feature, you can add a user object to the Protected Users group with this PowerShell one-liner:

Add-ADPrincipalGroupMembership -Identity:”CN=Administrator, CN=users,DC=domain,DC=tld” -MemberOf:”CN=Protected Users,CN=Users,DC=domain,DC=tld”

Requirements

To gain access to the PowerShell commands, you need to use either:

• Implement a Windows Server 2012 R2-based Domain Controller with the Active Directory Module for Windows PowerShell feature installed. (It is installed by default when you install the Active Directory Domain Services role.)
• Implement a Windows Server 2012 R2-based member server with the Active Directory Module for Windows PowerShell feature installed. This feature is buried deep in the Remote Server Administration Tools, then Role Administration Tools and AD DS and AD LDS Tools. Alternatively you can use the following PowerShell one-liner: Add-WindowsFeature RSAT-AD-PowerShell after you’ve installed the RSAT.
• Implement a Windows 8.1-based domain-joined workstation with the Remote Server Administration Tools (RSAT) package installed and Active Directory Module for Windows PowerShell feature installed. This feature is buried deep in the Remote Server Administration Tools, then Role Administration Tools and AD DS and AD LDS Tools. Alternatively you can use the following PowerShell one-liner: Add-WindowsFeature RSAT-AD-PowerShell after you’ve installed the RSAT.

To point the PowerShell commands to a Domain Controller, this Domain Controller needs to run the Active Directory Web Services (ADWS). This functionality is available on both Server Core and Full Installations of Windows Server 2008 R2. For Windows Server 2003 and full installations of Windows Server 2008, the Active Directory Management Gateway Service (Active Directory Web Service for Windows Server 2003 and Windows Server 2008) can be installed.

Concluding

All the new functionality in Windows Server 2012 R2 Active Directory Domain Services can be managed through PowerShell.

The PowerShell History Viewer, that has been available in the Active Directory Administrative Center (dsac.exe) since Windows Server 2012 is a great help in discovering and uncovering the new PowerShell Cmdlets.

Related blogposts

New features in AD DS in Windows Server 2012, Part 4: New PowerShell Cmdlets
New features in AD DS in Windows Server 2012, Part 5- PowerShell History Viewer
New features in AD DS in Windows Server 2012 R2, Part 2: Protected Users
New features in AD DS in Windows Server 2012 R2, Part 3: Authentication Policies and Authentication Policy Silos

Further reading

Active Directory Powershell Cmdlets in 2012 R2
Weekend Scripter: Authentication Silos Part 1
How to Install the Active Directory Module for Windows PowerShell
Deploying Active Directory Domain Services on Windows Server 2012 R2

Last week, we discussed the new Active Directory Domain Services-related PowerShell Cmdlets in Windows Server 2012 R2.

In the requirements I mentioned that you needed at least one system with the Windows Server 2012 R2 or Windows 8.1 version of the Active Directory Module for Windows PowerShell feature installed.

However, as Aleksandar Nikolic (PowerShell MVP) pointed out to me, purely having one Windows Server 2012 R2-based Domain Controller with this feature allows other systems, including down-level systems as far back as Windows XP and systems without the Active Directory Module for Windows PowerShell to use these new Active Directory Domain Services-related PowerShell Cmdlets.

Of course, you could argue that you could always use these Cmdlets through Remote Desktop and PowerShell Remoting, but PowerShell  has two distinct features up its sleeve, depending on your version of PowerShell:

PowerShell 2.0

On systems with PowerShell 2.0, you can use the Import-PSSession Cmdlet, pointed towards a Windows Server 2012 R2-based Domain Controller (or Windows 8.1-based domain-joined device with the Active Directory Module for Windows PowerShell feature installed):

$dc=New-PSSession -ComputerName DC1
Import-PSSession -Session $dc -AllowClobber
Import-Module ActiveDirectory

PowerShell 2.0 is available by default on Windows 7. You can download the Windows Management Framework, which includes Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0 for Windows XP with ServicePack 3 and Windows Vista with ServicePack 1.

PowerShell 3.0 (and up)

On systems with at least PowerShell 3.0, you can use the PowerShell 2.0 method above, but you can also use the Import-Module Cmdlet with the -PSSession parameter:

$dc=New-PSSession -ComputerName DC1
Import-Module -PSSession $dc -Name ActiveDirectory

Note:
You will need to allow scripts, before you can successfully run the above. Type Set-ExecutionPolicy unrestricted to this purpose, before running the above two lines of PowerShell code.

PowerShell 3.0 is available by default on Windows 8. After you download and install .Net Framework 4 or .Net Framework 4.5, you can download and install the Windows Management Framework 3.0, which includes PowerShell 3.0 and WMI 3.0 on Windows 7 with ServicePack 1.

Concluding

Take advantage of all the available Active Directory Domain Services-related PowerShell Cmdlets using the Import-PSSession and/or the Import-Module Cmdlet with the
-PSSession parameter on down-level systems.

Indeed, a neat trick!

Related blogposts

New features in AD DS in Windows Server 2012 R2, Part 4: PowerShell Cmdlets
New features in AD DS in Windows Server 2012, Part 4: New PowerShell Cmdlets
Active Directory Services and PowerShell manageability 
KnowledgeBase: Incorrect results when you run AD Windows PowerShell Cmdlets on a Windows Server 2012 or Windows Server 2008 R2-based Domain Controller 

Further reading

Import-PSSession (PowerShell 4.0) 
Powershell Remoting: using imported module cmdlets in a remote pssession 
Import and Export PSSession 
Get Full Control over your Exchange remote PowerShell session 
Deep Dive video: Constrained PowerShell Endpoints – Aleksandar Nikolic 

Hat Tip

Thanks to Aleksandar Nikolic for the tip!

While going through the Release Notes for the Windows Server Technical Preview and the Release Notes for Windows 10, I noticed something quite interesting:

If you join a computer with Trusted Platform Management (TPM) enabled to a domain in which there are no domain controllers running at least Windows Server 2012, computer authentication and those services running under Local, Network, or Virtual permissions will fail.

To correct this, on the computer you want to join to the domain, create a new registry key with DWORD value DevicePKInitEnabled under HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Set this key to 0 and then restart the computer.

So what’s going on here?

The situation

One of the new features in the next versions of Windows and Windows Server is support for device authentication using certificates. This feature requires connectivity to a Domain Controller in the device account domain which supports certificate authentication for computer accounts.

The DevicePKInitEnabled value in the registry allows you to set support for Kerberos to attempt authentication using the certificate for the device to the domain. By default, the device will attempt to authenticate using its certificate.

Since pre-Windows Server 2012 Domain Controllers do not support computer account authentication using certicates, authentication fails, NTSTATUS value 0xC00002F9 (STATUS_PKINIT_NAME_MISMATCH) will be logged, and you may receive an error reading The client certificate does not contain a valid UPN, or does not match the client name in the logon request. Please contact your administrator. when you start a Windows 10 Technical Preview or Windows Server Technical Preview-based virtual machine.

The solution

Using the registry

The solution, is to create a new registry key with DWORD value DevicePKInitEnabled under HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Set this key to 0 and then restart the computer.

Using a script

Meddling with the Windows registry can be time consuming, so alternatively you can run the following command from an elevated command prompt:

Reg add HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v DevicePKinitEnabled /t REG_DWORD /d 0

Using Group Policy

Alternatively, you can correct this behavior using Group Policy. Windows 10 Technical Preview or Windows Server Technical Preview both support a new Group Policy setting named Support device authentication using certificate under Computer Configuration, Administrative Templates, System, Kerberos to correct this behavior:

When this Group Policy setting is Not Configured, the device in scope for the Group Policy will attempt to authenticate using its certificate.

When you enable this Group Policy setting, Device authentication behavior using certificate: is set to Automatic, the aforementioned DWORD value DevicePKInitEnabled will be created (if not already present) in the Windows registry on devices running Windows 10 Technical Preview (and up) and Windows Server Technical Preview (and up) with a value of 1. When you change the value for Device authentication behavior using certificate: to Force, the DWORD value DevicePKInitEnabled will be created in the Windows registry (if not already present) on devices running Windows 10 Technical Preview (and up) and Windows Server Technical Preview (and up) with a value of 2.

When you  disable this Group Policy setting, the DWORD value DevicePKInitEnabled will be created in the Windows registry (if not already present) on devices running Windows 10 Technical Preview (and up) and Windows Server Technical Preview (and up) with a value of 0, effectively achieving the same as you would achieve when you create the value yourself as mentioned as the workaround.

The other way around

Of course, you could also fix this issue by upgrading at least one Domain Controller to Windows Server 2012 in the Active Directory domain where the device account resides.
Here’s an elaborate Howto.

Concluding

Device Authentication using certificates is a welcome addition to Windows, but unfortunately not every environment is ready for it, today.

Related blogposts

Transitioning your Windows Server 2003 Domain Controllers to Windows Server 2012

Further reading

Release Notes: Important Issues in Windows Server Technical Preview
Release notes: Important issues in Windows 10 Technical Preview
2.3.1 NTSTATUS values
Microsoft Devices Security, Virtual Smart Cards Part 1: Introduction and TPM
A Trusted Ticket System for Kerberos
Next Release of Windows Server Hyper-V

This afternoon, I received an e-mail message titled:

“Congratulations 2015 Microsoft MVP!”

This is the seventh message I receive, welcoming me (back) to Microsofts Most Valuable Professional (MVP) Program. It’s my honor to accept the award and wear the MVP logo for the seventh consecutive year.

Just like previous years, I will take my experiences in building and maintaining Directory Services solutions and the feedback I receive from you, to my fellow MVPs and to the product teams in Redmond.

My goal is and remains to share information on Directory Services technologies and to make these products and technologies more enjoyable.

Thank you!

Active Directory is a family of products. Besides the commonly known Active Directory Domain Services and Certificate Services siblings, the family consists of the Active Directory Lightweight Directory Services, Rights Management Services and Federation Services.

The latter received a major overhaul in Windows Server 2012 R2. One of the new features offered by Active Directory Federation Services is backed by Active Directory Domain Services: WorkPlace Join.

Active Directory Domain Services facilitate WorkPlace Join with a new object type, the msDS-Device object.

A primer on WorkPlace Join

WorkPlace Join, in my opinion, is a method to loosely couple devices (1) with a networking environment based on internet standards (2) to offer single sign-on (3) and rich authorization scenarios (4).

Let me explain in more depth:

1. Although you can easily WorkPlace Join Windows 8.1-based devices through the new Control Panel, and WorkPlace Join Windows 7-based devices, too (through a separate download), you can also WorkPlace Join iOS and Android-based devices.
2. You join these devices to Active Directory Domain Services (Ad DS) through the Device Registration Service (DRS) in Active Directory Federation Services (AD FS), based on federation-based protocols, encrypted using TLS and transported over HTTPS (TCP 443).
3. When a device is WorkPlace Joined, a cookie on the device offers single sign-on (SSO) to web-based applications and services for the user profile (if any) that was used to WorkPlace Join the device.
4. WorkPlace-Joined Devices, by default, offer more claimtypes than non-WorkPlace-Joined devices. These additional claimtypes may be used in rich authorization scenarios within the aforementioned applications and services.

Granted, iOS and Android-based devices don’t offer user profiles, today.
On Windows-based devices, though, WorkPlace Join is offered to the combination of the device object and the user account. When the device is used with another user account, the benefits of single sign-on and rich authorization scenarios are unavailable,

Note:
WorkPlace Join is not available for Windows 8 (8.0).

Requirements

When you want to utilize WorkPlace Join, you need to meet these requirements:

• Your Active Directory Federation Services (AD FS) infrastructure needs to run Windows Server 2012 R2, or up.
• Your Active Directory Domain Services (AD DS) infrastructure needs to be prepared for Windows Server 2012 R2. This means you need to have run adprep.exe with the /forestprep and /domainprep switches and your Active Directory schema must read at least version 69.
• When you want to use the group Managed Service Account (gMSA) functionality for the Active Directory federation Services (AD FS) Service account(s), this requires the Windows Server 2012 Active Directory schema.
• Optionally, when you want to utilize the msDS-Primary-Computer attribute on user objects as a  Group Policy scoping mechanism, this requires the Windows Server 2012 Active Directory schema and Windows 8.x clients.

Setting up WorkPlace Join

I’ve documented how to build an environment for WorkPlace Join (and other Windows Server 2012 R2-based Enterprise Mobility technologies like the Web Application Proxy and Work Folders) in Microsoft Azure for 4Sysops.com and you can find it through the links below:

• Building a BYOD lab in Microsoft Azure
• BYOD lab in Azure – Create virtual machines
• BYOD lab in Azure – Domain Controller, Certification Services
• BYOD lab in Azure – Active Directory Federation Services (AD FS)
• BYOD lab in Azure – Webserver
• BYOD lab in Azure – Trust relationships

WorkPlace Joining

Configuring WorkPlace Join on Windows 8.1 through the Control Panel

On devices running Windows 8.1 (and up), you can WorkPlace Join through the Control Panel of the New Interface.

To this purpose, perform these steps:

• Log on with the account that you wish to use to couple the device with the enterprise environment. This account does not need to have administrative privileges.
• While in the Start Screen, either:
• Press Ctrl + C to open the Charms menu. Click on Settings, then Change PC settings. In the Control Panel, in the left pane, click Network and then Workplace.
• Type (part of) Workplace settings and click on it in the Search results.

• In the text field under Enter your user ID to get workplace access or turn on device management enter the e-mail address or User Principal Name (UPN) for a valid account within Active Directory Domain Services. Click Join next.
• A pane will appear over the Control Panel section that allows you to authenticate to the Active Directory Federation Services (AD FS) infrastructure.

Note:
When you’ve enabled Multi-factor Authentication on WorkPlace Join, this pane will also feature the Multi-factor Authentication controls.

• When you successfully sign in, the combination of the device and user account will be WorkPlace-joined.

Note:
The Workplace settings screen can now be used to leave the workplace network, when you no longer want to combination of user and device to be trusted. The button labeled Leave serves this purpose.

• Now, after you’ve successfully authenticate to a claims-protected resource, the single sign-on (SSO) benefits for that resource will be enabled.

Configuring WorkPlace Join on Windows 8.1 through Group Policy

Windows 8.1 devices can also be automatically WorkPlace-Joined through Group Policy.

This behavior is governed by the Automatically workplace join client computers Group Policy setting under Policies, Administrative Templates, Windows Components, and finally Workplace Join.

When you configure this Group Policy setting to Enabled, any colleague that signs in with a domain user account on a domain-joined device in scope for the Group Policy object will be automatically and silently Workplace-Joined.

The Group Policy enables a Scheduled Task on the system that runs in the user’s context and is triggered on user sign-in. The task will silently Workplace Join the user and device with Active Directory after the User signs-in is complete, when the device is considered to be on the Intranet by the Federation Server.

Additional requirements

Automatic WorkPlace Join has the following specific and additional requirements to the general requirements listed above:

• Devices must have connectivity to an Active Directory Domain Controller in order to Workplace Join. You cannot automatically WorkPlace Join through a reverse proxy solution, such as the Web Application Proxy.
• The AD FS Global Primary Authentication Policy must be configured to allow Windows Integrated Authentication for the Intranet. The Federation server used, needs to see the device to be joined as an inside device.
• Internet Explorer must use the following settings for the Local intranet security zone:
  • Don’t prompt for client certificate selection when only one certificate exists: Enable
  • Allow scripting: Enable
  • Automatic logon only in Intranet zone: Checked

Luckily, the specific settings above are the default settings.

Configuring WorkPlace Join on Windows 7

For Windows 7 clients, both the Workplace Join functionality and the Control Panel of the New Interface are unavailable, by default. Although the New Control Panel will never make it to Windows 7 (and some people are very grateful for that), the WorkPlace Join functionality can be installed separately. The software package is available for download at the Microsoft Connect website.

You can distribute this package to Windows 7 devices through Group Policy and, for instance, System Center Configuration Manager. The use of the /quiet parameter is recommended in these scenarios.

Workplace Join for Windows 7 does not require or include a user interface. Once installed on the machine, any domain user that logs into the machine will be automatically and silently Workplace Joined with Active Directory; the installer creates a scheduled task on the system that runs in the user’s context and is triggered on user sign-in. The task silently Workplace-Joins the user and device with Active Directory after the user signs-in is complete. The Scheduled Task can be found in the Task Scheduler Library under Microsoft > Workplace Join.

The same additional requirements that apply to Automatic WorkPlace Join on Windows 8.1 apply to WorkPlace Join on Windows 7.

The msDS-Device Object

When you Workplace Join a device through this Active Directory Federation Services (AD FS) process, a Registered Device object is automatically created by the Device Registration Service (DRS) from within Active Directory Federation Services (AD FS). The Registered Device object, by default, is created in Active Directory Domain Services (AD DS) in a new container, labeled RegisteredDevices:

Registered Device objects (msDS-Device objects), by default, will be automatically created within this container for each of the devices you Workplace Join.

The first thing you’ll notice when examining these objects, is that, in contrast to domain-joined devices, the names for these objects are not very straightforward:

Additionally, in the left pane, many of the sections you’d normally see with user and device objects are missing. For instance, the ability to add Registered Devices to groups is not present.

However, in its attributes, a lot of useful information can be found on the device and the user account that was used to register it:

• DisplayName
  This attribute contains the hostname for the registered device.
• msDS-CloudIsManaged and msDS-IsManaged
  These attributes contain true and false values to indicate whether the device is managed through Microsoft Intune and/or System Center Configuration Manager.
• msDS-DeviceOSType and msDS-DeviceOSVersion
  These attributes contain strings to indicate the Operating System on the device, at the time when the device was registered. (If the device is upgraded, these attributes are not updated, unless a Mobile Device Management solution updates them for it.)
• msDS-RegisteredOwner
  When looking for the user account object that registered the device, this attribute contains the Security identifier (SID) for it.

Concluding

WorkPlace Join for Windows 7 and Windows 8.1-based devices offers a strategic expansion to Active Directory Domain Services into a dual identity stack. For iOS and Android-based devices, WorkPlace Join merely offers single sign-on (SSO) to enterprise applications and services. Something colleagues on these devices will appreciate strongly.

Further reading

Walkthrough Guide: Workplace Join with a Windows Device
Walkthrough Guide: Workplace Join with an iOS Device
Automatic and Silent Workplace Join
IT Guide to Windows 8.1: Workplace Join
Workplace Join for Windows 7
WorkPlace Join overview
Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications

Yesterday, we discussed WorkPlace Join and the msDS-Device object. Over the past months, these technologies sparked conversations with several people, some of which have very strong opinions on the exclusivity of domain join and a passion for loosely-coupling devices to Active Directory.

This conversation could best be titled WorkPlace Join versus Domain Join.

I’ll use this blogpost to express my opinion.

Trusted and untrusted networks

Domain Join conforms to the old client-server model where clients reside on the same network as the servers and this internal network is trusted. Protocols like LDAP, NetBIOS and Kerberos are suitable for this type of network. For this type of network, domain join offers single sign-on, based on available authentication modules in LSASS. (NTLM, Kerberos)

Nowadays, clients wander off these internal networks. For years, we’ve expanded these internal networks through VPNs. More recently, we’ve used more advanced tunneling scenarios like DirectAccess. All these scenarios expand the ‘trusted’ network to allow for ‘trusted’ protocols like Kerberos.

The right protocol for the right network

The Internet, of course, is an untrusted network. Kerberos and LDAP have no reason to exist there, nor did the people behind these protocols envision untrusted networks. For these networks, we need protocols designed specifically for them: SAML, Oauth, OpenID Connect. All working on the universal firewall bypass ports TCP80 and TCP443.

ADFS makes the distinction between Intranet and Extranet in its Authentication Policies. (unless you screw it up…) By default, An ADFS Server allows for Kerberos on the Intranet (trusted network), but not on the Extranet (the Internet). Through LSASS, clients on the intranet (the trusted network) that are domain-joined (and logged onto with a domain account and the client has no more than 5 minutes time difference with the DC and the ADFS Server) have single sign-on without re-authentication (commonly known as silent single sign-on) to ADFS-enabled resources: The ADFS server acts as the STS and transforms the Kerberos token into SAML/OAuth tickets.

WorkPlace Join and Domain Join

On the Extranet, an ADFS servers presents forms-based authentication. People on clients on the Internet, therefore, will need to authenticate per (browser) session. To make this experience smoother for them, you can Workplace Join these machines to achieve single sign-on (SSO) beyond the session through the cookie/certificate.

When all applications that need to be accessible from clients both from the Intranet and Extranet allow for claims, the need for expanding the trusted network – provide VPN access, DirectAccess – goes away. The Web Application Proxy can help there…

With WorkPlace Join and Domain Join combined on a device for an Active Directory-based user account, a dual protocol stack emerges, supporting both Identity 1.0 (Kerberos) and Identity 2.0 (SAML, OAuth, OpenID Connect).

Concluding

In my opinion, WorkPlace Join and Domain Join are complementary.

Hat tip

I’d like to thank Sean Deuby for helping me articulate my opinion.