Tag: MFA

ADFS 4.0 Step by Step Guide: Federating with Splunk Cloud

To integrate On-Premises SSO with Splunk Cloud, you need the following items:

  • An administrative account in your ADFS
  • An administrative account in your Windows Active Directory
  • An administrative account for your Splunk Cloud instance or tenant.

Step1: Create Security Groups

  1. Sign into Domain Controller
  2. Open Active Directory Users and Computers
  3. Create two security groups named, SG-SplunkAdmin and SG-SplunkUsers

Step2: Download IdP (ADFS 2016) Metadata

  1. Log into the ADFS 2016 server or an admin PC.
  2. Open a browser and type metadata URL https://ADFSServer1.domain.com/federationmetadata/2007-06/federationmetadata.xml
  3. Download and save the metadata as IdP metadata.

Step3: Download Splunk Metadata

  1. Login to Splunk Cloud instance using administrator credentials.
  2. Download metadata from your instance of Splunk Cloud or This can be obtained by, once logged into a session as an admin role user, entering the URL https://yourinstance.splunkcloud.com/saml/spmetadata into your browser’s URL field.
  3. Download and save the metadata as SP metadata

Step4: Extract Splunk certificate from metadata

  1. Open Splunk metadata XML file in a notepad, Search “X509Certificate” in the metadata. Copy the everything starting from XML tags from ‘<ds:X509Certificate>‘ to ‘</ds:X509Certificate>‘.
  2. Open a new notepad and paste the content into the notepad. Place a row above the certificate with the text —–BEGIN CERTIFICATE—– and a row below the certificate with the text —–END CERTIFICATE—–
  3. Save the notepad as a .cer
  4. The file will look like this one but with more hexadecimal character

—–BEGIN CERTIFICATE—–

MIIEsjCCA5qgAwIBAgIQFofWiG3iMAaFIz2/Eb9llzANBgkqhkiG9w0BAQsFADCB

sjFuz4DliAc2UXu6Ya9tjSNbNKOVvKIxf/L157fo78S1JzLp955pxyvovrsMqufq

YBLqJop4

—–END CERTIFICATE—–

Step5: Create a Relying Party Trust

  1. Log into the ADFS 2016 server and open the management console.
  2. Right-click Service>Relying Party Trusts>Select Add Relying Party Trust from the top right corner of the window.
  3. Click Claims aware>Click Start
  4. Click Import Data about the relying party
  5. Browse the location where you saved Splunk metadata, select metadata, and Click Next
  6. Type the Display Name as SplunkRP, Click Next
  7. Ensure I do not want to configure multi-factor authentication […] is chosen, and click Next
  8. Permit all users to access this relying party.
  9. Click Next and clear the Open the Claims when this finishes check box.
  10. Close this page. The new relying party trust appears in the window.
  11. Right-click on the relying party trust and select Properties.
  12. On the properties, choose the Encryption tab, Remove the certificate encryption
  13. Choose the Signature tab and make sure the Splunk Certificate was imported
  14. Select to the Advanced tab and set the Secure hash algorithm to SHA-1.
  15. Click into the Identifiers tab. The default Relying party identifier for Splunk came in from the metadata file as ‘splunkEntityId’. Remove Default one. Add new entity ID splunk-yourinstance
  16. Under the Endpoints tab, make sure the Consumer Endpoints is https://yourinstance.splunkcloud.com/saml/acs  with a Post binding and index 0
  17. Under the Endpoints tab, make sure the make sure the Logout Endpoints is https://yourinstance.splunkcloud.com/saml/logout with a Post binding
  18. Click Apply, Click Ok.

Step6: Add Claim Rule for the Relying Party

  1. Log into the ADFS server and open the management console.
  2. Right-click on the Splunk relying party trust and select Edit Claim Rules.
  3. Click the Issuance Transform Rules tab.
  4. Click Add Rules. Add a Rule Type the Name as Rule1
  5. Ensure Send LDAP Attributes as Claims is selected, and click Next
  6. Select the below details

Claim Rule Name =  Rule1

Attribute Store = Active Directory

LDAP Attribute Outgoing Claim Type
Display-Name realName

 
Token-Groups – Unqualified Names Role
E-Mail-Addresses mail
  1. Click Finish. Click Apply
  2. Click Add Rules. Add a Rule Type the Name as  Rule2
  3. Ensure Transform an Incoming Claim is selected, and click Next
  4. Select the below details
Claim Rule Name Rule2

 
Incoming claim type UPN

 
Incoming NameID format Unspecified
Outgoing Claim Type Name ID
Outgoing name ID format Transient Identifier
  1. Click Finish. Click Apply

Step7: Import Splunk Certificate into ADFS Server

  1. Sign into ADFS Server, Open Command Prompt as an Administrator, type MMC.exe
  2. Click File, Click Add/Remove Snap-in
  3. Click Certificates, Click Computer Account
  4. Right Click on Trusted People>All Tasks>Import Certificate
  5. Browse the location of certificate and import
  6. Close MMC.
  7. Repeat these steps in all ADFS Servers in your farm.

Step8: Setup SigningCertificateRevocationCheck to None

Sign into primary ADFS, open PowerShell as an administrator, type the following and hit enter.

Set-ADFSRelyingPartyTrust -TargetName “SplunkRP” -SigningCertificateRevocationCheck None

Step9: Configure SplunkCloud in your instance

  1. On the Splunk instance as an Admin user, choose Settings->Access Controls->Authentication Method.  Choose SAML then click on the ‘Configure Splunk to use SAML’ button.
    within the SAML Groups setup page in Splunk, click on the SAML Configuration button in the upper right corner.
  2. The SAML Configuration popup window will appear. Click on Select File to import the XML Metadata file (or copy and paste the contents into the Metadata Contents textbox) and click Apply.
  3. The following fields should be automatically populated by the metadata:
    Single Sign On (SSO) URL
    Single Log Out (SLO) URL
    idP’s Certificate file
    Sign AuthnRequest (checked)
    Sign SAML response (checked)
    Enter in the Entity ID as splunk-yourinstance as was used in ADFS RP Identifier property of the ADFS configuration.
  4. Scroll down to the ‘Advanced Settings‘ section.
    Enter in the Fully Qualified Domain Name (FQDN) of the Splunk Cloud instance – ‘https://yourinstance.splunkcloud.com
    Enter a ‘0‘ (zero) for the Redirect port – load balancer’s port.
    Set the Attribute Alias Role to ‘http://schemas.microsoft.com/ws/2008/06/identity/claims/role’
    It may also be necessary to set an Attribute Alias for ‘Real Name’ and ‘Mail’ – but not all implementations require these settings. Click Save to Save the configuration:
  5. The next step is set up the SAML groups. Within the Splunk ‘Settings->Access Controls->Authentication Method->SAML Settings‘ page, click the green “New Group” button
  6. Enter a group name that associates with ADFS Active Directory passed group names, some examples follow
Group Name (Type this name on New Group Properties ) Splunk Role (Select from Available Roles) Active Directory Security Group
SG-SplunkAdmin Admin SG-SplunkAdmin
SG-SplunkUsers User SG-SplunkUsers
  1. Click Save.

Step10: Testing SSO

  1. To test SSO, visit  https://yourinstance.splunkcloud.com/en-US/account/login?loginType=splunk  You will be redirected to ADFS STS Signing Page. Enter your on-premises email address and password as the credential.  You should be redirected back to Splunk Cloud.
  2. Also test logging out of Splunk, you should be re-directed to the Splunk SAML logout page.

 

ADFS 4.0 Step by Step Guide: Federating With Google Apps

To integrate On-Premises SSO with Google Apps, you need the following items:

Step1: Export ADFS Token Signing Certificate

  1. Log into the ADFS 2016 server and open the management console.
  2. Right-click Service>Certificate
  3. Right-click the certificate and select View Certificate.
  4. Select the Details tab.
  5. Click Copy to File. The Certificate Export Wizard opens.
  6. Select Next. Ensure the No, do not export the private key option is selected, and then click Next.
  7. Select DER encoded binary X.509 (.cer), and then click Next.
  8. Select where you want to save the file and give it a name. Click Next.
  9. Select Finish.

Step2: Download Google Certificate

  1. Login to Google Admin console with administrator permission to add new apps.
  2. Go to Apps > SAML Appsand click “+” at the right bottom of the page to add a new SAML IDP (“Enable SSO for SAML Application”).
  3. Select the “Setup my own custom app” at the bottom of the window. You will see the “Google IdP Information” page. Click Download button to retrieve google certificate.

Step3: Create a Relying Party Trust

  1. Log into the ADFS 2016 server and open the management console.
  2. Right-click Service>Relying Party Trusts>Select Add Relying Party Trust from the top right corner of the window.
  3. Click Claims aware>Click Start
  4. Click Enter Data about the relying party manually
  5. Give it a display name such as GoogleApps>Click Next>Click Next
  6. On the Configure URL Page, Check Enable support for the SAML 2.0 WebSSO protocol and type  https://www.google.com/a/domain.com/acs, Click Next
  7. On the Configure RP Identifier Page, type the identifiers: google.com/a/domain.com, Click Add
  8. Ensure I do not want to configure multi-factor authentication […] is chosen, and click Next
  9. Permit all users to access this relying party.
  10. Click Next and clear the Open the Claims when this finishes check box.
  11. Close this page. The new relying party trust appears in the window.
  12. Right-click on the relying party trust and select Properties.
  13. Select to the Advanced tab and set the Secure hash algorithm to SHA-256.
  14. Under the Endpoints tab, click Add SAML Logout with a Post binding and a URL of https://sts.domain.com/adfs/ls/?wa=wsignout1.0
  15. Select to signature tab, Click Add.. Import the google certificate, you have exported from Google admin console. Click Apply, Click Ok.

Step4: Add Claim Rule for the Relying Party

  1. Log into the ADFS server and open the management console.
  2. Right-click on the GoogleApps relying party trust and select Edit Claim Rules.
  3. Click the Issuance Transform Rules tab.
  4. Click Add Rules. Add a Rule Type the Name as GoogleApps Rule
  5. Ensure Send LDAP Attributes as Claims is selected, and click Next
  6. Select the below details
  • Claim Rule Name =  Send Email Address As NameID
  • Attribute Store = Active Directory
  • LDAP Attribute = E-mail-Addresses
  • Outgoing Claim Type = Name-ID
  1. Click Finish. Click Apply

Step5: Configure Google Apps in Admin Console

  1. Sign into the Google Apps Admin Console using your administrator account.
  2. Click Security. If you don’t see the link, it may be hidden under the More Controls menu at the bottom of the screen.
  3. On the Security page, click Setup single sign-on (SSO).
  4. Perform the following configuration changes:
  1. In Google Apps, for the Verification certificate, replace and upload the ADFS token signing certificate that you have downloaded from ADFS.
  2. Click Save Changes.

Step6: Testing SSO

To test SSO, visit http://mail.google.com/a/domain.com.  You will be redirected to ADFS STS Signing Page. Enter your on-premises email address and password as the credential.  You should be redirected back to Google Apps and arrive at your mailbox.

ADFS 4.0 Step by Step Guide: Federating with ServiceNow

Prerequisites:

Step1: Export Token Signing Certificate

  • Log into the ADFS 2016 server and open the management console.
  • Right-click Service>Certificate
  • Right-click the certificate and select View Certificate.
  • Select the Details tab.
  • Click Copy to File. The Certificate Export Wizard opens.
  • Select Next.Ensure the No, do not export the private key option is selected, and then click Next.
  • Select DER encoded binary X.509 (.cer), and then click Next.
  • Select where you want to save the file and give it a name. Click Next.
  • Select Finish. The instance requires that this certificate be in PEM format. You can convert this certificate using client tools or even online tools such as: SSL Shopper.
  • Use the DER/Binary certificate that you just created, and export it in Standard PEM format.
  • Right Click on the exported certificate>Edit with Notepad
  • Copy everything from Begin Certificate to End Certificate including —– and Paste in Service Now when needed.

—–BEGIN NEW CERTIFICATE REQUEST—–

/DY5HA/Cz5fElf4YTQak8PZMmCcndgPA==

—–END NEW CERTIFICATE REQUEST—–

Step2: Create a Relying Party Trust

  • Log into the ADFS 2016 server and open the management console.
  • Right-click Service>Relying Party Trusts>Select Add Relying Party Trust from the top right corner of the window.
  • Click Claims aware>Click Start
  • Click Enter Data about the relying party manually
  • Give it a display name such as ServiceNow>Click Next>Click Next>Click Next
  • Enter the instance site to which you connected as the Relying Party trust identifier. In this case use https://company.service-now.com and click Add.
  • Permit all users to access this relying party.
  • Click Next and clear the Open the Claims when this finishes check box.
  • Close this page. The new relying party trust appears in the window.
  • Right-click on the relying party trust and select Properties.
  • Browse to the Advanced tab and set the Secure hash algorithm to SHA-1.
  • Browse to the Endpoints tab and add a SAML Assertion Consumer with a Post binding and a URL of https://company.service-now.com/navpage.do
  • Under the Endpoints tab, click Add SAML Logout with a Post binding and a URL of https://sts.domain.com/adfs/ls/?wa=wsignout1.0

Step3: Add Claim Rule

  • Log into the ADFS server and open the management console.
  • Right-click on the ServiceNow relying party trust and select Edit Claim Rules.
  • Click the Issuance Transform Rules tab.
  • Select Add Rules. Add Custom Rule Type the Name as ServiceNow Rule, Copy and Paste the below rule.

Rule#1

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&#8221;, Issuer == “AD AUTHORITY”]

=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&#8221;, “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&#8221;, “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&#8221;), query = “;userPrincipalName,sAMAccountName,mail;{0}”, param = c.Value);

Rule#2

c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”%5D

=> issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&#8221;,

Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,

Properties[“http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format”%5D

= “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”);

Step4: Activate SSO in ServiceNow

  • Sign-on to your ServiceNow application as an administrator.
  • Activate the Integration – Multiple Provider Single Sign-On Installer plugin by following the next steps:
  • In the navigation pane on the left side, go to System Definition section and then click Plugins.
  • Search for Integration – Multiple Provider Single Sign-On Installer.
  • Select the plugin. Rigth click and select Activate/Upgrade.
  • Click the Activate
  • In the navigation pane on the left side, click Properties.
  • On the Multiple Provider SSO Properties dialog, perform the following steps:
  • As Enable multiple provider SSO, select Yes.
  • As Enable debug logging got the multiple provider SSO integration, select Yes.
  • In The field on the user table that… textbox, type user_name.
  • Click Save.

Step5: Import Certificate in ServiceNow

  • In the navigation pane on the left side, click x509 Certificates.
  • On the 509 Certificates dialog, click New.
  • On the 509 Certificates dialog>Click New.
  • In the Name textbox, type a name for your configuration (e.g.: 0).
  • Select Active.
  • As Format, select PEM.
  • As Type, select Trust Store Cert.
  • Open your Base64 encoded certificate in notepad, copy the content of it into your clipboard, and then paste it to the PEM Certificate
  • Click Update.

Step6: Configure IdP provider

  1. In the navigation pane on the left side, click Identity Providers.
  2. On the Identity Providers dialog, click New:
  3. On the Identity Providers dialog, click SAML2 Update1?:
  4. On the SAML2 Update1 Properties dialog, perform the following steps:
  • in the Name textbox, type a name for your configuration (e.g.: SAML 2.0).
  • In the User Field textbox, type email or user_name, depending on which field is used to uniquely identify users in your ServiceNow deployment.
  • copy the Identity Provider ID value http://sts.domain.com/adfs/ls, and then paste it into the Identity Provider URL textbox
  • copy the Authentication Request URL value http://sts.domain.com/adfs/ls, and then paste it into the Identity Provider’s AuthnRequest
  • copy the Single Sign-Out Service URL value https://domain.com/adfs/ls/?wa=wsignout1.0, and then paste it into the Identity Provider’s SingleLogoutRequest textbox.
  • In the ServiceNow Homepage textbox, type the URL https://company.service-now.com/navpage.do of your ServiceNow instance homepage
  • In the Entity ID / Issuer textbox, type the URL https://company.service-now.com/of your ServiceNow tenant.
  • In the Audience URL textbox, type the URL https://company.service-now.com/ of your ServiceNow tenant.
  • In the Protocol Binding for the IDP’s SingleLogoutRequest textbox, type urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect.
  • In the NameID Policy textbox, type urn:oasis:names:tc:SAML:1.1:nameid-format:emailaddress.
  • Deselect Create an AuthnContextClass (By deselecting this option, you have created SP-Initiated SSO)
  • In the AuthnContextClassRef Method, Since you are using on-premises ADFS or MFA for authentication then you should not configure this value.
  • In Clock Skew textbox, type 60.
  • As Single Sign On Script, select MultiSSO_SAML2_Update1.
  • As x509 Certificate, select the certificate you have created in the previous step.
  • Click Submit.

Testing Single Sign On:

IdP Initiated Signon Redirect:

To create a direct link so users do not need to select from a drop down list, browse to https://sts.domain.com/adfs/ls/idpinitiatedsignon.aspx?logintoRP=https://company.service-now.com

SP-Initiated Signon:

https://company.service-now.com/navpage.do

Building Multiple ADFS Farms in a Single Forest

Let’s paint a picture, you have an unique requirement to build multiple ADFS farms. you have a fully functional hybrid environment with EXO. you do not want to modify AAD connect and existing ADFS servers. But you want several SaaS applications use different ADFS farm with MFA but their identity is managed by the same Active Directory forest used by existing ADFS farm.

Here is the existing infrastructure:

  • 1 single forest with multiple hybrid UPNs (domainA.com, domainB.com, domainC.com and many…)
  • 2x ADFS servers (sts1.domainA.com)
  • 2X WAP 2012 R2 cluster
  • 1x AAD Connect
  • 1X Office 365 Tenant with several federated domains (domainA.com, domainB.com, domainC.com and many….)
  • 1x public CNAME sts1.domainA.com

Above configuration is working perfectly.

Now you would like to build a separate ADFS 2016 farm with WAP 2016 cluster for SaaS applications. This ADFS 2016 farm will be dedicated to authenticate these SaaS applications. you would also like to turn on MFA on ADFS 2016. Add new public authentication endpoint such as sts2.domainA.com for ADFS 2016 farm.

End goal is that once user hit https://tenant.SaaSApp.com/ it will redirect them to sts2.domain.com and prompt for on-prem AD credentials and MFA if they are accessing from public network.

New ADFS 2016 infrastructure in the same forest and domain:

  • 2X ADFS 2016 Servers (sts2.domainA.com)
  • 2X WAP 2016 Servers
  • 1 X separate public IP for sts2.domainA.com
  • 1X public CNAME for sts2.domainA.com
  • 1X Private CNAME for sts2.domainA.com

Important Note: You have to prepare Active Directory schema to use ADFS 2016 functional level. No action/tasks necessary in existing ADFS 2012 R2 environment.

Guidelines and referrals to build new environment.

Upgrading AD FS to Windows Server 2016 FBL

ADFS 4.0 Step by Step Guide: Federating with Workday

Branding and Customizing the ADFS Sign-in Pages

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part I

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part II

Upgrading AD FS to Windows Server 2016 FBL

This article will describe how to install new ADFS 2016 farm or upgrade existing AD FS Windows Server 2012 R2 farm to AD FS in Windows Server 2016.

Prerequisites:

  • ADFS Role in Windows Server 2016
  • Administrative privilege in both ADFS 2012 R2 and ADFS 2016 Server
  • Local Admin rights in both ADFS 2012 R2 and ADFS 2016 Server
  • WAP role in Windows Server 2016
  • Generate new certificate and signed by public certificate authority for new installation
  •   To use existing certificate, export the certificate from ADFS 2012 R2 with private key and import into ADFS 2016 server.

Mixed Mode Farm: A Windows Server 2016 AD FS server can be added to a Windows Server 2012 R2 farm and it will operate at the same FBL as a Windows Server 2012 R2. When you have a Windows Server 2016 AD FS server operating in this fashion, your farm is said to be “mixed”. However, you will not be able to take advantage of the new Windows Server 2016 features until the FBL is raised to Windows Server 2016.

Installation of ADFS Role

  1. Open the Windows Server 2016, Add Roles and Features Wizard and add the Active Directory Federation Services server role
  2. Proceed through the wizard. Click Configure the federation service on this server.
  3. On the Welcome page in the Active Directory Federation Services Configuration Wizard, choose an option for a federation server, and then click Next
  4. Proceed through the wizard. To join to existing farm, specify the farm name and import the certificate or to create a new farm, click create new farm and provide the details. On the Specify Service Properties page, select your TLS/SSL certificate, enter a Federation Service Name, and then enter a Federation Service Display Name
  5. Proceed through and complete the Active Directory Federation Services Configuration Wizard. Close the Add Roles and Features Wizard
  6. If you have not created a host record in DNS for the federation server name you specified in Step 4 previously, do so now.

Upgrade ADFS 2016

To Upgrade to ADFS 2016, Once you have joined the new ADFS server to existing farm, on the Windows Server 2016 server, open PowerShell and run the following cmdlt:

Set-AdfsSyncProperties -Role PrimaryComputer

On the original AD FS Windows Server 2012 R2 server, open PowerShell and run the following cmdlt:

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName Server2012R2.domain.com

To use ADFS 2016 functionality, you have prepare AD with ADFS 2016 Schema. Mount Windows Server 2016 installation media on a domain controller, open a command prompt and navigate to support\adprep directory. Run the following:

adprep /forestprep

adprep/domainprep

Now Raise farm behavior level to ADFS 2016, Invoke-AdfsFarmBehaviorLevelRaise  PowerShell Cmdlet on the ADFS 2016 primary server.

To test ADFS 2016 signin page, Enable IdP initiated Sign On and RP initiated Sign on using the following cmdlets to ADFS 2016 Server.

Set-ADFSProperties -EnableIdpInitiatedSignonPage $True

Set-ADFSProperties -RelaystateForIdpInitiatedSignonEnabled $True

Open a browser and type https://sts.domain.com/adfs/ls/idpinitiatedsignon

Removing Legacy ADFS and WAP

  • Remote into the servers and uninstall ADFS and Remote Access Role

Installing Federation Proxy

  • Install Windows Server 2016
  • Rename the server
  • Setup IPv4 on the WAP server
  • Install WAP Role using the below PowerShell Cmdlets.
  • Add a host a record of STS in the C:\Windows\systems32\drivers\etc\hosts file of WAP server

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools
Install-WebApplicationProxy –CertificateThumbprint ‘1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b’ -FederationServiceName sts.domain.com

Firewall Rules for WAP Servers

Add firewall rules for WAP servers if WAP servers are placed behind firewall. You must allow inbound and outbound rules on port 443 from WAP servers to internet.

Firewall Rules for ADFS servers

ADFS servers are domain joined and placed in internal network but WAP servers are place in different VLANS or DMZ  to secure ADFS servers. You must allow port 443 between ADFS and WAP in both direction.

Firewall Rules for ADFS 2016 with MFA

If your ADFS 2016 servers are behind firewall specially going via Azure Express Route , add the below firewall rules in Azure Network Security Group (NSG) for ADFS 2016 MFA.

10.xx.0.0/24 23.99.10.4 HTTPS (TCP/443) Allow
10.xx.0.0/24 23.99.10.4 HTTPS (TCP/443) Allow
10.xx.0.0/24 168.63.89.78 HTTPS (TCP/443) Allow
10.xx.0.0/24 168.63.89.78 HTTPS (TCP/443) Allow
10.xx.0.0/24 40.77.21.104 Custom (TCP/Any) Allow
10.xx.0.0/24 104.42.126.253 Custom (TCP/Any) Allow
10.xx.0.0/24 40.84.187.178 Custom (TCP/Any) Allow
10.xx.0.0/24 52.161.23.17 Custom (TCP/Any) Allow
10.xx.0.0/24 40.87.57.9 Custom (TCP/Any) Allow
10.xx.0.0/24 134.170.116.0/25 Custom (TCP/Any) Allow
10.xx.0.0/24 134.170.165.0/25 Custom (TCP/Any) Allow
10.xx.0.0/24 70.37.154.128/25 Custom (TCP/Any) Allow

ADFS 4.0 Step by Step Guide: Federating with Workday

This article provides step by step guidelines to implement single sign on using ADFS 4.0 as the identity provider and Workday as the identifier and service provider.

Important Note:

  • Workday does not provide a service provider metadata XML file to import into AD FS.
  • Workday does not import federation metadata automatically
  • Workday does not support SAML timed out.
  • Do not tick SP initiated Auth or IdP initiated Auth at the same time. Use one or the other not both.

Prerequisites:

  • Active Directory Federation Services 4.0
  • Workday tenant
  • Admin access in Workday and ADFS

Workday supports both Idp Initiated Auth and SP initiated Auth. In both cases ADFS configuration does not change but Workday configuration will change depending on what you select as your authentication method i.e. IdP initiated or SP initiated. Workday has two section to configure in Edit Security in Workday Tenant 1. SSO section and 2. SAML Auth Section.

Workday SSO IDP Initiated Auth

Single Sign-on

Login Redirect URL:  https://sts.domain.com/adfs/ls/idpinitiatedSignon.aspx?loginToRp=https://www.workday.com/

Logout Redirect URL: https://sts.domain.com/adfs/ls/?wa=wsignoutcleanup1.0

Timeout Redirect URL:  https://wd3.myworkday.com/tenant/login-saml2.htmld (Workday does not support SAML timed out. So when a user’s session is timed out, they will be redirected back to sign in page. Use the sign url as timed out url)

Mobile Login Redirect URL:  https://sts.domain.com/adfs/ls/idpinitiatedSignon.aspx?loginToRp=https://www.workday.com/

SAML Setup

Enable SAML Authentication: Enabled

Identity Provider: IDPInitiatedAuth

Issuer: http://sts.domain.com/adfs/services/trust (do not type https in issuer)

X509 Certificate: sts.domain.com (Export certificate from ADFS, open the certificate in notepad, copy and paste the certificate in Workday security configuration)

Enable Idp Initiated Authentication: Enabled

Enable Workday Initiated Logout: Enabled

Enable IdP Initiated Logout: Enabled

Logout Request URL: https://sts.domain.com/adfs/ls/?wa=wsignoutcleanup1.0

Logout Response URL https://sts.domain.com/adfs/ls/?wa=wsignoutcleanup1.0

IdP SSO Service URL: http://sts.domain.com/adfs/services/trust

Workday SP Initiated Authentication

Single Sign-on

Login Redirect URL:  https://wd3.myworkday.com/tenant/login-saml2.htmld

Logout Redirect URL:  https://sts.domain.com/adfs/ls/

Timeout Redirect URL:  https://wd3.myworkday.com/tenant/login-saml2.htmld (Workday does not support SAML timed out. So when a user’s session is timed out, they will be redirected back to sign in page. Use the sign url as timed out url)

Mobile Login Redirect URL:  https://wd3.myworkday.com/tenant/login-saml2.htmld

SAML Setup

Enable SAML Authentication: Enabled

Identity Provider: SPInitiatedAuth

Issuer: http://sts.domain.com/adfs/services/trust (do not type https in issuer)

X509 Certificate: sts.domain.com (Export certificate from ADFS, open the certificate in notepad, copy and paste the certificate in Workday security configuration)

Enable SP Initiated Authentication: Enabled

Enable Workday Initiated Logout: Enabled

Enable IdP Initiated Logout: Enabled

Logout Request URL: https://sts.domain.com/adfs/ls/

Logout Response URL https://sts.domain.com/adfs/ls/

IdP SSO Service URL: https://sts.domain.com/adfs/ls

Force IdP initiated Authentication: ForceAuth Only

Active Directory Federation Services Configuration

Relying Party Metadata: Copy the metadata and save as XML then import into Relying Party of ADFS.


<?xml version=”1.0″ encoding=”UTF-8″?>
<md:EntityDescriptor entityID=”http://www.workday.com&#8221; 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://wd3.myworkday.com/tenant/login-saml.htmld” index=”0″ isDefault=”true”/></md:SPSSODescriptor></md:EntityDescriptor>

Create Claim Rule

Template: Send LDAP Attributes as Claims

EmployeeNumber Name ID
EmailAddresess UPN
SAM-Account-Name Windows Account Name (Use this option to automatically SSO from internal network)

Access Control from ADFS

Access Control using SSO from internal network and SSO using MFA from external network.  Create a separate access control policy

Name: Workday

Description: Grant Access to Workday XYZ tenant

Permission:

  1. Permit everyone
  2. Permit a security group from Active Directory and from intranet
  3. Permit the same security group in number 2 from Active Directory, from internet and require MFA

Remote into Domain Controller and add users to the security groups mentioned in number 2 and number 3 of access policy using the below PowerShell

CSV Header: UserPrincipalName, SecurityGroup

Import-Module ActiveDirectory
$Csv = Import-Csv C:\temp\AddUsersToGroups.csv
Foreach ($item in $csv) {
$UPN = $Item.UserPrincipalName
$Groups=$Item.SecurityGroup
$Users=Get-ADUser -Filter “UserPrincipalName -eq ‘$UPN'” | % {Add-ADGroupMember -Identity $Groups -members $UPN}

ADFS properties looks like below:

Endpoints: https://wd3.myworkday.com/tenant/login-saml.htmld

Binding: Post

Default: Yes

SAML Signout URL: https://sts.domain.com/adfs/ls/?wa=wsignoutcleanup1.0

SAML Signout Binding : POST

Signature: Import private key from Workday and add into the signature tab of Workday relying party properties.

Encryption: SHA256 (Workday does not support SHA1 anymore)

Certificate Bits: 2048 (Microsoft no longer support 1024 bits)

Allow SAML Signature and Skew Time. Open PowerShell in ADFS Server and run the below cmdlets.

Set-ADFSRelyingPartyTrust -TargetName Workday -SamlResponseSignature “MessageOnly”

Set-ADFSRelyingPartyTrust -TargetName Workday -NotBeforeSkew 3

Test ADFS SSO:

Open any browser and type: https://wd3.myworkday.com/tenant/login.htmld or https://wd3.myworkday.com/tenant from internal and external network or from mobile app.

Login to Exchange Online PowerShell using MFA

Once you enable MFA on Admin account, you will be denied access to EXO using PowerShell until you update Azure PowerShell version to latest.

Download and install Microsoft Online Services Sign-In Assistant and Azure Active Directory Connection preview

Use Connect-MsOlService Cmdlets, you will prompted to signin in a browser with MFA. Once correct MFA is provided, you are signed into Office 365.