This Wednesday, Dave and I demoed managing iPad devices from an enterprise perspective. In this blogpost, I’ll go over the contents of that session and show you how to achieve centralized management of iPads ((but also including other iOS devices, like iPhones and iPods), without breaking a sweat.

First, let me quickly outline the four management scenarios available:

1. The iPhone Configuration Utility and iOS Configuration Profiles
2. Corporate App Store
3. Exchange ActiveSync, Remote Wipe and ActiveSync Policies
4. Mobile Device Management (MDM)

These scenarios can also be combined to control the residual state of the device after more elaborate management functionality is removed. For instance: ActiveSync Policies and Configuration Profiles can be combined so when the Exchange account is removed, the settings from the Configuration Policies still apply.

Initial configuration

Before you can deploy management scenarios to iOS devices, several key actions need to be performed:

Initial activation

Initial iTunes activation of iOS devices is still needed in all the above scenarios. the iPad or iPhone need to be connected to a computer running iTunes. The latest version of iTunes is recommended, but you will need at least version 10.1. This computer needs to run at least Windows XP with Service Pack 2 (or Mac OS X version 10.5) and be connected to the Internet. You can put iTunes in Activation-only Mode, to avoid being asked about synchronization options. This will save considerable time when you need to activate hundreds of devices.

Updating to the latest and greatest iOS

Before handing iOS devices to your colleagues, make sure they are updated with the latest version of iOS, but be sure to wait a couple of weeks after launch before upgrading to a new major release. Apple releases new versions of iOS regularly adding new functionality, but also fixing bugs. iOS updating can only be performed through iTunes.

Jailbreaking

Jailbreaking devices gets you rid of the initial activation burden, but might be more work per device. You might want to performs jailbreaks when you have needs beyond the default Apple functionality, but with every new iOS version, you will need a new per-device jailbreak to maintain this functionality.

iTunes Parental Controls

For corporate installations of iTunes, several settings can be centrally configured through the Parental Controls functionality in the Windows registry. Although the feature doesn’t sound like an enterprise feature, it sure helps to manage iTunes installations. Using AdminFlags, an administrator can lockdown the iTunes installation. Using UserFlags, an administrator can push preferred settings that can be changed by the end-user.

No Administrative Templates (*.adm or *.admx files) are currently available, but you can use Group Policy Preferences to deploy the necessary registry values.

Apple accounts

Each colleague with an iOS device needs an Apple ID to be able to use the iOS App Store. These accounts do not need a credit card associated to them, but you might want to consider associating a company credit card when rolling out business apps from the App Store (like RoamBI).

iOS Configuration Profiles

The first management method is using iOS Configuration Profiles.

Configuration profiles are XML files that contain device security policies and restrictions, VPN configuration information, Wi-Fi settings, email and calendar accounts, and authentication credentials that permit iOS devices to work with your enterprise systems. Configuration profiles quickly load settings and authorization information onto a device. Some VPN and Wi-FI settings can be set only by using a configuration profile, and if you’re not using Microsoft Exchange, you need to use a configuration profile to set device passcode policies.

These profiles can be created and edited using the iPhone Configuration Utility. This program is available for both Windows (requires at least Windows XP with Service Pack 3 and .Net Framework 3.5.1) and Mac OS X (requires Mac OS X 10.6).

With this utility, an administrator can create configuration profiles. These configuration profiles may include the following payloads:

• General settings
  These basic settings contain the name of the profile, but also the security setting. Per configuration profile you can set whether the policy can be removed by the end-user. You can also specify a PIN to be able to remove it, but only with authorization.
    
• Passcode settings
  You can specify whether a passcode is required in order to use the device, and specify characteristics of the passcode and how often it must be changed. This is also the place to configure how many password attempts will unavoidable wipe the device.
    
• Restrictions settings
  You can use device restrictions and application restrictions. For instance, you can restrict the use of the camera, but also the corresponding applications like FaceTime, PhotoBooth and Camera. You can also granularly disallow screen capture, the App Store, in-app purchases, YouTube, Safari and set roaming settings.
    
• Wi-Fi settings
  When your company uses a wireless network, an iOS device can be preconfigured with the service set identifier (SSID) and password, along with other information like the security type (WEP, WPA, WPA2 are all supported) and whether the SSID is broadcasted.
  
• VPN settings
  When your company is using Virtual Private Networking (VPN) you can enable an iOS device to use it. The VPN connection can be Cisco SSL VPN, L2TP/IPSec and PPTP-based. Optionally the VPN connection can use RSA SecurID for authentication.
      
• E-mail, address lists, and calendar and Microsoft Exchange settings
  Pre-configuring iPads with information on ActiveSync, IMAP4 and POP3 mailboxes. For non-Exchange environments, LDAPv3 server information can be configured for lookups. Also CalDAV can be configured for server-based  calendar functionality. Since you might not want passwords and usernames for these accounts in the profile, you can omit these. Colleagues are then asked to enter the omitted information when they access the account for the first time.
  
• Web Clip settings
  Web Clips can be used within iOS to access functionality in a restricted way. For instance, a corporate app store or the support telephone number can be added to the home screen on the iOS device of your colleagues. Web Clips pointing to URLs can still be used after Safari has been disabled through restriction policies.
         
• Credentials
  Use the Credentials settings payload to add certificates and identities to the device. These settings are especially useful to add non-trusted root certification authorities.
     
• Simple Certificate Enrollment Protocol (SCEP) settings
  Just like a router, an iOS device can enroll for certificates using Simple Certificate Enrollment Protocol (SCEP) from Cisco Systems Inc. This way, an iOS device can obtain certificates through the Network Device Enrollment Service (NDES) within Active Directory Certificate Services. (ADCS) on Enterprise and Datacenter editions of Windows Server 2008 and Windows Server 2008 R2.
    
• Mobile Device Management settings
  An iOS device can be pointed to a Mobile Device Management (MDM) server. These settings allow such a server to manage the device over-the-air.
     
• Network settings
  Under Advanced, several settings exist to control the cell provider and its mobile data information, like proxy server and proxy server port. Under normal circumstances you should not need to change these settings.

After you make a configuration profile you can get it onto an iPad or iPhone in the following ways:

• Directly through USB by connecting the device to the computer running the iPhone Configuration Utility. This option also allows you to install apps immediately.
• Share the configuration profile (*.Mobileconfig file) through e-mail
• Export the configuration profile and place it on a (private) web server
• Use a Mobile Device Management (MDM) solution to distribute profiles (only after you’ve distributed a configuration profile containing the MDM settings earlier)

Corporate App Store

If you’re solely interested in distributing Apps to your colleagues, a corporate App Store might be more your thing. Corporate App Stores exist next to the Apple App Store and are designed to contain custom-signed organization-specific IT-approved Apps.

To create a Corporate App Store your company will need to sign up with the Apple  Developer Enterprise program. ($299 annual fee). Membership in this program allows you to distribute your proprietary, in-house iOS apps to employees or members of your organization. You can also securely host and wirelessly distribute or update in-house apps to employees, keeping them current anywhere, anytime.

Using Apple’s XCode (integrated development environment (IDE), application installers consist of three files: a *provisionprofile, *.plist and *.ipa file. Colleagues can be pointed to the files. Once they click them, the application gets installed. The most common way to do this is by setting up a webserver using Internet Information Services (IIS), for example that Microsoft Exchange Server you have standing over there…

Alternatively you can use a service like testflightapp.com.

Exchange ActiveSync

Speaking of Microsoft Exchange; Since Apple licensed ActiveSync for iOS, ActiveSync Profiles can be used to manage iOS devices connected to an Exchange Server.

Of course, running the latest version of Exchange Server avoids certain compatibility problems. Also, using Exchange Server 2010 with Service Pack 1, allows Exchange administrators to change ActiveSync profiles using Outlook Web App:

This functionality is useful, since it also allows system administrators to iOS devices through ActiveSync from Safari on Mac OS X.

Remote Wipe

Both administrators and end-users have the ability by default to instantaneously remote wipe their connected devices through Outlook Web App. A message is sent to the inbox of the end-user by default to inform him or her of the remote wipe command. The message is a default message, but may be altered through the Exchange Management Shell.

ActiveSync Policies

Besides Remote Wipe functionality, Microsoft Exchange Server, through its ActiveSync profiles, can be used to apply the following settings to iOS devices on a per device basis:

• Device password policies 
  You can specify whether a password is required in order to use the device, and specify characteristics of the password, how often it must be changed and how long the device may be inactive before locking. You can configure how many password attempts will unavoidable wipe the device. Unique to Exchange ActiveSync is the ability to recover the password for the device through Outlook Web App, if you enable it here. 
     
• Device encryption policies
  While device encryption policies may be interesting in ActiveSync policies for other devices, these policies don’t apply to iOS devices, since these devices already encrypt the entire contents of their hard drives by default.
    
• Device restriction policies
  Using Exchange Server you can disable the camera on iPods, iPhones and iPad2s. When disabling the camera on an iPad2, you’re basically reducing its functionality to an iPad1, which might be helpful in some change management scenarios.  

By default the ‘Default (default)’ ActiveSync policy applies to all ActiveSync-enabled devices. You can create your own ActiveSync profiles and apply them to all users, by making your policy the default policy or to certain users (read:mailboxes) only.

Device Access Rules

Another option you might want to explore is to block or quarantine certain device families from using Exchange ActiveSync. Blocking devices may be interesting if your organization is testing the scalability of the Exchange environment with a limited amount of devices. Quarantining is useful when your organization has a need to only allow approved iPads to be used to synchronize with Exchange Server. More information on the Allow/Block/Quarantine list can be found here.

Logging

For troubleshooting purposes, an Exchange admin can enable logging for the server. Through Outlook Web App, both the admin and the end-user can get access to the log information. The end-user accesses the information through a standardized message. The admin uses the Exchange Management Shell.

Mobile Device Management

Mobile Device Management (MDM) solutions are top of the bill in both functionality as in price. Management capabilities found in MDM solutions include (but are not limited to):

• Management of many families of devices
  While this post primarily focuses on centrally managing iOS devices, many Mobile Device Management solutions offer management of BlackBerry, Android too. Some are even capable of managing Windows Phone 7. With granular targeting of profiles, different devices can receive different settings.
      
• Jailbreak detection
  When the corporate policy is not to allow jailbroken devices, using jailbreak detection allows you to filter out these unwanted devices.
    
• Granular Wipe
  While MobileMe, Exchange Server and other solutions only offer complete wipe functionality (by destroying the encryption keys for the entire device, and thus resetting it to factory defaults), Mobile Device Management solutions offer the capability to granularly wipe certain parts of the configuration and/or documents.
    
• Apple Push Notification Service
  While ActiveSync policy changes rely on the device syncing with the server, Mobile Device Management solutions rely on the Apple Push Notification Service to get tailored configuration profiles to devices instantaneously. This ensures policy changes are implemented as fast as remote wipe commands and don’t rely on the next synchronization cycle.
  
• Active Directory integration
  Assigning profiles and applications, based on Active Directory group membership or other Active Directory attributes, results in a more robust, scalable, integrated and comprehensible mobile device management solution.

Currently over 70 MDM solutions exist to manage iOS devices. In its Magic Quadrant for Mobile Device Management Software (April 2011) Gartner filtered out the good suppliers for you and placed them in the Magic Quadrant. Be aware, however, good mobile device management starts at $70 per device.

System Center Configuration Manager 2012

In 2012, Microsoft will introduce the new version of System Center Configuration Manager, with built-in iOS Mobile Device Management. Microsoft already has a System Center Mobile Device Manager product today, but it can only be used to manage Windows Mobile devices.

Concluding

Four management scenarios exist to centrally manage iPads, iPhones and iPods, Depending on the needs of your organization one scenario or multiple scenarios can be used.

As this blogpost shows, centrally managing iPads is childishly simple.

Scenario table

The table below shows key management capabilities per management scenario:

Further reading

iTunes: Turning on Activation-only Mode 
Windows OS Managed Client: How to manage iTunes control features  
Exchange ActiveSync Client Comparison Table   
Gartner Magic Quadrant for Mobile Device Management Software (April 2011) 
iPad, iPhone Challenge Management Orthodoxy  
Securing the iPad in the Business   
iPad Enterprise Users: Some Safety Tips

I’ve never made a secret of my continuing loathing of PST files, I just never displayed it on my blog. I always felt it would be too negative, while I always try to to find the positive angle to a story. Today, finally, I have positive news on PSTs!

What’s wrong with PSTs then?

If you need to ask this question, I guess you’ve never been an admin for a (enterprise) networking infrastructure, never needed to migrate between messaging solutions or never had the generic trouble related to PSTs.

PSTs, or PST files, are files with the *.pst extension. Microsoft Outlook is the program a user would typically use to open these kinds of files. Microsoft calls them personal folder files or personal stores. And yet, many problems with PSTs are related to people treating them as anything but personal files…

 
The problem with PSTs, in short, is:

1. PSTs cannot be used in multi-user and multiple-devices-per-user scenarios.
2. PSTs cannot be accessed through Outlook Web Access or Outlook Web App.
3. PSTs are storage inefficient. In a large messaging environment, archiving to PSTs would clog up file servers. Where older versions of Exchange Server use Single Instance Storage and newer versions of Exchange Server compress the database, PSTs don’t offer any of these optimizations. A 10MB message sent to a hundred recipients, stored by these hundred recipients in their respective PSTs would clog up the file server with 1GB. Not an uncommon scenario. Because of this, PSTs are mostly stored locally, exposed to the risk of data loss, data theft, etc.
4. PSTs used to be limited to 2GB file sizes. If a PST grew larger than that, it would end up corrupted and needed to be fixed (with pst2gb.exe). To accommodate larger files, Microsoft introduced the Unicode format with Office 2003, but for a long time the new Unicode format wasn’t supported by the Exchange Migration Wizard (migwiz.exe) and PSTs in Office 2003 did not always migrate gracefully.
5. PSTs are excluded from synchronization of offline files and excluded from use with programs like Windows Live Mesh.

In the old days, avoiding problems with PSTs would mean you would have large Exchange databases (with long backup windows, restore times, etc.), extensive Exchange Public Folder stores (without quotas) or an expensive mail archiving solution. Not quite desirable solutions either.

…and now, for someting positive

As I stated at the beginning of this blogpost, I would say something nice about PSTs.

The positive thing is Microsoft has executed on the extinction of PST files in small to medium-sized networking infrastructure environments, removing most of the barriers in place:

Exchange Archiving

No longer do you have to invest in an expensive mail archiving solution. Exchange Archiving is now built into Exchange Server and Exchange Online, with users being able to access their archives with Microsoft Outlook (as part of Office Professional Plus) and Outlook Web App (OWA).

The archiving database is separate from the Exchange private store and, thus, does not interfere with the backup and restore of this database. If you do want to get rid of archives, put them in Exchange Online.

PST Capture

Microsoft, earlier this week, has released a free tool to track down PSTs in networking environments. It’s called Exchange PST Capture and you can use it to discover and import PSTs into Exchange Server and Exchange Online. PST Capture helps. By optionally installing PST Capture Agents on target machines, you can determine where PSTs are located and who their owners are via the PST Capture Console.

Now, not only does Exchange Server and Exchange Online offer archiving, you can also track down any existing PSTs and put them into their owners’ respective archives automatically.

So, if you been waiting to get rid of those PSTs, then now is the time!

Download

Microsoft Exchange PST Capture free

Further reading

Sean McNeill - Hands on with the PST Capture Tool
PST Capture 
.PST Capture is now available as a free download
Outlook Blog – PST Capture: New tool to manage those ever multiplying inboxes 
Microsoft Exchange PST Capture tool released! 
Microsoft Exchange PST Capture Tool 
Microsoft PST Capture Tool for Exchange 2010 and Office 365 released 
Bink.nu - Microsoft Exchange PST Capture tool released
.PST, Time to Walk the Plank

Many software vendors and organizations have adopted workflow tools to accommodate their needs towards faster delivery of the same quality. At least, getting an OK from a senior executive, is something that can be automated to save time, right? Another angle a lot of organization explore is Delegation of Control. Why wait for a centralized admin over in India to perform a (small) action, when you can have a super user, HRM executive or concierge to perform it too?

Most organization, however, don’t get very far in their efforts. The reason, mainly, is the lack of understanding of the business by the IT-department, causing a missing policy. Another reason might be, that solutions that offer full workflow capabilities, like System Center Orchestrator, are deemed too expensive. Another big reason is executives might believe they’ll have to be charged more once charge-back is introduced or at least when IT usage becomes more transparent. These organization don’t have much to gain with workflows. Or so it seems.

For these kinds of organizations, Denny from Zohno has created two applications, that can be used to delegate two particularly simple (but often fought over) tasks:

• Hiring new personnel and entering their basic information in the core applications
• Terminating a persons contract and removing the person from the core applications, without information getting lost.

Best of all: these two applications are complete freeware!

Z-Hire

Z-Hire automate IT account creation process including Active Directory account, Exchange mailbox and Lync account. With a click of a button, an Active directory account, Exchange mailbox and Lync account will be created. Traditionally, this process might take over 3 minutes, but with Z-Hire, this can be done in matter of seconds. Features include:

• Active Directory account creation with major attributes
• Active Directory group selection
• Exchange 2007 / 2010 Mailbox creation, support for ActiveSync, Managed folder policy and more…
• Lync 2010 account creation supporting External Policy and Conferencing policies

Download Z-Hire from the TechNet Gallery here.
  

Z-Term

This application allows IT administrators to automate common tasks when an employee leaves the company. Usually, IT administrators use multiple consoles and perform a variety of tasks to terminate user accounts. Z-Term allows IT administrator to automate:

• Disable the Active Directory account
• Reset the user’s password in Active Directory
• Move the user account to an Organizational Unit (OU) of your choice
• Remove AD Group membership

Note: This action removes the user from all Active Directory groups.

• Change Distribution list ownership (the managedby property)
• Hide the user from Outlook Global address list in Exchange
• Set an Out of Office autoreply of your choice
• Forward the user’s emails to someone else
• And more to come in next version…

Download Z-Term from the TechNet Gallery here.

Both these tools, with proper Delegation of Control (DoC) and Role-based Access Control (RBAC) under the hood, can be used to allow a super user, HRM executive or concierge to hire and/or terminate accounts in a way, even they can remember.

As an IT Professional, dedicated to help people out by sharing the information I research and uncover, I have donated much of my time to help the Dutch Networking User Group (NGN).

Now, it’s my great pleasure to announce that on Wednesday April 17, 2013, Dave Stork and I will be presenting a 45-minute session on Managing devices through Exchange ActiveSync during the NGN Tablet Day at the Reehost in Ede, the Netherlands.*

Active Directory is the cornerstone to most networking environments, but not all devices can be domain-joined and/or managed through Active Directory. While talking about these devices with clients, most of the time, they would think of mobile devices like tablets.

Several Microsoft solutions exist to manage these devices, depending on their capabilities and organizational strategy. In some cases, Internet-based Management in System Center Configuration Manager would suffice. In other scenarios Windows Intune would be just what the doctor prescribed. Remote Access Services, DirectAccess and Remote Desktop Gateway also have their advantages, but most of the time Exchange ActiveSync is the solution that just works.

Dave and I will, once again, assume the roles of Jos Haarbos and Hans Worst and explain the inner workings, management challenges and best practices surrounding Exchange ActiveSync in all supported versions of Exchange Server and Exchange Online in a 45-minute Dutch-spoken session.

Also, KMC Solutions, the sponsor for this event, will host a follow-up session on the added value of Mobile Device Management (MDM) in contrast to ActiveSync, delivering the complete picture during the day. Since KMC Solutions is also a Value Added Reseller (VAR), they will be able to talk about licensing and licensing costs.

Tickets are available through the event page. Tickets cost € 300. Members of the Dutch Networking User Group (NGN) benefit from the lower member fare for this event (€ 125).

* It will be the third time Dave and I will be presenting this session.

Related Blogposts

Centralized iPad management with profiles and policies 
Upcoming Speaking Engagements (March & April 2012) 
Upcoming Speaking Engagements 

Further reading

NGN TabletDagDutch 
KMC Solutions - NGN TabletDag 17 April in de Reehorst te EdeDutch

This week, Microsoft has released KnowledgeBase article 2872882 today, detailing a situation where you’d receive an “Organization Preparation FAILED” error when you try to Prepare the Active Directory for Exchange Server 2007 or Exchange Server 2010.

The situation

When you try to prepare Active Directory for Exchange Server 2007 or Exchange Server 2010, during the automated installation or while manually preparing it through setup.exe /PrepareAD, you might receive the following error:

Configuring Microsoft Exchange Server
Organization Preparation   FAILED
The following error was generated when "$error.Clear();
install-ResourceConfig -DomainController $RoleDomainController" was run: "Active Directory operation failed on <Domain Controller>. This
error is not retriable. Additional information: The parameter is incorrect. Active directory response: 00000057: LdapErr: DSID-0C090D11, comment: Error in attribute conversion operation, data 0, v23f0".The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup in the <SystemDrive>:\ExchangeSetupLogs folder.

When you check the ExchangeSetup.log file (typically) in the C:\ExchangeSetupLogs folder, you find the following lines:

[Time] [2] [ERROR] Active Directory operation failed on dc. domain.com. This error is not retriable. Additional information: The parameter is incorrect.
Active directory response: 00000057: LdapErr: DSID-0C090B38, comment: Error in attribute conversion operation, data 0, vece
[Time] [2] [ERROR] The requested attribute does not exist

Note:
In the above error, the actual hostname for the Domain Controller and Active Directory Domain name have been substituted with generic values to protect the innocent.

Installation of Exchange Server fails.

The cause

This issue occurs because the lDAPDisplayName attributes for ms-Exch-Resource-Schema and ms-Exch-Resource-Property-Schema are incorrect.

The resolution

To resolve this situation, you will need to perform these steps:

1. Open Active Directory Service Interfaces (ADSI) Edit. To do this, click Start, type ADSIEdit.msc, and then click OK.
    
        Note:
        On pre-Windows Server 2008 Domain Controllers, use Start + R.
    
2. After the ADSI Edit window is loaded, right-click ADSI Edit in the navigation pane, and then click Connect To.
3. In the Connection Settings window, click Select a well known Naming Context in the Connection Point area, and then click Schema.
4. Expand the Schema [DC.domain.com] node, and then click CN=Schema, CN=Configuration,DC=domain,DC=com.
   
        Note:
        Substitute the values for domain and com to your values.
   
5. In the result pane, right-click CN= ms-Exch-Resource-Schema, click Property, and then change the value of the lDAPDisplayName attribute to msExchResourceSchema.
6. In the result pane, right-click ms-Exch-Resource-Property-Schema, click Property, and then change the value of the lDAPDisplayName attribute to msExchResourcePropertySchema.
7. Close Active Directory Service Interfaces (ADSI) Edit.

In environments with multiple Domain Controllers, force Active Directory replication between them with the following command:

1. Open Active Directory Sites and Services. To do this, click Start, type DSSite.msc and then click OK.
       
        Note:
        On pre-Windows Server 2008 Domain Controllers, use Start + R.
    

2. After the Active Directory Sites and Services windows is loaded, in the console tree, expand Sites, and then expand the site to which you want to force replication from the updated server.

1. Expand the Servers container to display the list of servers that are currently configured for that site.

2. Expand the server objects and click their NTDS Settings objects to display their connection objects in the details pane. Find a server that has a connection object from the server on which you made the updates.

3. Click NTDS Settings below the server object. In the details pane, right-click the connection object whose From Server is the Domain Controller that has the updates that you want to replicate, and then click Replicate Now.

4. When the Replicate Now message box appears, review the information, and then click OK.

Now, run the Setup.exe /PrepareAD command to prepare Active Directory for Exchange Server 2007 and/or Exchange Server 2010 again. It will succeed.

Related KnowledgeBase articles

2872882 "Organization Preparation FAILED" error when you install Exchange Server 
948214 You may receive an "error code 8202" error message when you try to install Exchange Server 2007 Service Pack 1 

Further reading

TechNet Forums - Exchange 2007 sp1 setup fails with code 8202  
Force Replication Between Domain Controllers  

Acknowledgements

This topic was brought to my attention by Johan Veldhuis, an Exchange Server MVP.

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.

Previously, we’ve looked at the WorkPlace Join functionality in Active Directory Federation Services (AD FS) in Windows Server 2012 R2 (and up) and the accompanying Registered Device objects in Active Directory Domain Services (AD DS).

When WorkPlace Join is enabled for a networking environment, by default anyone has the right to WorkPlace Join devices, by default.

In Active Directory Domain Services, a special container is created for Registered Devices: the msDS-DeviceContainer. This is the default location where WorkPlace-Joined device have their registered device object (msDS-Device) stored.

On this container, Authenticated Users have read rights, just like they do in the greater part of the Active Directory. However, the Device Registration Service (DRS) service account in Active Directory Federation Services (AD FS) has an awful amount of rights on the container and actually creates the Registered Device object in Active Directory Domain Services.

Note:
By default, the service account for Device Registration Service (DRS) is the same as the service account for Active Directory Federation Services (AD FS).

Since Device Registration is a Relying Party Trust in Active Directory Federation Services (AD FS), the most logical way to look at granularly revoking access is to modify the Issuance Authorization Rules.

Perform these steps to gain access to the authorization rules for the Device Registration Service (DRS) in Active Directory Federation Services:

• Log on with an account that has Domain Administrator rights on a device that is capable of running the Windows Server 2012 R2 version of the AD FS Management Management Snap-in (Microsoft.IdentityServer.msc).
• In the left pane, open Relying Party Trusts.
• In the main pane, now select Device Registration Service and, then, in the (right) task pane click the Edit Claim Rules… shortcut. This will open the Edit Claim Rule for Device Registration Service window:

• Click on the second tab, labeled Issuance Authorization Rules.

• Here you’ll find the Permit Access to All Users rule.

Changing access to WorkPlace Join

Depending on your scenario, you might want to specifically permit or specifically deny users that are member of specific group(s):

Permitting WorkPlace Join only for a specific group

If you want to permit the use of the Device Registration Service (DRS) and thus the ability to WorkPlace Join devices to only colleagues that are members of a specific group or a couple of specific groups, create a new Issuance Authorization Rule:

• Click the Add Rule… button.
• The Add Issuance Authorization Claim Rule Wizard appears. Its first screen is the Select Rule Template screen.

• As the Claim rule template: select the default Permit or Deny Users Based on an Incoming Claim. Press Next >.
• In the Configure Rule screen, type a suitable name in the field below Claim rule name:. Then, as the Incoming claim type:, select Group SID from the drop-down list.

• Click Browse… to browse for a group or a set of groups that you want to explicitly permit.

• Press OK when done.
• Press Finish in the Add Issuance Authorization Claim Rule Wizard window to create the Issuance Authorization claim rule.In the Edit Claim Rules for Device Registration Service window, select the Permit Access to All Users rule. Click the Remote Rule… button.
• Click Yes to answer Are you sure you want to delete this claim rule?.

Note:
If you have no Issuance Authorization rules to Permit claims, no one will be able to use Device Registration Service (DRS) and thus no one will be able to WorkPlace Join devices.

• Click OK to close the Edit Claim Rules for Device Registration Service window.

Denying WorkPlace Join for a specific group

The other method is to deny a specific group of colleagues the use of the Device Registration Service (DRS) and thus the ability to WorkPlace Join devices. While this sounds harsh, there might actually be good reasons to deny this right to specific groups, like the Protected Users group.

Note:
Membership to the Protected Users group protects a lot of older insecure access protocols, but it does not deny WorkPlace Join, by default.

Let’s create a new Issuance Authorization Rule that denies this group that right:

• Click the Add Rule… button.
• The Add Issuance Authorization Claim Rule Wizard appears. Its first screen is the Select Rule Template screen.
• As the Claim rule template: select the default Permit or Deny Users Based on an Incoming Claim. Press Next >.
• In the Configure Rule screen, type a suitable name in the field below Claim rule name:. Then, as the Incoming claim type:, select Group SID from the drop-down list.
• Click Browse… to browse for a group or a set of groups that you want to explicitly deny.
• Press OK when done.
• Select Deny access to users with this incoming claim.

• Press Finish in the Add Issuance Authorization Claim Rule Wizard window to create the Issuance Authorization claim rule.
• In the Edit Claim Rules for Device Registration Service window, Select the Permit Access to All Users rule. Move this rule down in the order in which the Issuance Authorization Rules will be processed, by clicking the blue down arrow to the right of the list with rules.

Note:
It is a best practice to place rules with Deny issued claims above rules with Permit issued claims. Place the Permit Access to All Users as the last rule, when possible.

• Click OK to close the Edit Claim Rules for Device Registration Service window.

Concluding

Since the Device Registration Service (DRS) is a Relying Party Trust in Active Directory Federation Services (AD FS), the most logical way to look at granularly granting or revoking access to it is to modify the Issuance Authorization Rules.

Related blogposts

WorkPlace Join vs. Domain Join
New features in Active Directory Domain Services in Windows Server 2012 R2, Part 5: WorkPlace Join and Registered Device objects

Further reading

Set-AdfsRelyingPartyTrust
When to Use an Authorization Claim Rule
The Role of Claim Rules
The Role of the Claims Pipeline

When we discussed the WorkPlace Join functionality in Active Directory Federation Services in Windows Server 2012 R2 (and up) and the accompanying Registered Device objects in Active Directory Domain Services, you might have gotten the feeling that the directory might get cluttered with Registered Devices.

Microsoft has built in a feature in the Device Registration Service (DRS) that makes it automatically clean up unused devices, by default. Its default setting is 90 days.

The Device Registration Service (DRS) is the part of Active Directory Federation Services that is responsible for WorkPlace Join. Since the Device Registration Service (DRS) is part of Active Directory Federation Services ‘unused days’ can best be interpreted as ‘the amount of days before a device object is removed because of inactivity in accessing claims-based resources involving the AD FS infrastructure the DRS is part of’. Popularly speaking, when you’re not using the single sign-on functionality of WorkPlace Join, Microsoft feels it can disable this functionality and clean up after 90 days of you not using it.

Now, don’t get me wrong. I feel 90 days is a perfectly healthy and balanced value for this behavior of the Device Registration Service (DRS) in most environments.

However, you might want to change it.

Changing the inactivity time-out

The Device Registration Service (DSR) is exposed for authentication and authorization in Active Directory Federation Services (AD FS), but has its own distinct endpoint and service. Much of that is controlled to DRS-specific PowerShell Cmdlets.

You can change the inactivity time-out with the following steps:

• Log in with an account that is a member of the Domain Admins group to a device capable of offering the Active Directory Federation Services 3.0 PowerShell module.
• Start PowerShell
• Perform this PowerShell one-liner:

Set-AdfsDeviceRegistration -MaximumInactiveDays n

You can specify a value between 0 and 1000 for n. When you specify 0, the Device Registration Service (DRS) will no longer clean up inactive WorkPlace-joined devices.

• Exit PowerShell and log off, or type logoff directly in PowerShell.

Tip!
You can check the current number of days before the Device Registration Service (DRS) in Active Directory Federation Services (AD FS) deletes Registered Devices using the Get-AdfsDeviceRegistration PowerShell Cmdlet. You can also use this Cmdlet to check your change.

Best practices

As noted earlier, I think the default 90 days value is a healthy and balanced value for the inactivity clean-up time-out for the Device Registration Service (DRS) within Active Directory Federation Services (AD FS).

You might want to clean up unused devices more frequently, because typically you use the WorkPlace Join functionality for contractors that are assigned for a far shorter period to your organization. In terms of security, you might also want the trusted combination of user and device to expire faster than 90 days of inactivity.

You could clean-up inactive user/device combinations faster, but configuring it too short might only prove it an inconvenience to colleagues using claims-based apps often, either because they want single sign-on functionality or either because you utilize WorkPlace Join as an authorization mechanism. Additionally, you run the risk of RID Pool depletion in Active Directory Domain Services.

You want to clean up unused devices less frequently, because you experience colleagues use claims-based application less frequently than 90 days and are prompted to WorkPlace-join devices. I can think of a couple of applications I only use once or twice per year.

This other side of the spectrum might also prove tricky. Not cleaning up inactive devices might expose single sign-on access to apps on devices that are no longer used, were lost or stolen (but never reported as such).

Concluding

You can change the inactivity clean-up time-out for the Device Registration Service (DRS) within Active Directory Federation Services (AD FS) with the Set-AdfsDeviceRegistration PowerShell Cmdlet. Use sensibly.

Related blogposts

Granularly permitting or denying the right to WorkPlace Join
WorkPlace Join vs. Domain Join
New features in AD DS in Windows Server 2012 R2, Part 5: WorkPlace Join and Registered Device objects

Further reading

Set-AdfsDeviceRegistration
Get-AdfsDeviceRegistration
ADFS 3.0: Enabling Device Registration Service (DRS)
AD FS W2012 R2 – Workplace Join via WAP
Conditional Access with Azure Device Registration Service (aka Workplace Join)