Category Archives: AD FS 4.0

Office 365 and MFA in AD FS 2016 (TP4)

March 11, 20162FA, AD FS 2016, AD FS 4.0, MFA, Multi-Factor Authentication, Office 365, Powershell, Relying Party, Windows Server 2016AD FS;ADFS;ADFS 4.0;ADFS 2016;MFA;2FA;O365;Multi-Factor Authentication;Office 365mylo

I recently added my O365 tenant, for testing purposes, to a AD FS in Windows Server 2016 TP4 and noticed something rather unusual. Via the AD FS Management snap-in it was not possible to assign an access-control policy in AD FS to my Office365 Relying Party (RP). Looking at my RP Trusts, I could see the Access Control Policy section was blank.

Right-clicking over a Relying Party in AD FS 2016 TP4 reveals an additional menu option for editing Access Control Policies:

Doing this on the O365 RP, only the Issuance Authorization Rules pipeline is visible, nothing else.

If we compare that with a normal RP.

Right-clicking and selecting access control policy, the administrator is presented with the option of choosing an appropriate policy for that RP: in our case, the desire to use multi-factor authentication.

Why this does not appear on the O365 pipeline, I can only speculate. It might be partially explained by the fact that creating the Office 365 Identity Platform relying party is normally performed via PowerShell and Microsoft wanted to keep this procedure ubiquitous across all versions of AD FS since v2.0. For example, the following command will create the Office 365 Identity Platform RP should it not exist.

Update-MsolFederatedDomain -SupportMultipleDomain -DomainName mydomain.com

Alternatively, following the principle of Occam’s Razor, it could be Microsoft have simply not got round to updating their code to detect AD FS 2016 during O365 Relying Party creation Smile Either way, from previous experiences of using MFA under Office 365 via AD FS 2012 R2, we do know it IS possible to use MFA with O365, so getting it working with AD FS 2016 just requires a little more effort. ..

Looking at our O365 RP in PowerShell (Get-ADFSRelyingPartyTrust) , we see no access policies configured. Under the O365 Relying Party it’s blank.

Compare this to an RP that does have an access control policy configured:

Since the UI doesn’t allow enabling MFA in an access policy for our O365 RP, playing around with PowerShell reveals that it is possible using the Set-ADFSRelyingPartyTrust cmdlet .

Set-AdfsRelyingPartyTrust -AccessControlPolicyName ‘Permit everyone and require MFA’ -targetidentifier https://login.microsoftonline.com/extSTS.srf

Check the O365 relying party (Get-ADFSRelyingPartyTrust) that an Access Control Policy has been added.

In the GUI, we then see the applied policy (Permit Everyone and require MFA) appearing.

Connect to Office 365 and we’re redirected to our AD FS instance. Enter the AD credentials for the user and then MFA kicks in:

As ever, play and test at your own peril Smile

AD FS Extranet Lockout: a case of the unintended pun

March 3, 2016AD FS 3.0, AD FS 4.0, AD FS R2, Extranet Lockout, Web Application Proxyaccount, AD FS 2012 R2, AD FS 3.0, AD FS 4.0, Brute Force, DoS, Extranet Lockout, FSMO, lockout, Password, PDC Emulator, Web Application Proxymylo

Just a very quick post, to describe a problem recently experienced at a customer.

Extranet Lockout, available in AD FS 2012 R2 and beyond, is a great security function that helps shield the AD password from remote attack. The normal Active Directory conventions for protecting an AD account include:

Password complexity
Account Lockout policies
Password Length

In a remote access scenario we need to consider the impact of users incorrectly entering their credentials versus scenarios where:

an attempt to maliciously lockout an account is attempted
a brute force attack is attempted on said account

Enter Extranet Lockout. By implementing this as a policy on the AD FS server, we can stipulate that after x number of invalid logon attempts via the Web Application Proxy, not to forward further requests to Active Directory, thereby protecting that account from lockout. For example, if our AD account lockout policy stipulates lockout at 10 logon attempts, we set our AD FS extranet policy at a lower value, say 5.

All good. There is a caveat though. Extranet Lockout capability does introduce a direct dependency between ADFS and the PDC Emulator Active Directory FSMO role. If you do plan on using this feature it’s worth considering this. Otherwise, extranet lockout may occur for very different reasons Smile Connectivity between the AD FS farm and the Domain Controller hosting this role is assumed. Should the situation arise where network connectivity between the two is broken, then users will be unable to logon at AD FS. This applies even where local domain controllers are co-located next to AD FS. It turns out that the PDC Emulator must be contacted on each logon attempt. This sort of issue can arise in an enterprise (e.g. global) setup, where AD is distributed, living in different data centers; the AD FS services in one and FSMO roles in another.

Should the above scenario occur, the immediate solution is to disable Extranet lockout. Longer term remedies may come in different forms:

Ensure a redundant path on the network exists between the two locations, to avoid single points of failure;
Consider moving the FSMO roles into the data center where AD FS lives to eliminate the WAN as a point of failure;
Reconsider use of Extranet Lockout until one of the above two are implemented… Disclaimer (see below)

However, the PDC Emulator role, hosted on a single domain controller, does introduce a single point of failure. FSMO roles can be seized or transferred, though this requires manual intervention. A good monitoring setup can also help reduce potential downtime by way of monitoring the PDC emulator or more specifically, the server running underneath it. Monitoring AD FS service health can also help identify problems if the tool used is capable of checking logon with a synthetic transaction (e.g. testing login with a SOAP message against a WS-Trust endpoint). Nonetheless, the fact remains that with the feature enabled, this represents a single point of failure into your AD FS setup. You’ll need to evaluate organizational requirements (security v availability) and whether the individual protection offered by Extranet Lockout outweighs the possible service availability impact that arises through failure of the server hosting the PDC Emulator.

Customizing AD FS Relying Parties in Windows Server 2016 (TP4)

February 15, 2016AD FS 2016, AD FS 4.0, AD FS VNext, Powershell, Relying Party, Windows Server 2012 R2, Windows Server 2016AD FS 4.0; Windows Server 2016; Relying Party; Customization; RP;mylo

A while back I was lucky enough to chat with a member of the AD FS development team, to compare notes and discuss features missing or lacking in the current release. One item that popped up and which I rued the absence of, was the ability to customize relying parties. It turned out that this was a fairly common feature request. This omission, I’m glad to see, has been addressed in AD FS under Windows Server 2016. While the changes described are mostly cosmetic, they do allow some basic changes to the look and feel of the environment and, most importantly, improve overall user experience. Let’s have a look at some of these.

Our basic configuration consists of a Windows Server 2016 TP4 server with the AD FS role installed and the presence of a relying party trust to a SAML-based web application. Our relying party, called ‘simpleSAMLphp Demo’, will be the guinea-pig for this little exercise, though it plays no real part besides kicking off the sign-in process (RP-initiated sign-on). All changes are made on the AD FS side to customize the login experience.

Message-Level

Here we tinker with messages presented to the connecting user/device via the Set-AdfsRelyingPartyWebContent cmdlet.

Set-AdfsRelyingPartyWebContent -TargetRelyingPartyName “simpleSAMLphp Demo” -CompanyName “Cepa Fidelis ” -OrganizationalNameDescriptionText “Enter your Access Onion account” -SignInPageDescription “This is for access to simpleSAMLphp Demo RP”

Logos and Illustrations

In addition to customizing messages, it’s also possible to present specific logo and illustrations on a per RP basis. Here we copy the content to the AD FS server and then run the Set-AdfsRelyingPartyWebTheme cmdlet :

Set-AdfsRelyingPartyWebTheme -TargetRelyingPartyName “simpleSAMLphp Demo” -Logo @{path=”C:\Content\rp1\logo.png”} -Illustration @{path=”C:\Content\rp1\illustration.png”}

…and connecting users are magically transported to the Tirol Winking smile

Page-level

This allows for page-level changes on a per RP basis. Previously in AD FS 2012 R2, such changes were possible only at the federation service level and thereby applicable to all relying parties.

Set-AdfsRelyingPartyWebTheme -TargetRelyingPartyName “simpleSAMLphp Demo” -OnLoadScriptPath @{path=”c:\content\rp1\onload.js”}

As with Windows Server 2012 R2, we can export the default theme to obtain the javascript (onload.js) that we wish to modify.

Export-AdfsWebTheme –Name default –DirectoryPath c:\content\default

One of the more common onload.js customization changes employed in AD FS 2012 R2 lay with a code change to support the use of sAMAccountName style formatting, similar to that supported in AD FS 2.0. This involved changing the onload.js file and then hardcoding the domain name into the form as described here.

Summary

Well, that’s nice, but these examples are just scratching the surface.. Take a look at the Get-AdfsRelyingPartyWebContent cmdlet and we can see there are multiple additional options that can be changed.

Let’s set a descriptor for additional authentication text.

Set-AdfsRelyingPartyWebContent -TargetRelyingPartyName “simpleSAMLphp Demo” -SignInPageAdditionalAuthenticationDescriptionText “This application requires additional authentication. Please choose the appropriate multi-factor authentication mechanism. Time wasters will be shot.”

Similarly, looking at the cmdlet (Set-AdfsRelyingPartyWebTheme) used to configure logos and illustrations, there’s also some hidden nuggets.

Here, we copy the web theme from one RP (simpleSAMLphp Demo) to another (Office 365).

Logon to Office 365 and the default AD FS theme has logos and illustration changed.

Note that the text/messaging has not been altered, because we did not elect to change this for our O365 RP via Set-AdfsRelyingPartyWebContent.

Explore… explore… have fun!

Certificate Requests and Server Core (and a little AD FS)

January 3, 2016AD FS 4.0, AD FS VNext, Certificates, Certreq, PKI, Powershell, Server Core, Windows Server 2016AD FS 4.0; Windows Server 2016; PKI; Certificates; SSL; Service Communications Certificate; PowerShellmylo

Just a quick post describing how to request an AD FS SSL (service communications) certificate from within Windows Server Core. The OS being used is Windows Server 2016, but, unless otherwise stated, this also applies to Windows Server 2012 R2.

For the enrollment and submission of the request, as well as parsing of the response, we’ll look at two mechanisms:

CERTREQ.EXE
PowerShell

The issuing authority is an Active Directory Certificate Services Enterprise CA.

CERTREQ.EXE

This is the legacy tool uses for certificate enrollment since Windows 2000. While a little cumbersome, it’s provide to be very useful over the years. It’s a command-line utility that parameterizes the request, submission and processing of the request file and certificate response to the Certificate Authority (CA). As a rule-of-thumb, it’s used where traditional enrollment mechanisms: web enrollment or MMC are not available or valid.

To begin a configuration (TXT) file needs to be created. This serves as an input file for completing information concerning the request. We’ll call it ADFSDEMO.TXT.

[Version]

Signature= $Windows NT$

[NewRequest]

Subject = “CN=adfsdemo.mydomain.com ¹, OU=Demo, O=Access_Onion, L=City, S=State/Province, C=NL” ;
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = Microsoft RSA SChannel Cryptographic Provider
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
Hashalgorithm = sha256 ²

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication OID ³

[RequestAttributes]
SAN=”dns=adfsdemo.mydomain.com&dns=enterpriseregistration.mydomain.com&dns=certauth.adfsdemo.mydomain.com” ⁴
;———————————————–
CertificateTemplate=”WebserverV2″

¹ is the common name for our certificate, i.e. the federation services URL.

²specifies a hash algorithm of SHA-256. Note that CNG algorithms are only supported in AD FS in Windows Server 2016. Use SHA-1 for older versions.

³is the Server Authentication object identifier (OID) required for an SSL certificate

⁴are Subject Alternate Names added for Workplace Join and the new certificate enrollment endpoint in Windows Server 2016 / AD FS 4.0

⁵ For third-party certificate authorities or a stand-alone AD CS CA, the CertificateTemplate=”WebserverV2″ line can be dropped.

On our AD Certificate Services Enterprise CA, support for Subject Alternate Names (SAN) needs to be enabled:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

net stop certsvc&&net start certsvc

A template called WebServerV2 has been created (this is a copy of the WebServer built-in template, with compatibility level set to Windows Server 2003 and with certificate duration to 2 years). From CERTREQ.TXT, we generate a REQ (Request) file for submission to the local issuing authority

This is done with the following command:

CERTREQ –new ADFSDEMO.TXT ADFSDEMO.REQ

A response from the local policy filter

Active Directory Enrollment Policy

{521CC4EE-C923-4AE3-9123-A12F655CE123}

ldap:

CertReq: Request Created

And it’s now possible to submit the request file to the CA

CERTREQ –submit ADFSDEMO.REQ

The authority requests confirmation via a popup-window

Click on OK and the CA requests a location to save the generated certificate on the local disk of the server. For consistency, we call it ADFSDEMO.CER.

To complete the installation of the certificate the following command is run:

certreq –accept ADFSDEMO.CER

PowerShell

This section is the picture of conciseness as PowerShell simplifies the enrolment process for us. Here’s the request, submission and installation of the certificate, succinctly rolled-up into one command.

Get-Certificate -Template WebServerV2 -DnsName adfsdemo.mydomain.com,enterpriseregistration.mydomain.com,certauth.adfsdemo.mydomain.com -Subjectname -CertStoreLocation cert:\LocalMachine\My

Summary

Note that on the AD FS server, it’s possible to drop into Powershell to have a look at the issued certificate

dir cert:\localmachine\my

Assuming the server has already been domain-joined, has had the AD FS feature installed (Add-WindowsFeature ADFS-Federation) and a service account created in AD, then the configuration wizard of the AD FS farm can begin. Here’s an example of a WID-based deployment for the first farm node, utilizing the thumbprint of the SSL cert. The credentials for the service account are collected via the variable $cred, before being called in the Install-ADFSFarm cmdlet.

$cred=Get-Credential

Install-ADFSFarm –CertificateThumbprint 57C0D558EC02… –FederationServiceDisplayName ‘Access Onion’ –FederationServiceName adfsdemo.mydomain.com –ServiceAccountCredential $cred –OverwriteConfiguration

Till next time..

The Access Onion

Access Management and Identity Federation on a plate.