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

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

From http://technet.microsoft.com/en-us/library/hh831502.aspx:

“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:

http://technet.microsoft.com/en-us/library/dn823754.aspx

2) New Claim Types

The following new claim types are available in this preview release:

http://schemas.microsoft.com/ws/2014/01/identity/claims/accountstore	The account store that was used to authenticate the user.
http://schemas.microsoft.com/ws/2014/01/identity/claims/anchorclaimtype	The type of claim used to represent the primary identity of the user.
http://schemas.microsoft.com/2014/01/clientcontext/claims/appid	Identifier for the OAuth Client
http://schemas.microsoft.com/2014/01/clientcontext/claims/apptype	Type of the OAuth Client
http://schemas.microsoft.com/2014/02/devicecontext/claims/mdmstatus	Status of device determined by a management service
http://schemas.microsoft.com/2014/02/deviceusagetime	Last time the device is used for accessing the relying party
http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown	Device is known to the enterprise, either by virtue of being joined to a domain or workplace joined
http://schemas.microsoft.com/2014/03/psso	This claim indicates that AD FS has issued a Persistent SSO token.
http://schemas.microsoft.com/identity/claims/scope	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)

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

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.

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

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

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

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

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:

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

We give a name and a description to our policy:

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

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:

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

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

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

Let’s click ‘Ok’ again.

We have now our policy template created:

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’

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

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!

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 🙂

Cheers!

Mitch