Publishing Work Folders with Web Application Proxy

Work Folders and the Web Application Proxy are probably two of the most exciting new features in Windows Server 2012 R2 and Windows 8.1. These features create a whole lot of new possibilities for Bring Your Own Devices to provide controlled access to data stored on the corporate network. I had already checked out Work Folders and the Web Application Proxy. But what about using these together? This enables corporations to use the Web Application Proxy for claims based pre-authentication and to add Multi Factor Authentication.

A few weeks ago I started building the lab environment setup for AD FS and Connect to applications and Services with Web Application Proxy as described on TechNet. As an addition to these walkthroughs, I published a walkthrough how to setup a PKI for the Workplace Join Lab.

The resulting topology of these very useful step-by-step articles looks like this:

If this is all working, you have the ideal start for the final goal of this article. Only the Work Folders server is still missing.

Important note:
For the entire setup, ensure that you are using Windows Server 2012 R2 and Windows 8.1 with at least the following hotfixes installed:

  • KB2887595
  • KB2883200

Please make sure that you have the previous labs working before you proceed.

For the rest of this article I got lots of information from the Windows product team that also publishes on FileCab. Without their help this article would have never seen the day of light. Checkout FileCab for more information about Work Folders and other Microsoft storage technologies.

Step 1: Setup a Work Folder share with SSL encryption

As this article is about publishing Work Folders, you also need to setup a Work Folders server on the internal network. The step-by-step for setting up Work Folders on TechNet describes how to setup Work Folders without SSL. Without SSL Work Folders cannot be published with the Web Application Proxy, as the Web Application Proxy can only publish https and not http.

You can still use the guide to setup a Work Folders server to publish externally, but skip the section “Lab testing specific settings” that enables the client to use http instead of https to connect to the Work Folders share.

Configure the Work Folders Server with SSL

  • Obtain and install an SSL Certificate for the Work Folders server. Make sure the certificate contains DNS entries for both the server FQDN and for the Work Folders host in your domain. My DNS entries looked like:
  • Get the certificate Thumbprint of the certificate in PowerShell. Start PowerShell and type the following command:
    • Get-childitem –Path cert:\LocalMachine\My
  • Bind the certificate to the Work Folders service from the Comand prompt. Start an elevated Command prompt and run the following command, replacing <Cert thumpprint> with the value you just obtained:
    • netsh http add sslcert ipport= certhash=<Cert thumbprint> appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=My

Now test if you can access the Work Folders from a client on the internal network as described in “Step 11: Work Folders setup” from step-by-step for setting up Work Folders on TechNet.

The topology should now look like this:

Configure the Work Folders Server for AD FS Authentication

In order to publish Work Folders with Web Application Proxy, the Work Folder server must use AD FS (OAuth2) authentication instead of Windows Authentication.

On the Work Folders Server, open Server Manager and browse to File and Storage Services | Servers. Right click the server name and select Work Folders Settings.

In the Work Folders Settings Dialog, under Authentication, select Active Directory Federation Services. Type the FQDN of the ADFS server as the Federation Service URL, and click OK.

You can also use PowerShell to configure the Work Folder Server for AD FS authentication using the following command:

  • Set-SyncServerSettings -ADFSUrl <AD FS URL>

Step 2: Configure the ADFS Server

This was the hardest part of building this infrastructure. At this point I expected to find an XML somewhere, defining the Relying Party Trust (RP) to import on the AD FS server. Just like the procedure used to create the RP for claimapp in the AD FS lab. Unfortunately there is no such file, and we have to use a PowerShell script to create the RP.

The Relying Party settings must include the UPN in the claims since the Work Folders will use it to impersonate as the user.

Here is the script I used:


$ECSIdentifier = "https://Windows-Server-Work-Folders/V1";
$ECSDisplayName = "EnterpriseClientSync";
$TransformRuleString = '@RuleTemplate = "LdapClaims" @RuleName = "Ldap" c:[Type == "", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("", "", "", ""), query = ";userPrincipalName,displayName,sn,givenName;{0}", param = c.Value);' ;
$AuthorizationRuleString = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "",Value = "true");' ;
Add-ADFSRelyingPartyTrust -Identifier $ECSIdentifier -Name $ECSDisplayName -IssuanceTransformRules $TransformRuleString -IssuanceAuthorizationRules $AuthorizationRuleString -EncryptClaims:$false -EnableJWT:$true -AllowedClientTypes Public;


Notice that the RP Identifier is hardcoded as https://Windows-Server-Work-Folders/V1. There is no need to reference the identifier to the actual server running Work Folders. A reference to the actual server is only needed when the server is being published from the Web Application Server as described in the following section.

Step 3: Configure the Web Application Proxy

First obtain the SSL certificate for publishing the Work Folders server. If you already have a wildcard certificate on the Web Application Proxy, you can use that to publish Work Folders. Otherwise you require a certificate that contains at least the entries as described for the Work Folders Server.

Now, obtain the SSL certificate thumbprint you will use to publish the Work Folders server. You will need the thumbprint later to publish Work Folders with PowerShell.

You can use PowerShell to obtain the thumbprint. Start PowerShell and type the following command:

  • Get-childitem –Path cert:\LocalMachine\My

Copy the thumbprint from the certificate that you will use to publish Work Folders.

Check the Web Application Proxy configuration for the existence of the OAuth URL. Work Folders can only be published using OAuth2. This requires the existence of the OAuth URL.

You can use PowerShell to obtain the current value of the OAuth URL. Start PowerShell and type the following command:

  • Get-WebApplictionProxyConfiguration

Check if the value of OAuthAuthenticationURL looks like https://$farmFqdn/adfs/oauth2/authorize

Now you can use PowerShell to publish the Work Folders Server with OAuth. Start PowerShell and run the following script, replacing * with the CN of your public certificate and with the FQDN of your file server:

$cert = Get-childitem –Path cert:\LocalMachine\My | Where-Object -Property Subject -EQ -Value "CN=*"
$WAPAppName = "EnterpriseClientSync"
$ExternalURL = ""
$BackEndServerURL = ""
Add-WebApplicationProxyApplication -Name $WAPAppName -ExternalURL $ExternalURL -ExternalCertificateThumbprint $cert.Thumbprint -BackendServerUrl $BackEndServerURL -ExternalPreauthentication ADFS -ClientCertificateAuthenticationBindingMode None -BackendServerCertificateValidation None -ADFSRelyingPartyName EnterpriseClientSync -UseOAuthAuthentication


Just like Exchange, Work Folders has an AutoDiscovery mechanism that refers users to their appropriate Work Folders Server. AutoDiscovery works out of the box on the corporate network, when a CNAME record named ‘workfolders’ is created in DNS that links to the Work Folders server.

Publication of AutoDiscovery requires an extra rule on the Web Application Proxy. I tested this with a single Work Folders server on the corporate network. It enables a user to connect to his/her Work Folder by only supplying the users’ UPN. Without the extra rule, the user must address his/her specific Work Folders Server URL.

You can use the following PowerShell script to publish AutoDiscovery. The publishing rule refers to the http url of the Work Folders server. As this is traffic on the internal network it is not considered as an additional risk.

$WAPAppName = "WorkFoldersDiscovery"
$ExternalURL = ""
$BackEndServerURL = ""
Add-WebApplicationProxyApplication -Name $WAPAppName -ExternalURL $ExternalURL -ExternalCertificateThumbprint $cert.Thumbprint -BackendServerUrl $BackEndServerURL -ExternalPreauthentication ADFS -ClientCertificateAuthenticationBindingMode None -BackendServerCertificateValidation None -ADFSRelyingPartyName EnterpriseClientSync -UseOAuthAuthentication


When services like Work Folders and Device Registration are published outside of the corporate network, it is required to use a split-DNS setup. This means that you will be using the same hostnames on the outside as you are using on the inside. Only on the outside the IP addresses will differ from the addresses on the inside. The outside addresses will typically refer to addresses hosted on the external interface of the Web Application Proxy. As the Web Application Proxy supports Single Name Indication (SNI), you are now able to host multiple SSL hostnames on a single IP address.

In my demo environment the external DNS zone currently looks like this:

Hostname Type Data






If DNS for you domain contains the required records, you should now be able to access Work Folders through the Web Application Proxy.

The final topology should now look like this:


During the process, I found out that things will go wrong. When something goes wrong you should check for details in the event logs. Most of the times these log entries will provide the extra information required to fix your issues. If the message doesn’t make sense, ensure that you installed the required updates.

These are my most consulted event logs:

  • On the client
    • Applications and Services Logs\Microsoft\Windows\WorkFolders\Operational
  • On the Web Application Proxy
    • Applications and Services Logs\Microsoft\Windows\Web Application Proxy\Admin
  • On the AD FS Server
    • Applications and Services Logs\AD FS\Operational

This takes me to the end of my longest blog article ever. Many thanks to the Windows product team for helping me to work this out.

Posted in Security, Web Application Proxy, Windows 8.1, Windows Server 2012 R2, Work Folders | 7 Comments

Building the PKI for the Workplace Join Lab with an OCSP Responder

Last month I have been busy building the lab environment to demonstrate Workplace Join with Windows 8.1 and Windows Server 2012 R2. Microsoft created an excellent walkthrough to build the lab environment starting with AD FS. While working my way through the demo I noticed that Workplace Join is very picky when retrieving the certificate revocation list for the certificate used for the AD FS service. The lab set up refers to Configure SSL/TLS on a Web site in the domain with an Enterprise CA to set up the Public Key Infrastructure. But this reference does not contain the steps to set up a working PKI. Here is my fix for this omission.

This time I setup the PKI with an OCSP Responder. The previous setup with an published CRL, expires the CRL every few days. This requires a manual action to republish the CRL. With the OCSP Responder server this is no longer the case.

Disclaimer: The following steps are for setting up PKI for a DEMO ENVIRONMENT. It is NOT meant as a solution for building a production PKI.

You can use the Domain Controller in the lab environment as the Certificate Authority or set up a separate server that is joined in the domain. In my case I used the Domain Controller to setup the CA.

Step 1: Configure the Domain Controller

I used the following PowerShell commands to setup the Domain Controller for

Install-WindowsFeature AD-Domain-Services –IncludeManagementTools

Install-ADDSForest -DomainName “” -ForestMode 5 -DomainMode 5 -DomainNetbiosName “nextxpert”

Step 2: Configure the Certificate Authority with Active Directory Certificate Services

Install Active Directory Certificate Services and the Online Responder

I used the following PowerShell commands to install AD CS:

Install-WindowsFeature ADCS-Cert-Authority,ADCS-Online-Cert –IncludeManagementTools

Configure the Certificate Authority

I used the following PowerShell commands to set up the Enterprise Root CA:

Install-AdcsCertificationAuthority -CAType EnterpriseRootCa -CACommonName HyperxpertRootCA -CryptoProviderName “RSA#Microsoft Software Key Storage Provider” -KeyLength 2048 -HashAlgorithmName SHA1 -ValidityPeriod Years -ValidityPeriodUnits 5

Configure the CRL Distribution Point on the CA

Start the Certificate Authority MMC

Right click the CA name and select Properties

In the CA Properties dialog select the Extensions tab

On the Extensions tab select Authority Information Access (AIA), and then click Add.

In the Add Location dialog, type the following location: http://<ServerDNSName>/ocsp and click OK.

In the Extensions tab, enable the following option:

  • Include in the online certificate status protocol (OCSP) extension

Click OK, and restart the service when prompted.

Enable the OCSP Signing certificate template on the CA

Start the Certificate Authority MMC

Right click the Certificate Templates and select New | Certificate Template to Issue

Select OCSP Response Signing, and click OK

Publish the Revocation List

In the Certificate Authority MMC right click Revoked Certificates

Select All Tasks | Publish

In the Publish CRL dialog, select New CRL and click OK

Step 3: Configure the Certificate Template ACLs

The Enterprise CA can only enroll certificates from templates when the template ACLs are properly configured. The following procedure shows how to enable Domain Computers to enroll WebServer certificates. If you are running ADFS on a Domain Controller, make sure you also allow the group Domain Controllers to enroll certificates from the template.

Start Active Directory Sites and Services

Browse to Services\Public Key Services\Certificate Templates

Right click the WebServer certificate template and select Properties

On the Security tab add the group Domain Computers and allow Read and Enroll

If AD FS is running on a Domain Controller, also add the group Domain Controllers and allow Read and Enroll

Right click the OCSPResponseSigning certificate template and select Properties

On the Security tab add the group Domain Computers and allow Read and Enroll, and the group Domain Controllers and allow Read and Enroll.

Step 4: Configure the Online Responder

Under Tasks, select Configure Active Directory Certificate Services on th…

In the AD CS Configuration dialog, credentials screen specify the credentials for a member of the Enterprise Admins group and click Next.

In the Role Services screen, enable Online Responder, click Next and then click Configure.

Click Close when the Online Responder is successfully configured.

Open Online Responder Management

Right click, Revocation Configuration and then click Add Revocation Configuration

In the Add Revocation Configuration wizard, click Next in the getting started page.

Enter a name for the Revocation Configuration and click Next.

Select, Select a certificate for an Existing enterprise CA, and click Next

Select, Browse CA certificates published in Active Directory, and click Browse…

In the Select Certification Authority dialog, select the Enterprise Root CA, and click OK, then click Next

In the Select Signing Certificate page, select Automatically select a signing certificate, enable Auto-Enroll for an OCSP signing certificate, and then click Next

Click Finish to end the wizard

Now restart the server running the OCSP Responder

Step 5: Enroll the Web Server Certificate on a Domain Member Server

Use the following procedure to enroll the WebServer certificate on a Domain Member Server

Start certlm.msc

Browse to Certificates\Personal\Certificates

Right click Certificates and select All Tasks | Request New Certificate…

In the Certificate Enrollment wizard, click Next twice

In the Request Certificates dialog, select Web Server, expand the Details and click Properties

In the Certificate Properties, configure the subject name and Alternative names (when applicable) and click OK

Now click Enroll

Click Finish

Step 6: Test if the OCSP Responder is functional

On the server with the enrolled certificate, export the newly enrolled Web Server certificate to a file.

On the Command Prompt, use CertUtil.exe to check OCSP operation. Use the following command to do the test:

CertUtil –URL <certificate.crt>

In the URL Retrieval Tool, select OCSP (from AIA), and click Retrieve

Check if the status for the OCSP is “Verified“.

If all is fine, you can now continue building the Workplace Join lab environment with a working PKI

Posted in PKI, Windows 8.1, Windows Server 2012 R2 | Tagged , | 2 Comments

Demystifying AppContainers (Part II)

In my previous post I explained how Windows 8 uses AppContainers to create a sandbox for Modern UI Apps. Capabilities define what an App can do outside of the sandbox. An app is required to use use specific API calls and broker processes for its actions outside of the sandbox.

Anyone who will ever create a Modern UI App for the Windows Store has to obey Microsoft rules for app development. Rule #1 is that the app will run in an AppContainer and must declare only the minimum list of capabilities that your app needs for its core functionality. Some capabilities appear to be more special than others. If your Modern UI App requires capabilities like enterpriseAuthentication, sharedUserCertificates, or documentsLibrary, you are subject to even more strict rules and additional review and testing.

Internet Explorer appears to be a special case when you look at its capabilities. Internet Explorer is Trusted and allowed to use all System capabilities. At least, that is what the UI says…

Being trusted and able to use all system capabilities doesn’t sound like the minimum list of capabilities for Internet Explorer. Is this true?

Internet Explorer Architecture before Windows 8

Let’s first look at a little history of Internet Explorer before Windows 8
Internet Explorer has its own sandbox infrastructure since Windows Vista. It runs in Protected Mode while you are surfing the Internet. When you start Internet Explorer, two processes are created:

  1. The frame process that contains the address bar and manages the content processes
  2. The content process that show the web content to the end user

The frame process runs at the same security level as your other processes. It can access every resource just like any other application. The content process on the other hand is started in Protected Mode and runs at the low integrity level. Processes running at the low integrity level have limited write access to the system. Only objects (for instance files or registry keys) that have the low integrity level can be changed by low integrity level processes. This is one of the reasons that you will find the LocalLow folder in the user profile under %userprofile%\AppData. This is one of the specific locations where Internet Explorer in Protected Mode can write data, because the folder has the Low integrity level.

Internet Explorer in Protected Mode also has limited options to communicate with higher level processes. User Interface Privilege Isolation (UIPI) filters its communication to make sure that only specific information can be passed to specific other processes. This allows you to download data from the Internet to a folder that does not have the low integrity level. When you download a file iexplore.exe calls a broker process IEUser.exe that runs at the Medium integrity level to save the file in the correct location.

Enhanced Protected Mode

Windows 8 introduces Enhanced Protected Mode. This is the default behavior for Internet Explorer in its Modern UI appearance on Windows 8. Enhanced Protected Mode means that iexplore.exe is not only running at the Low integrity level, but also that it runs in an AppContainer. Internet Explorer on the Desktop by default runs in Protected Mode at Low integrity level, like in previous Windows versions.

Enhanced Protected Mode is more secure, because it removes unlimited read access to the system. In the hypothetical case that some malware injects the Internet Explorer process, a Low integrity level process can virtually read all the data on your system and get away with it. With Enhanced Protected Mode, such a malicious piece of code cannot access resources outside of the AppContainer.

On 64-bit systems, Internet Explorer in Protected Mode is always running as a 32-bit process. This allows for better compatibility with add-ons and plug-ins. On 64-bit Windows, Internet Explorer with Enhanced Protected Mode always runs as a 64-bit process.

Enhanced Protected mode can be enabled for Internet Explorer on the Desktop. When Enhanced Protected Mode is enabled, Internet Explorer runs in an AppContainer.

IE 10 in Windows 8 Pre-RTM

In the blog on Enhanced Protected Mode in Internet Explorer by Eric Law [ex-MSFT], Eric describes how Internet Explorer in Enhanced Protected Mode in Windows 8 Release Preview runs in an AppContainer that lacks the following capabilities:

  • privateNetworkClientServer
  • enterpriseAuthentication
  • Music Library
  • Pictures Library
  • Video Library

These missing capabilities seriously limited the use of Internet Explorer in Enhanced Protected Mode. As Enhanced Protected Mode is the default for the Internet Explorer running with the Modern UI, it invalidated the Modern UI for use in corporate networks where integrated authentication is a common practice. Eric also describes how Enhanced Protected Mode disables access to private networks, like when trying to access the management site of an internal router on a home network.

IE 10 in Windows 8 RTM

Microsoft made some interesting changes to Internet Explorer when RTM was released. Enhanced Protected Mode is still there. But the Modern UI Internet Explorer behaves much more like its desktop UI processes.

When a user starts Internet Explorer in the Modern UI, it creates a minimum of two process. The frame process and one or more content processes. The frame process manages stopping and starting of content processes when required. The Internet Explorer frame process runs at the Medium integrity level. This is default behavior for processes running on the desktop, but absolutely not done for applications running as a Modern UI app. When you start Internet Explorer in the Modern UI, two processes are created:

  1. The frame process, running at the Medium integrity level
  2. A content processes running in an AppContainer (Enhanced Protected Mode) when browsing the Internet

The question now is: What capabilities are there for Internet Explorer in Enhanced Protected Mode?

Process Explorer provides the answer.

The following capabilities are listed for the content process:

Capability Friendly name
Your Internet conection Your Internet connection
S-1-15-3-3215430884-1339816292-89257616-1145831019 Your location
S-1-15-3-3845273463-1331427702-1186551195-1148109977 Show Status on your lock screen and/or Show notifications
S-1-15-3-4096 <no friendly name available>
S-1-15-3-787448254-1207972858-3558633622-1059886964 Your Webcam and/or your Microphone
Software and hardware certificates or a smart card Software and hardware certificates or a smart card

This list is not even near the complete list of available capabilities on the system. It seems as if Internet Explorer in Enhanced Protected Mode has the same restrictions as described for Windows 8 RC.

But wait a second. Can’t we use Internet Explorer in Enhanced protected mode to browse on the internal network at home?

Let’s give that one a try and watch the result.

Internet Explorer in Enhanced Protected Mode does not have the privateNetworkClientServer capability. When you select “Turn on access” Internet Explorer will start a new process with added capabilities.

In the new process the following capabilities are added:

  • Your home or work networks
  • Your Windows credentials

This is still not quite the complete list of capabilities.

Jumping out of the AppContainer

Things get freaky when you are running the Modern UI Internet Explorer on a system that is a domain member. When you now browse to site on the Internal network, no questions are asked and you will get a new content process that does not run in an AppContainer.

Yes, it is true. You will get a Modern UI Internet Explorer session running at Medium integrity level without an AppContainer! This is when Internet Explorer is trusted and able to use all system capabilities…

This is the same behavior we know from Internet Explorer on the desktop. When browsing the Intranet zone, Internet Explorer is not running in Protected Mode. This is the default configuration for the Intranet zone.

The frame process running at the Medium integrity level already is a curiosity on Windows 8 as every other Modern UI app will always start in an AppContainer at the Low integrity level. With a content process running at the Medium mandatory level, Internet Explorer appears to cross the borders that Microsoft created for Modern UI apps.

Internet Explorer requires the Medium integrity level on the intranet when you use it to open Office documents from SharePoint for instance. Running at the mandatory level allows IE to do all sorts of stuff that you do in a trusted environment. Things like starting a new process for about any application at the medium mandatory level cannot be done from a Low integrity level process. And processes in an AppContainer are running at the Low integrity level.

The behavior of Internet Explorer drove the people at Mozilla crazy when they tried to create a Modern UI version of their browser. Mozilla wants to be able to browse the Internet from a browser at the Medium integrity level. This is something that is considered as an unsafe practice by Microsoft. And Microsoft is not willing to change the rules for Modern UI apps. The people at Mozilla state that they require the Medium Integrity Level to load their large range of browser plugins and that the browser plugins cannot run at the Low integrity Level.

I think Microsoft has a case. Especially when you know that Google Chrome runs perfectly at the Low integrity level with even less privileges than Internet Explorer. Unfortunately Google has not yet announced a Modern UI version of their browser.

Posted in Internet Explorer, Security, Windows 8 | Leave a comment

Demystifying AppContainers in Windows 8 (Part I)

The introduction of Modern UI apps in Windows 8 has added a whole new layer of security in the operating system. Modern UI apps can be installed by standard users. In order to keep the system secure with all this added functionality, Microsoft created a sandbox architecture that is primarily used for Modern UI apps. Modern UI Apps live in an AppContainer. The AppContainer defines the sandbox and the identity of the App.

Microsoft published very little information about AppContainers. One of the most detailed articles on the Microsoft site is a blog on Enhanced Protected Mode in Internet Explorer by Eric Law [ex-MSFT]. The article was written in the Windows 8 Release Preview time frame and partly contains outdated information about IE10. Eric Law mentions the following on AppContainers: “Windows 8 introduces a new process isolation mechanism, called AppContainer, that offers more fine-grained security permissions and which blocks Write and Read Access to most of the system. There’s not a lot of documentation specifically about AppContainer because all Metro-style applications run in AppContainers, so most of the documentation is written from that point of view.”

Running in an AppContainer means that a process can by default only access its install folder and subfolders without user interaction. Other areas of the system can only be accessed after explicit user interaction or when this is defined during install with specific capabilities. This means that a Modern UI app like Adobe Reader requires no system capabilities to let you browse to a PDF. The Music app for instance requires a capability to access the Music Library and create an index of your music. Capabilities are also required for Modern UI apps to make use of specific hardware like the camera or microphone on the system.

A new SID on the block

The AppContainer in Windows 8 is defined as a Security Identifier (SID). Before Windows Vista, only users and groups on Windows Systems had a SID. Group and User SIDs are found in the process token of each process that runs in the context of the user. SIDs are then used in Access Control Lists (ACLs) to evaluate what level of access a user gets to a resource in Windows. In Windows Vista Microsoft introduced the notion of a Services SID. Specifying a SID for a service provided new possibilities to enable a service to exclusively access certain resources. Windows Vista and later actively use the Services SID for the Windows Installer service. Due to ACLs defined on Windows system files, this is the only SID that is able to make changes to the Operating System. When a hotfix or Service Pack is installed in Windows Vista and later, this is done by the Windows Installer service. No other entity in Windows, not even SYSTEM or Administrator is able to do this without changing the ACLs of the OS system files. Doing this made it harder for malware to take over the system.
Windows Vista also introduced Integrity Levels. Integrity levels introduce mandatory access control for write access. With integrity levels it’s no longer just the user and group membership that define if a process can make changes to an object. The process must also have an integrity level that has at least the same level as the object in order to write a file or change a registry key. Windows uses the following five integrity levels:

  • System
  • High
  • Medium
  • Low
  • Untrusted

The Medium integrity level is defined as default for standard user process and objects created by the user. Elevated Administrator processes run with the high integrity level. System processes can run with the system integrity level. The low integrity level is used for Internet Explorer when browsing the Internet and Untrusted is used by Google Chrome.

Windows 8 complements the integrity levels with a new concept that blocks processes from both writing and reading outside of its boundaries: the AppContainer. The AppContainer is primarily used by Modern UI Apps. This ensures that these apps can do nothing outside their AppContainer unless they are explicitly allowed to. The AppContainer is not just there for Modern UI apps, but can also be used for Desktop applications. Currently only Internet Explorer 10 uses the AppContainer on the desktop when Enhanced Protected Mode is enabled.

Every Modern UI app gets its own AppContainer. Just like users, each AppContainer gets a unique SID. Analogous to users, Apps can be members of built-in groups that enable the app to access certain resources on a systems. For AppContainers these built-in groups are called Capabilities.

An App shows its capabilities in the Permissions section of the settings pane.

Capabilities exist in four categories:

  • Library Capabilities

    These capabilities allow an application autonomous access to a specific library. The Music app for examples requires the capability to access the Music library to create its index.

  • Device Capabilities

    Device Capabilities provide access to the microphone, camera, GPS and removable storage. Device capabilities can be interactively switched by the end user.

  • Network Capabilities

    Network capabilities allow the app access to the internal network or the Internet for outgoing or both outgoing and incoming traffic.

  • Identity Capabilities

    Identity capabilities allow an app to use the users credentials

  • System Capabilities

    System capabilities allow an app to show notifications, show status in the background and run in the background when the system is locked.

While investigating AppContainers in Windows 8 I was able to identify the following Capabilities:

  • Library Capabilities:
    • Your pictures library
    • Your music library
    • Your videos library
  • Device Capabilities:
    • Removable Storage
    • Your Webcam and/or Microphone
    • Your Location
  • Network Capabilities:
    • Your home or work networks
    • Your Internet Connection, including incoming connections from the Internet
    • Your Internet connection
  • Identity Capabilities:
    • Your Windows credentials
    • Software and hardware certificates or smartcard
  • System Capabilities:
    • Run in the background and show status on lock screen and notifications
  • Trusted (only in IE10)

Observations of app capabilities on Windows 8

The previous screenshot shows the capabilities of the built-in messaging app of Windows 8. The app has the following capabilities:

  • Software and hardware certificates or smartcard
  • Run in the background and show status on lock screen and notifications
  • Your Webcam and/or Microphone
  • Your home or work networks
  • Your Internet connection

Most capabilities seem very logical for this app, though I have no idea why the app requires access to the local network.

Now, let’s have a look at the capabilities of the Adobe Reader app.

Even without any capabilities this app is able to open your PDF documents. In order to do so the app calls a broker process, PickerHost.exe to show the files outside of the AppContainer to the end user and select the file. It is NOT Adobe Reader that loads your documents, it’s a trusted broker that is a part of the operating system that does so.

A Windows App in an AppContainer has access to a selection of broker processes to execute certain operations outside of the AppContainers boundaries.

The dark horse among Windows 8 Modern UI Apps is Internet Explorer 10. Its capabilities look like this.

Now that is a special capability! Internet Explorer is trusted and can use all system capabilities? This begs for some extra investigation.

In my next article I will write about Internet Explorer 10 in Windows 8. How I analyzed parts of its behavior and why Mozilla is angry with Microsoft.

Posted in Security, Windows 8 | 5 Comments

Case of the unexplained: whoami.exe and the Deny flag

In my TechEd sessions “Raiders of the Elevated Token” I used to demo the group memberships contained in the user token using whoami.exe. Whoami.exe is a part of Windows since Windows Vista and seemed a valid tool for this purpose until I started asking questions to Mark Russinovich.

Raiders of the Elevated Token is about User Account Control. Part of the session is about how Windows creates a restricted token for users who are a member of administrative groups. Mark Russinovich wrote a very interesting article about this subject in Technet Magazine. According to the documentation there is a fixed list of groups that are considered as administrative groups. These groups are therefore flagged for deny in the restricted user token. This way users are requested to elevated when trying to perform an action in Windows that requires membership of one or more of these groups.

For my presentation I create a domain user that I add to a number of administrative groups like Administrators, Power Users, Domain Admins, Schema Admins and Enterprise Admins. Running whoami.exe as a restricted user then shows how these groups are flagged for deny. That is for all those groups except Domain Admins. During last years TechEd I already mentioned this as unexpected behavior without further investigation.

This year I decided to go a little bit further for my presentation and I created the FoolAdmin user that I made a member of every administrative group that I could find. Then to my surprise, whoami.exe showed different results. To make a long story short. When FoolAdmin is a member of both Domain Admins and Group Policy Creator Owners, the Domain Admins group is flagged for deny according to whoami.exe. If the FoolAdmin is not a member of the Group Policy Creator Owners group, the Domain Admins group is not flagged according to whoami.exe.

Screenshots of the user token group status according to whoami.exe, Domain Admins with and without Group Policy Creator Owners

After some more testing I decided it was time to ask Mark Russinovich what’s going on. Knowing how busy Mark is and how big he is in the industry, I was very surprised to find Marks first response in my mailbox within an hour. He referred me to his article in Technet Magazine. After telling him that my findings did not reflect the behavior in the article, he asked me the obvious question: Can you send me the screenshots from Process Explorer? Well I had not used Process Explorer and I should have know that is a mistake when you start mailing Mark. Luckily Mark was willing to look at my screenshots from whoami.exe, even though he did not write that tool.

After a day Mark came back and reported that I found a bug in Whoami.exe and that I should use Process Explorer from now on to demo the contents of the user token. Process Explorer from the SysInternals site shows the correct contents of the user token. It’s a shame that Process Explorer still is a separate download and not provided with the OS.

It turns out that the results of whoami.exe regarding the deny flag status for groups in the user token are totally unreliable. And it has been that way from Windows Vista until the Windows 8 Release Preview that came out on May 31st. Let’s hope it will be fixed before Windows 8 RTMs later this year.

Thanks you Mark Russinovich for helping me solve this issue!

Raiders of the Elevated Token will be presented by Raymond Comvalius at TechEd NA on June 14th in Orlando and TechEd Europe on June 28th in Amsterdam.

Posted in Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, Windows Vista | Tagged | Leave a comment

A TechEd Story

My contribution to the Springboard Series Insider – June 2012

I’ll never forget the arrival at my first TechEd at the Côte d’Azure in France, 1997. My first international business trip ever. Completely prepared for business. Sharply dressed, I went to my first conference complete with suit and tie, ready to discover a new world. And ready to learn my first lesson: “Don’t wear a suit and tie when you attend a technical conference.” Period. Luckily, these were the days of Miami Vice and I could take off my shirt and tie and dress like Sonny Crockett for the rest of the day. So, after fixing my clothing, I was ready to go.

TechEd might seem overwhelming at first. You are there with a few thousand other IT people, all of whom are there to learn and have a great time. Learning at TechEd is fun because TechEd is about every Microsoft product currently on the market. It is the one-stop shop for investing in your IT skills. For an IT pro like me, learning about much cutting edge technology is professionally one of the best things that can happen in a year. Looking at what is coming with this year’s conference, for example, I can only say, “Wow, you don’t want to miss this year’s TechEd.”

Most TechEd conferences start with a pre-conference event. This is where you can use a full day to deep-dive into one subject. The extra day comes at an extra cost, but, if you want to get the maximum out of your stay at TechEd, you should consider attending a pre-conference event. With the added content, you will have more time to discover other new things during the rest of the week.

The real conference really takes off with the keynote. Get ready to see all attendees of the conference in one big room. Most keynotes are a high level overview of the products and technology Microsoft is now working on with lots of demos and numbers. The keynotes are presented by high level people from Microsoft and, in some rare occasions, you will see someone wearing a suit and a tie. The keynote sometimes contains announcements on the availability of new technology. It wouldn’t surprise me if Microsoft is preparing something great and new for us this year.

The keynote sessions are followed by the foundational sessions that provide more technical depth and form a bridge to the breakout sessions. Make sure you prepare for the breakout sessions at home before you come over to the venue! Every time slot contains multiple sessions with interesting topics for everyone. Some sessions are repeated. That’s why it is a good idea to plan ahead. Sometimes you can skip a session during its first occurrence knowing you can attend it later.

Choosing the best session can be hard. Some speakers are very entertaining. Others know a lot of detail and can provide helpful advice for that little issue you have been fighting with for the past few months. If you know which session you want to attend, be there on time. Once in a while, you’ll find that single hyper-popular session that fills the room. And if you’re late, you’re late and may miss out. Luckily, most sessions are recorded and you can have a look at it later or after the conference. If you have no alternative planned for that time slot, look for something else. There is a lot to do besides the breakout sessions.

First of all, there are the more informal “birds of a feather” sessions presented by community leaders. I personally love the hands-on lab area where you can sit down and explore a new technology at your own pace. In case you get in trouble, there always are some Microsoft Certified Trainers around to help you and provide assistance when you get stuck. And, if you just need answers or like to meet the industry experts, you can visit the Ask-the-Experts area and find experts on about every subject you can think of. This area contains an interesting mixture of people from Microsoft, speakers, MVPs and other experts. This area is also very popular if you are hunting for swag. If your timing is right, you can walk away with all sorts of branded stuff like bags, t-shirts, and other items to fill your suitcase before the trip home.

Still the best thing I always take home from every TechEd is a head full of ideas and inspiration from being there. For one week, TechEd is the center of the universe for every IT pro who attends, and even some that don’t. This year, it will have been 15 years since I first attended TechEd. During this time, I have grown from an attendee wearing a suit to a conference speaker for the third year in a row. I hope you will enjoy this year’s conference as much as I will and I hope to see some of you at my session.

Posted in Events, Uncategorized | 1 Comment

BitLocker Recovery tab missing from the Computer properties after installing the BitLocker Password Recovery Viewer


You’re domain is running on pre-Windows Server 2008 R2 domain controllers. After enabling the BitLocker Password Recovery Viewer feature on Windows 7 or Windows Server 2008 R2, the Recovery Password tab may not show in the computer properties dialog in Active Directory Users and Computers (DSA.MSC).



When the Active Directory domain does not have any Windows Server 2008 R2 domain controllers, Active Directory is missing the BitLocker Recovery Information display specifiers. The BitLocker Recovery Information Display specifiers must be populated in the domain in order to show the BitLocker Recovery tab.


You can manually populate the display specifiers by registering BdeAducExt.dll. You have to register the DLL logged on as a member of the Enterprise Administrators on a system running Windows Server 2008 R2 or Windows 7 with the BitLocker Password Recovery Viewer feature enabled. Run the following command to populate the display specifiers: “regsvr32.exe BdeAducExt.dll”.

The display specifiers for BitLocker Recovery Information are automatically populated when a Windows Server 2008 R2 domain controller is installed in the domain.

More Information

BitLocker Recovery Password Viewer for Active Directory Users and Computers tool

Posted in BitLocker, Windows 7, Windows Server 2008 R2 | 2 Comments