ADFS in Windows Server 2016 Technical Preview 3 – First Insights on the ‘Application Groups’ functionality!!!

August 21, 2015 Leave a comment

Hello Everyone,

I’m inviting you to have a look right-now at the blog post of Vittorio Bertocci who has illustrated the new functionality coming with ADFS on Windows Server 2016 TP3 which is the ‘Application Groups’ – The support for modern authentication looks really promising ūüôā

The blog post is avalaible here:




What’s new in ADFS vNext in Windows Server 2016 Technical Preview 2

May 13, 2015 2 comments

Hello Everyone!

What a nice past week, full of great news at the Ignite conference in Chicago ūüôā
As you know, Microsoft took the opportunity to release the technical preview 2 of Windows Server 2016 few days ago and the first thing I did was to quickly install my favorite component, ADFS!

So, this post is coming after my first review few month ago based on technical preview 1 which is available here:

There are a lot of changes coming again with this new release!

First let’s recap what has been announced at the conference:

1) Authenticate users stored in non AD directories

* Enable login to Azure AD/Office 365 or other ADFS apps for users stored in LDAP directories

* Consolidate app authentication and authorization across different account stores

* Supports any LDAP v3 directory

* Support across sync and sign-in coming to Azure AD Connect at a later date

* Each LDAP directory is modeled as a ‚ÄėLocal‚Äô Claims Provider Trust (just like Active Directory)

* An untrusted AD forest can be modeled as an LDAP directory.

Some good information can be found here on that topic:

2) Upgrade path from 2012 R2 to 2016

* Upgrading to 2016 is now quite easy, just add new 2016 node in the actual 2012 R2 ADFS farm and replace step-by-step all your 2012 R2 server

* Roll back is supported

3) Better Conditional Access Control

* Enable Access only from devices that are managed and/or compliant =>New Device Trust Level (Authenticated/Managed/Compliant) via Intune

* Support for restricting access to corporate ‚Äėjoined‚Äô PC‚Äôs

* Revocation of Access & SSO when device attributes change

* Device authentication can now be primary authentication method

4) Access Control Policies

* Templates to simplify applying similar policies across multiple application

* Parameterized templates to support assigning different values for access control (e.g. Security Group)

* Simpler UI with additional support for many new conditions

5) Delegated Service Management

* Separation between server administrators and ADFS service administrators

* Standard security groups can be assigned as admins

6) Audits Enhancements

* Schematized Audits (Schematized for easy parsing)

* Fewer but comprehensive audits (Reduces # of audits for logon from ~80 to <3)

7) Better Support for Oauth

* Additional Profile Available

* OBO Support

* ID Token Support

* Confidential Client Auth

* Secure Device Auth

8) OpenID Connect Support

* Enable apps (e.g. MVC) with web front end as well as WebAPI back end

* Returns authorization code to web application which is exchanged for tokens & refresh tokens

* Support for OpenIDConnect Discovery

* Scopes (Defines a resource group within an application)

* Permissions¬†(Assignment of scopes for ‚Äėclient‚Äô to access ‚Äėservice‚Äô application)

9) App Branding with per-RP Customization

* Modify Sign-in page descriptions to have specific language/links for a RP

* Modify images (e.g. illustration & logo) to align with RP specific branding

* Modify JavaScript via onload.js to control UI elements that are RP specific

* Easier management using custom web theme to have a similar look & feel across a set of RP’s

10) AD FS: Certificate Proxy Authentication

* Enable seamless access to Azure Remote App without having to resign into the VM session

==> Ignite Session on this topic

If you want to have a look at the Ignite session given by Samuel Devasahayam from the ADFS product team, it’s available here:

Now let’s dive a bit in this new version ūüôā

Like for the TP1 review, it’s not a¬†definitive view on the product (technical preview) neither a complete one, it’s¬†only my personal view on the changes ūüôā

1) GUI Changes
Let’s have a look at the direct changes in the GUI. As you can see¬†there¬†are some reorganization and some¬†functionalities added.

– The “service”¬†part is now containing a lot more of¬†options compared to before (only Certificates, Endpoints and Claim Descriptions)

– New “Access Control Policies” and “Clients” configuration¬†parts¬†have been added

–¬†“Relying Party Trusts” and “Claims Provider Trusts” are not anymore under the “Trust Relationship” part but directly under the root.
Screenshot - 5_7_2015 , 9_12_32 AM

2) Delegation of Administration

For all of you who were worried about the fact that as soon as you are administrator of the server, you’re an ADFS administrator, Microsoft has now fixed that problem by allowing you to define “delegates” to administer the component!

By default, the local administrator still have the rights to manage the component but you can now easily change that and define your own management group for example.

Screenshot - 5_7_2015 , 9_14_57 AM

3) Authentication Methods

The “Authentication Methods” part is now what was the “Authentication Policies” in ADFS 3.0 where you can define the primary and secondary authentication methods.

Screenshot - 5_7_2015 , 11_21_01 AM

The main change in that part is now that you’re able to select device authentication or Azure MFA as a primary authentication method.

Device authentication is also not anymore a “global setting” that you enable or not.

Screenshot - 5_7_2015 , 11_27_30 AM_2

On the “Multi-Factor” tab, you’ll see now that it’s only basic settings where you select the method and that’s all. There are not anymore any conditional trigger as this part is now controlled by a dedicated module that we’ll see afterwards.

Screenshot - 5_7_2015 , 11_36_25 AM

4) Certificate Authority

ADFS can now act as a certificate authority to issue certificates for user logon and VPN access. The trigger for this, explained by the product team was the user experience with Azure Remote App where users are not experiencing SSO when reaching those applications being already authenticated in Azure and having to re-authenticate a second time.

By default the functionality is disabled


If you enable it, you can decide whether you want to use your ADFS server acting as a CA or having your existing PKI infrastructure being used for this purpose.


If you use your existing CA, the wizard will ask you the certificate templates to use for the different purposes


Screenshot - 5_8_2015 , 10_28_12 AM

5) Claim Descriptions

The following new claim types are available in this preview 2 release:
Description: IP address of the user
Description: The account store that was used to authenticate the user.
Description: The type of claim used to represent the primary identity of the user.
Description: Identifier for the OAuth Client
Description: Type of the OAuth Client
Description: Compliance status of device reported by the management service
Description: Last time the device is used for accessing the relying party
Description: Device is known to the enterprise, either by virtue of being joined to a domain or workplace joined
Description: This claim indicates that AD FS has issued a Persistent SSO token.
Description: Scope of access to a secured resource
Description: The windows group SID of the device
Description: The windows deny-only group SID of the device
Description: Trust type of the device to indicate if it is a Workplace Join, Domain Join, or another type of join.

6) Device Registration

As already part of the Technical Preview 1 (See details and prerequisites/!\ Certificate /!\ in my posts here: and here: you can enable DRS via the GUI now.

You click on ‘Configure Device Registration’ to prepare AD for DRS

Screenshot - 5_8_2015 , 10_57_37 AM

Once done, you click on ‘Enable Device Authentication’ to finish the process

Screenshot - 5_12_2015 , 9_16_05 AM

And that’s all, you’re ready with DRS!

Screenshot - 5_12_2015 , 9_16_51 AM

7)  Scope Descriptions

As part of the Oauth protocol, you have now the possibility to define “scopes”. Scopes defines permissions to an application on what is being allowed for that application to request. There are some scopes configured by default. For example, you can see that there is the “logon_cert” scope¬†which can be used together with the new CA functionality to distribute authentication certificate to clients.

As soon as those scopes are defined, you can use them in relying parties (we’ll see that afterwards)

Screenshot - 5_8_2015 , 3_51_31 PM

8) Web Application Proxy

There is now a dedicated¬†Web Application Proxy ¬†part. As soon as you have installed a first WAP, you’ll have the ability to Enable/Disable the functionality (generally, for all the proxy servers) and also the possibility to edit the Access Control Policy for the Proxy.


9) Access Control Policies

As we have seen the first trace of this in the technical preview 1, Access Control Policies allows you to:

– Define “Recurrent” policy templates¬†that you are able to easily assign to your relying parties without having to reinvent the wheel each time you have a new application to onboard. So you define it one time and assign it multiple time depending on your usage.

– Define “Parameterized” policy template that you’re also able to assign to application. This allow you to be prompt for the wanted criteria when applying the policy template to the application.

– This in-turn allow you to have an easy way to manage Access Control without diving into Claims Rules Language

What is also interresting is the new trust level for devices, you are now able to select 3 different trust levels (Authenticated/Managed/Compliant):

Screenshot - 5_12_2015 , 1_18_00 PM

I’m inviting you to have a look at the following link where Access Control Policies is described in details:

10) Clients

Before going further on the Relying Party Trusts, we’ll have a look at the new ‘Clients’ part. In this section, you’re able to add Oauth clients. You can see there are already some defined by default. Example, again, the Microsoft Windows VPN client which is working with the scope and the new CA functionality you’ve seen before.

Screenshot - 5_12_2015 , 2_58_24 PM

Having a look at the properties, you have the Client ID and the Redirect URI which are part of the Oauth protocol.

Screenshot - 5_12_2015 , 2_59_38 PM

You can decide to disable one client whenever you want

Screenshot - 5_12_2015 , 3_04_48 PM

When you want to add a new Oauth client, you have the ability to set its type as ‘Public’ or ‘Confidential’

The difference will be at the authentication level. Indeed, Being ‘Confidential’ the Oauth client will need to authenticate which is not the case¬†if the¬†application¬†type is¬†‘Public’.


Screenshot - 5_12_2015 , 3_04_15 PM


Screenshot - 5_12_2015 , 3_03_53 PM

Let’s have a look at the different possibilities for the authentication:

Screenshot - 5_12_2015 , 3_11_18 PM

11) Relying Party Trusts

Let’s have a look at the Relying Party Trusts Part now. I’ll highlight only the pieces of configuration which are different compared to the actual version.

When adding a new relying party, you have now the choice to select whether it’s a claim aware or nn claims aware application right-after launching the wizard. This was a separate wizard in the actual version.

Screenshot - 5_12_2015 , 4_06_11 PM

You can now enable support for OAuth2 protocol

Screenshot - 5_12_2015 , 4_06_46 PM

This will give you the ability to specify a OAuth Client and the scope. By default here, you can see that all clients are autorized to use OpenID Connect

Screenshot - 5_12_2015 , 4_07_11 PM

When adding a client, you can select one of the different clients available and the permission scope. You can add multiple scope for the same client.

Screenshot - 5_12_2015 , 4_08_10 PM

Now, you’re able to easily assign one of the access control Policy you’ve created before.

Screenshot - 5_12_2015 , 4_08_38 PM

Let’s select a parameterized one, you can see that the paramter (in blue in the screenshot) needs to be filled with a group name in this example.

If you don’t fill this value, this will generate an error when you’ll hit the ‘Next>’ button.

Screenshot - 5_12_2015 , 4_09_14 PM

Here is the relying party created:

Screenshot - 5_12_2015 , 4_13_03 PM

12) Claims Provider Trust

This part seems not to bring additional features compared to the actual version. Anyway, if you define additional LDAPv3 directories, you’ll get them listed here.

13) Endpoints

As already seen in TP1, you can see that DRS is now having its own endpoint.

There are also new endpoints for OpenID connect and for the CA CRL.

You can also see that there is a new endpoint added for Webfinger:

Screenshot - 5_13_2015 , 11_33_11 AM

14) Powershell

I’ll not review all the changes on the PS side for the moment bu we can already have a look at some new features here:

You’re now able to define custom branding (description text, logo, illustration,…) per relying party via new parameters available in the powershell command: Set-ADFSRelyingPartyWebTheme


Change Description Text

Screenshot - 5_12_2015 , 8_55_39 PM

Screenshot - 5_12_2015 , 8_55_14 PM

The output of the Get-ADFSProperty cmdlet is showing also some new parameters available.

As already seen in the technical preview 1, you can now enable easily the relay state functionality without having to change the configuration manually on each of your internal ADFS server.

Be aware that IdpInitaitedSignonPage is not enabled by default so you’ll have to enable it manually.

You can find also the administration delegation present here via ‘DelegateServiceAdministration’, ‘AllowSystemServiceAdministration’¬† and ‘AllowLocalAdminsServiceAdministration’

Screenshot - 5_12_2015 , 9_20_57 PM

That’s all for today and this concludes my second review, we’ll have again the opportunity to discover a lot more in the coming weeks! Hope you’ll find this interesting ūüôā

Have a nice day!



ADFS 3.0: OneDrive For Business and Conditional Access Control

March 20, 2015 2 comments

Hello Everyone,
Today, we’ll focus on the possibilities available in term of conditional access control in OD4B.
Before starting, there are a lot of good reasons to implement conditional access control but the requirements to have this implemented should be first well identified, this should match the company needs in term of security governance and not come from the technical side.

So, let’s start by enumerating the potential requirements that you could be asked to answer:
1) Is the user located inside or outside the company network?
2) Is the user is using a trusted/managed device?
3) Is the user using a rich client, a mobile app or a browser?
4) Is the user using an app, which one?

In term of response to those question, what could you do?
1) Enforce MFA?
2) Block the access?

Those points are classical ones that you can face, we’ll now take them separately and see what are the possibilities in an ADFS/O365 claims world ūüôā

1) Is the user located inside or outside the company network?
First and the easiest one, if the user is outside the company network, you’ll receive the following claim filled with the server name of your ADFS proxy server:

The approach is quite straight forward and you can base your authorization decisions on that claim, this is valid for all usage: Browser/OD4B Windows Sync Client/OD4B Mobile App

2) Is the user is using a trusted/managed device?
Good question isn’t it? The only way for you to know that is to leverage workplace join, as soon as you’ll have workplace joined a device, you’ll also receive claims about that device. The claims you can get at that time are the following ones:

I’ll not go into details of all those claims as it’s not the aim here but you already understand that as soon as you’re able to receive device related claims, you have a registered device which is knocking on the door.

On the other hand, you’ll start to encounter problem here, why? Simply due to the fact that not all the client types are workplace join aware… Using a browser, you’ll well receive the device claims, using the OD4B sync client for Windows or the mobile app, you’ll not receive anything! And then your authorization rule will simply fails.

What Can I do then?
For the OD4B Sync client for Windows, simply nothing for the time being, you cannot leverage workplace join, end of the story.
For the OD4B mobile app, there is a pretty new cool stuff which is available since 2 weeks ago: Intune offers you the ability to do Conditional Access Control based on the fact that the device is registered (note: registered in Azure AD this time) – You can find some useful information there on how to proceed:
The following mobile application are compliant with this system:

Microsoft Office Mobile (Android)
Microsoft OneDrive (Android and iOS)

You can leverage Worplace join to base your authorization rules on the fact that the user is using a registered device but keep in mind that it’s only valid for browser, for the OD4B mobile app, you’ll need to leverage Intune and device registration in Azure AD to accomplish this and finally, no option for the OD4B Sync client for Windows

3) Is the user using a rich client, a mobile app or a browser?

There are 2 kind of federation approaches, you have passive ones (typically browser-based) and active ones (typically application)
The nice thing here is that you can also differentiate this via claims, basically, an active federation will not use the same ADFS endpoint as a passive federation one.
So let’s have a look at that, the claim you need to check here is the following one:
What can you trap in our 3 main cases:
Browser: /adfs/ls/
OD4B Mobile App: /adfs/ls/
OD4B Sync Client for Windows:/adfs/services/trust/2005/usernamemixed

You can already wonder what is the “issue” in this case, with that claim only, you’ll not be able to differentiate the mobile app compared to the browser

Checking whether it’s an active/passive federation by having a look at the “x-ms-endpoint-absoluth-path” claim can already give you interesting insights about the context of the request but could not give you alone a clear picture

4) Is the user using an app, which one?
The aim here would be to identify the application used. Bad news, there is no easy way to do that for the OD4B client applications. There is an interesting claim that you would want to check but unfortunately, this one is not filled with any values:

There is no easy way to identify the OD4B applications compared to other ones, you cannot respond to this requirement

Now, after having seen what you can gather for those 4 points, let’s consider the actions and particularly triggering MFA and the impact on the 3 different cases:
– Browser based : Supported
– OD4B Mobile Application: Supported
– OD4B Sync Client for Windows: Not Supported

You can enforce MFA depending on the claims we’ve seen below but keep in mind that not all the client types supports MFA. The OD4B Sync Client for Windows is not supporting MFA and will simply reject the authentication if the user is configured to use MFA

As a summary, you can see that there are already a lot of options in term of conditional access control but as of now, you’ll not be able to put in place a homogenous behavior with all the client types used by OD4B.
Please note also that the mobile application side has only be tested on iOS in this blog post, feel free to send me your feedback for Android and Windows Phone!

Here is a little summary of what we’ve seen:

Here are some useful links to interesting documentation:
Limiting Access to Office 365 Services Based on the Location of the Client:

Conditional Access for SharePoint Online with Microsoft Intune:

Control access to Exchange and Office 365 with conditional access in Microsoft Intune:

Conditional Access Device Policies for Office 365 services


Office 365/WAAD: Use Powershell to provision/deprovision users based on an on-prem AD group

January 21, 2015 Leave a comment

Hello Everyone,

For some reasons (in short, not using any directory synchronization tool), I had to write a little script to provision/deprovision users in O365/WAAD based on an on-prem AD group.

The script is using the on-prem AD mail attribute to set-up the user’s unique Identifier (UPN) in O365/WAAD. (it can be changed to use the on-prem UPN if required)

It also fills the ‘immutableID’ attribute so that means the script can be used along with having the federation enabled for the on-prem domain in O365/WAAD.
Along with this, the DisplayName, GivenName and SurName and also provisioned from the on-prem AD (more can be added if required)
The script also output the activity in a log file and perform a count on the amount of users present in 0365/WAAD and in the on-prem AD group.

The scope here is only provisioning/deprovisioning but you can also imagine performing other actions too like assigning O365 licences,…
It does not perform updates on attributes changed in on-prem AD but if you start to think about that, better think about installing a directory synchronization tool ūüėČ


Sample Script:

(Requires Active Directory and Windows Azure Active Directory Modules to be installed on the machine the script is running)

#Log File Location
$logfile = "Path_To_Your_Log_File"

#Modules Import
Import-Module ActiveDirectory
Import-Module MSOnline

$credentials = Your_Credentials
$ErrorActionPreference = "Stop"

#Connect to WAAD
Connect-MSOLService -Credential $credentials
(Get-Date).ToString()+"|Connection to WAAD|OK" >>$logfile}
$ErrorMessage = $_.Exception.Message
(Get-Date).ToString()+"|Connection to WAAD|NOK|ERROR:"+$ErrorMessage >>$logfile

#Getting group member from AD
$usersList = Get-ADGroupMember Your_Group_Name
(Get-Date).ToString()+"|Getting group member from AD|OK|Number of members found: " + $usersList.count >>$logfile}
$ErrorMessage = $_.Exception.Message
(Get-Date).ToString()+"|Getting group member from AD|NOK|ERROR:"+$ErrorMessage >>$logfile

#Getting WAAD tenant users
$usersInCloudList = Get-MSOLUser | Where-Object {$_.UserPrincipalname -like "*@your_domain"}
(Get-Date).ToString()+"|Getting WAAD tenant users|OK|Number users found: " + $usersInCloudList.count >>$logfile}
$ErrorMessage = $_.Exception.Message
(Get-Date).ToString()+"|Getting WAAD tenant users|NOK|ERROR:"+$ErrorMessage >>$logfile

Foreach ($user in $usersList){
$userDetails = Get-ADUser $user.sAMAccountName -Property mail,DisplayName
$present =$false
Foreach($userInCloud in $usersInCloudList){
$match = $userInCloud.UserPrincipalName -eq $userDetails.mail
if ($match){
If (!$present){
$immutableID = [System.Convert]::ToBase64String(($userDetails.objectguid).toByteArray())
New-MSOLUser -DisplayName $userDetails.DisplayName -FirstName $userDetails.GivenName -LastName $userDetails.surname -UserPrincipalName $userDetails.mail -ImmutableId $immutableID
(Get-Date).ToString()+"|User Provisioning|OK|Provisioned User: " + $userDetails.mail >>$logfile}
$ErrorMessage = $_.Exception.Message
(Get-Date).ToString()+"|User Provisioning|NOK|ERROR:"+$ErrorMessage >>$logfile


Foreach ($userInCloud in $usersInCloudList){
$present =$false
Foreach ($user in $usersList){
$userDetails = Get-ADUser $user.sAMAccountName -Property mail
$match = $userInCloud.UserPrincipalName -eq $userDetails.mail
if ($match){
If ((!$present){
Remove-MSOLUser -UserPrincipalName $userInCloud.UserPrincipalName -force
(Get-Date).ToString()+"|User Deprovisioning|OK|Deprovisioned User: " + $userInCloud.UserPrincipalName >>$logfile}
$ErrorMessage = $_.Exception.Message
(Get-Date).ToString()+"|User Deprovisioning|NOK|ERROR:"+$ErrorMessage >>$logfile

ADFS 3.0: KB3003381 – Fixing more than the security issue

December 23, 2014 Leave a comment

Hello Everyone,

Last month, Microsoft released a security bulletin for ADFS which is impacting ADFS 2.0, 2.1 and 3.0.

The security bulletin details can be found here:

And the details of the security issue is as following:

Microsoft Active Directory Federation Services (AD FS) 2.0, 2.1, and 3.0, when a configured SAML Relying Party lacks a sign-out endpoint, does not properly process logoff actions, which makes it easier for remote attackers to obtain access by leveraging an unattended workstation, aka “Active Directory Federation Services Information Disclosure Vulnerability.”

So, if you don’t have already applied this KB, it clearly makes sense to do it.

The reason why I’m also writing about it is that I was struggling with another issue on customer side where there was an issue with a relying party, using SP-Initiated login and accessed using another claims provider. It was working well with the local claims provider (AD).

The error encountered was the following one:


If some of you worked with ADFS 2.0,2.1,  this was already an issue which appeared after applying a specific Security Update: ( After some weeks, Microsoft released a hotfix to solve the issues met with that security update ( so the problem was solved after the hotfix application.

In ADFS 3.0, the problem has been solved after applying the security update release last month.

I hope¬†it’ll help some of you trying to figure out how to solve this!





Vulnerability in Kerberos – MS14-068 – Critical

November 19, 2014 Leave a comment

Hi Everyone,

Yesterday, Microsoft published  a Security Bulletin for a vulnerability discovered in the Windows Kerberos KDC.

Domain controllers which are running KDC are vulnerable to this security breach and need to be patched in priority!

Vulnerability Details

CVE-2014-6324 allows remote elevation of privilege in domains running Windows domain controllers. An attacker with the credentials of any domain user can elevate their privileges to that of any other account on the domain (including domain administrator accounts).

The exploit found in-the-wild targeted a vulnerable code path in domain controllers running on Windows Server 2008R2 and below. Microsoft has determined that domain controllers running 2012 and above are vulnerable to a related attack, but it would be significantly more difficult to exploit. Non-domain controllers running all versions of Windows are receiving a ‚Äúdefense in depth‚ÄĚ update but are not vulnerable to this issue.

Security Bulletin:

Security Update:

Additional information can be found here:




What’s new in ADFS vNext on Windows Server 10 Technical Preview?

October 14, 2014 1 comment

Hello Everyone,

Today, we’ll have a look at the changes present in the ADFS¬†vNext (3.1?) coming along with Windows Server 10¬†technical preview.

Please note that this is clearly not the definitive view on the product¬†(technical preview) ¬†neither a complete one (it’s only my personal view on changes present in the release)

Let’s start with the officially announced new feature and not the smallest one:

1) Authenticate users stored in non AD directories

Yes, you’ll be able now to use other LDAP directories to authenticate users


“For the Windows Server Technical Preview, the AD FS server role includes the same functionality and feature set that is available in Windows Server 2012 and Windows Server 2012 R2. It also includes new features that enable you to configure AD FS to authenticate users stored in non-AD directories, such as X.500 compliant Lightweight Directory Access Protocol (LDAP) directories and SQL databases. In many organizations, identity management solutions consist of a combination of Active Directory, AD LDS and third-party LDAP directories, as well as SQL databases. With the AD FS support of the non-AD identity stores, you can benefit from the entire enterprise-ready AD FS feature set regardless of where your user identities are stored.

Some interesting info can be found here for the configuration part:

2) New Claim Types

The following new claim types are available in this preview release: The account store that was used to authenticate the user. The type of claim used to represent the primary identity of the user. Identifier for the OAuth Client Type of the OAuth Client Status of device determined by a management service Last time the device is used for accessing the relying party Device is known to the enterprise, either by virtue of being joined to a domain or workplace joined This claim indicates that AD FS has issued a Persistent SSO token. Scope of access to a secured resource

3) Changes in DRS

As you can see now, there is a new¬†‘Device Registration’ part located under ‘Services’.

You’re now able to configure Device Registration directly in the GUI instead of using Powershell command. (Remember, certificate requirements which don’t change whether you’re able to do this via the GUI now)

Screenshot - 10_7_2014 , 4_45_56 PM

As soon as you have clicked on ‘Configure Device Registration’, you have now the Status switching to green:

Screenshot - 10_7_2014 , 4_47_13 PM

Previously, DRS was part of the relying party trusts list. This is now a specific component.

If you click on ‘Edit Claim Rules…’ you’ll find back the ‘Issuance Authorization Rules’ options.

Screenshot - 10_8_2014 , 9_49_34 AM

If you click on ‘Edit Custom Multi-Factor Authentication…’ you’ll find back the authentication policy for DRS:

Screenshot - 10_8_2014 , 9_50_04 AM

If you click on ‘Options’ you’ll find 2 options which were also only available on Powershell before.

Screenshot - 10_8_2014 , 9_50_38 AM

The ‘Issuance Transform Rules’ can be retrieved and set via Powershell:

Screenshot - 10_8_2014 , 10_05_28 AM

Also, DRS is now having its own endpoint that you can configure as the others to be available internally/externally or both:

Screenshot - 10_8_2014 , 9_39_42 AM

4) New Feature – Policy Templates

Here is also a nice new feature that is available in the technical preview of ADFS. You’re now able to create a policy template that you can assign to specific relying parties.

Imagine, and this is often the case where you have several time the same policy applied to relying parties. Instead of reconfigure each time the same claim rule, you’re now able to build template which can be fixed or dynamic.

Let’s have a look at that!

As you can see, there is now a new ‘Policy Templates’ part in the console:

Screenshot - 10_13_2014 , 4_30_11 PM-2

Let’s try to add a Policy Template by selecting ‘Add Policy Template’:

Screenshot - 10_13_2014 , 4_30_52 PM

We give a name and a description to our policy:

Screenshot - 10_13_2014 , 4_31_36 PM

Going to ‘Policy Rules’ we’ll now define what’s in our policy by clicking on ‘Add’

Screenshot - 10_13_2014 , 4_32_06 PM

We are now getting the rule editor, the look and feel¬†is a bit of already seen before in a popular mail client, isn’t it ūüėČ

So, as you can see, you can define the conditions and the exceptions:

Screenshot - 10_13_2014 , 4_32_33 PM

Let’s take the first condition: ‘from <specific> location’ and click on ‘<specific>’ – We’re now getting 2 options:

Let’s configure “hardly” the location in this case and go for the second options in the next rule.

So let’s say in this case that this rule if for users being on the Extranet

Screenshot - 10_13_2014 , 4_34_13 PM

Now we’ll configure group membership by using the second rule. Instead of mentioning a specific AD group, we’ll now select the second option and give a specific name for that condition.

What is the aim of this? For all rules where this is configured, you’ll be prompt each time you assign the policy template for this specific information

Screenshot - 10_13_2014 , 4_37_14 PM

We’re ending with this, let’s click ‘Ok’

Screenshot - 10_13_2014 , 4_37_58 PM

Let’s click ‘Ok’ again.

Screenshot - 10_13_2014 , 4_38_38 PM

We have now our policy template created:

Screenshot - 10_14_2014 , 3_02_18 PM

Unfortunately,¬†the GUI and Powershell¬†in this release preview don’t¬†allow us to assign the policy template¬†to a relying party

Even though the Powershell commands include all the needed to assign a policy template, it’ seems not working at this stage.

Here is the result of the newly PS cmdlet: ‘Get-ADFSPolicyTemplate’

Screenshot - 10_14_2014 , 3_02_55 PM

If you have a look also at a relying party there is now a ‘PolicyTemplateName’ and ‘PolicyTemplateParameters’ available

Screenshot - 10_14_2014 , 3_03_39 PM-2

5) New Powershell possibilities

While there is no in depth details about all the possibilities potentially added to the release, simply executing a ‘Get-ADFSProperties’ can show some new features added there too.

Have a look at the screenshot below, did you see the new parameters?¬†The ‘RelayStateForIdpInitiatedSignonEnabled’ is now a parameter in Powershell so, no need anymore to edit the ‚ÄėMicrosoft.IdentityServer.Servicehost.exe.config‚Äô file¬†on each of our internal ADFS servers.

It seems also possible to enable or not ‘IdpInitiatedSignonPage’ directly as a parameter too!

Screenshot - 10_14_2014 , 3_43_12 PM-2

Here we go, this is closing today my first review on the next version of ADFS, I surely missed some points but we’ll have time to discover it more in the next coming weeks. I hope there will be some other new functionalities added too in the final version like the possibility to assign specific MFA¬†methods to specific relying parties, that would be awesome ūüôā