Category Archives: AD FS VNext

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 🙂

 

 

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