Category Archives: Windows Server 2016

AD FS – Old Habits (idpinitiatedsignon.aspx)

AD FS 2.0, AD FS 2016, AD FS 3.0, AD FS R2, AD FS VNext, ADFS, Windows Server 2012 R2, Windows Server 2016, , , , , , ,

Usually after building an AD FS/WAP farm I test locally from the Internet and the Intranet using (to-date) a fairly reliable source of verification that the service is up and running. I’m referring to, of course, the IdP sign-in page (../adfs/ls/idpinitiatedsignon.aspx). This offers a simple way of validating login via AD FS.

With Windows Server 2016, this page is no longer surfaced “out-of-the-box”.. if you want to do a SAML 2.0  IdP-initiated sign-on, this functionality will need to be enabled. Otherwise, connecting to the obligatory sign-in page, will produce an error similar to the following:

2016-06-10_18-06-00

Testing from the Web Application Proxy itself directly,  pointing to the AD FS farm, we may see an HTTP 503 Service Not Available error.

Via Powershell, it can be switched back on:

set-adfsproperties -EnableIdpInitiatedSignon $True

Now, before we get too hasty,  knowing that we can turn it back on versus actually turning it back on are two different things 🙂 If it’s directly required, IdP-driven sign-on is a feature of your federation setup, then you may have no choice. For example, certain SaaS/Cloud applications simply don’t support SP-initiated workflow.

For some organizations I’ve worked for though, this page is seen as insidious because it reveals the relying parties configured on your AD FS farm anonymously.

AD FS 2.0

2016-06-16_18-57-06

AD FS 2012 R2

2016-06-16_18-58-34

Going back to AD FS 2.0, customers are often unwilling to float this data anonymously via the sign-in page and want to hide the RP enabled trusts visible on the page, sometimes re-writing the code behind to do so or even hiding it from the browser via obfuscation.

Whatever your view, it’s off by default in Windows Server 2016. Those of a paranoid bent may now breathe …………. in….. out….in… out…. there you go 🙂

 

 

Office 365 and MFA in AD FS 2016 (TP4)

2FA, AD FS 2016, AD FS 4.0, MFA, Multi-Factor Authentication, Office 365, Powershell, Relying Party, Windows Server 2016

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.

clip_image002

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

image

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

clip_image004

If we compare that with a normal RP.

image

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.

clip_image006

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

clip_image008

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.

clip_image010

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

clip_image012

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:

image

As ever, play and test at your own peril Smile

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

AD FS 2016, AD FS 4.0, AD FS VNext, Powershell, Relying Party, Windows Server 2012 R2, Windows Server 2016

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”

image

 

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”}

 

image

…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.

image

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.”

image

 

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

image

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.

image

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)

AD FS 4.0, AD FS VNext, Certificates, Certreq, PKI, Powershell, Server Core, Windows Server 2016

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:

  1. CERTREQ.EXE
  2. 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 1, 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 2

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication OID 3

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

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

2 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.

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

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

5  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

image

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

image

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

image

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..