ADFS 3.0 and Workday Single Sign-On

This step guide has been generated to assist in the configuration of ADFS 3.0 and Workday to provide Single Sign on

Pre Requisites

  • ADFS 3.0 Infrastructure
  • ADFS Administrative Access
  • Workday Tennant
  • Workday Administrative Access

Exporting the ADFS Token Signing Certificate

In order for the 3rd party online service to trust your Active Directory Federation Service and the authentication token provided to them you must provide them with the Token signing certificate applied to your Federation Service endpoint, you can export the Token signing certificate by following the steps below.

  1. Open “Server Manager” and under the “Tools” section select “AD FS Management”
  2. Wait for the AD FS Management page to load and expand the “Service” folder and then select the “Certificates” folder


  1. Locate and right select the “Token-signing” certificate, and select “View Certificate”


4.    On the Certificate popup, select the “Details” tab and select “Copy to File”

  1. On the “Welcome to the Certificate Export Wizard” select “Next”
  2. On the “Certificate Export Wizard” page select “DER encoded binary X.509 (.CER)” for the format


  1. Specify a path and name for the exported file and select “Next”,
  2. On the “Completing the Certificate Export Wizard Page” verify you are not exporting the private key and select “Finish”


Note:    The Token signing certificate is a self-signed certificate any amendments to the certificate and or expiry will mean that the certificate will require exporting and re-assigning

Configuring the Relying Party in Active Directory Federation Services

To create a relying party trust using federation metadata follow the steps below

  1. Create the Workday metadata file by copying the text below to Notepad and entering your tenant specific information in the highlighted section and then save the file as an .mxl file type


    <?xml version=”1.0″ encoding=”UTF-8″?>

    <md:EntityDescriptor entityID=”; xmlns:md=”urn:oasis:names:tc:SAML:2.0:metadata”><md:SPSSODescriptor AuthnRequestsSigned=”false” WantAssertionsSigned=”false” protocolSupportEnumeration=”urn:oasis:names:tc:SAML:2.0:protocol”><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><md:AssertionConsumerService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”https://your_workday_domain/your_tenant_name/login-saml.flex” index=”0″ isDefault=”true”/></md:SPSSODescriptor></md:EntityDescriptor>


  1. Open “Server Manager” and under the “Tools” section select “AD FS Management”
  2. Wait for the “AD FS Management” page to load and expand the “Trust Relationships” folder and then right select the “Relying Party Trusts” folder and select “Add Relying Party Trust”


  1. On the “Welcome” page, select Start.
  2. On the “Select Data Source” page, choose to “Import data about the relying party from a file” by browsing to the metadata file created in step 1.


  1. On the “Specify Display Name” page type a name in “Display name”, under “Notes” type a description for this relying party trust, and then select “Next”.
  2. On the “Configure Multi-factor Authentication Now?” leave the defaults and “Next”


  1. On the “Choose Issuance Authorization Rules” page, select “Permit all users to access this relying party” and then select “Next”.
  2. On the “Ready to Add Trust” page, review the settings, and then select “Next” to save your relying party trust information
  3. If you are ready to configure the claim rules now leave the “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” option checked, if not uncheck the option and select “Close”
  4. The newly created relying party trust should be displayed in the “Relying Party Trusts” folder


  1. Highlight the new relying party trust and right select then select “Properties”
  2. Select the “Endpoints” tab and then select “Add SAML”
  3. In the “Endpoint type” drop down menu, select “SAML Logout” this should automatically change the selection in the “Binding” drop down menu to “POST”
  4. In the “Trusted URL” text field enter the ADFS logout page URL which will be similar to then select “OK”


  1. Confirm you have both the “SAML Assertion Consumer Endpoints” and “SAML Logout Endpoints” populated and then select “Apply”


Required ADFS settings


Workday requires that the SAML message be configured so that the XML signature applies to the entire body of the message as opposed to the default of only the Assertion element, and also allow for any time differences between that of the ADFS service and Workday, in order to configure this you can run the below PowerShell.


Run the following PowerShell commands in order on the ADFS server:

•    Add-PSSnapin Microsoft.Adfs.PowerShell (adds the ADFS snapin to server)

•    Set-ADFSRelyingPartyTrust -TargetName <relyingpartytrust> -SamlResponseSignature “MessageOnly”

•    Set-ADFSRelyingPartyTrust -TargetName <relyingpartytrust> -NotBeforeSkew 3

Configuring the Relying Party Trust Claim Rules

In order to identify any user attempting to login to the service a specific Active Directory attribute will be returned in the authentication token provided, to edit the claim rules to respond with specific attribute mappings follow the steps below.

  1. Open “Server Manager” and under the “Tools” section select “AD FS Management” Wait for the “AD FS Management” page to load and expand the “Trust Relationships” folder and then select the “Relying Party Trusts” folder
  2. Select the Relying Party Trust you wish to add the claim rules to, right select and then select “Edit Claim Rules”
  3. Wait for the “Edit Claim Rules for (relevant) Relying Party Trust” page to load and select the “Issuance Transform Rules” tab and select “Add Rule”


  1. On the “Add Transform Claim Rule Wizard” select “Send LDAP Attributes as Claims” option in the “Claim rule template” drop down menu, then select “Next”
  2. Enter a name for the claim rule in the “Claim rule name” text box, and then in the “Attribute Store” drop down menu select “Active Directory”
  3. In the “Mapping of LDAP attributes to outgoing claim types” table, select the drop down icon in the first column “LDAP Attribute (Select or type to add more)
  4. Select the relevant AD attribute that will be used to identify the user, for the purposes of this guide I have selected “User-Principal-Name”
  5. In the “Outgoing Claim Type (Select or type to add more)” column select “Name ID” then select “Finish”



  1. Ensure the rule has been added then Select “Apply” and then select “OK” to close the window



Configuring Workday to use ADFS as the Identity Provider for Single Sign-On

Listed below is the information required to configure Workday to use ADFS as the identity provider broken down into the sections on the Workday “Edit Tenant Setup – Security” webpage

Single Sign-on

Login Redirect URL
Logout Redirect URL /adfs/ls/?wa=wsignoutcleanup1.0
Timeout Redirect URL /adfs/ls/?wa=wsignoutcleanup1.0
Mobile Redirect URL /adfs/ls/idpinitiatedSignon.aspx?loginToRp=https://


SAML Setup

Enable SAML Authentication Enabled
Identity Provider Name Name of ADFS Identity Provider
Issuer http://
x509 Certificate
Enable IdP Initiated Logout Enabled
Logout Response URL https:// /adfs/ls/?wa=wsignoutcleanup1.0
Enable Workday Initiated Logout Enabled
Logout Request URL https:// /adfs/ls/?wa=wsignoutcleanup1.0
Service Provider ID http://
Enable SP Initiated SAML Authentication Enabled
IdP SSO Service URL http://
Sign SP-initiated Authentication Request Enabled



Skype for Business in Place Upgrade

When carrying out an in place upgrade to Skype for Business ensure that you do not start the services in a mixed mode fashion, upgrade all the Front End Servers in the pool and then execute the new “Start-CSPool” cmdlet, the cmdlet will start all the services on all the Front End Servers in the pool simultaneously, for all non user homed pools for example Edge and Mediation you can continue to use the “Start-CsWindowsService” cmdlet.



Skype 4 Business Upgrade Paths


Current Topology

Desired Topology

In Place Upgrade?

Lync Server 2013 Skype for Business Server and Lync Server 2013 YesIn Place Upgrade Support from Lync Server 2013 to Skype for Business Server
Lync Server 2010 Skype for Business Server and Lync Server 2010 NoRequirement to Migrate from Lync Server 2010 to Skype for Business Server


Lync Server 2010 + 2013 Skype for Business Server and Lync Server 2013 NoRequirement to Migrate all Lync Server 2010 roles to Lync Server 2013 and then upgrade to Skype for Business Server


Polycom RoundTable 100

A new release from Polycom!

April 14, 2015 update for Lync 2013 (Skype for Business Client)

You can download the client update using the link below.