Decide on Office 365 Migration Path

Deciding on the best migration path of your users’ email to Office 365 can be difficult. Your migration performance will vary based on your network, existing messaging systems design, mailbox size, migration speed, and so on.

Office365

For migrations from an existing on-premises Exchange Server environment, you can migrate all email, calendar items, tasks and contacts from user mailboxes to Office 365. The available methods are cutover, staged, and Exchange Hybrid migrations.

For migrating third-party email to Office 365, you can configure mail flow coexistence if the third-party email provider permits then migrate the mailboxes using IMAP or cutover migration options.

Migrating from Exchange 2003 or Exchange 2007

Number of mailboxes How quickly do you want to migrate? Use
Fewer than 150 Over a weekend or a few days. Cutover
Fewer than 150 Slowly, by migrating a few users at a time. Staged
Over 150 Over a weekend or a few days. Staged
Over 150 Slowly, by migrating a few users at a time. Staged

Migrating from Exchange 2010 or Exchange 2013 or Exchange 2016 or Exchange 2019

Number of mailboxes How quickly do you want to migrate? Use
Fewer than 150 Over a weekend or a few days. Cutover
Fewer than 150 Slowly, by migrating a few users at a time. Exchange Hybrid
Over 150 Over a weekend or a few days. Exchange Hybrid
Over 150 Slowly, by migrating a few users at a time. Exchange Hybrid

Migrating from third-party email system to Office 365

Number of mailboxes How quickly do you want to migrate? Use
Fewer than 150 Over a weekend or a few days. Cutover
more than 150 Slowly, by migrating a few users at a time. IMAP with mail flow coexistence

If the mailboxes you’re migrating contain a large amount of data, you can also use Office 365 Import Service to import PST files to Office 365.

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

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.

How to deploy VDI using Microsoft RDS in Windows Server 2012 R2

Remote Desktop Services is a server role consists of several role services. Remote Desktop Services (RDS) accelerates and securely extends desktop and applications to any device and anyplace for remote and roaming worker. Remote Desktop Services provide both a virtual desktop infrastructure (VDI) and session-based desktops.

In Windows Server 2012 R2, the following roles are available in Remote Desktop Services: 

Role service name Role service description
RD Virtualization Host RD Virtualization Host integrates with Hyper-V to deploy pooled or personal virtual desktop collections
RD Session Host RD Session Host enables a server to host RemoteApp programs or session-based desktops.
RD Connection Broker RD Connection Broker provides the following services

  • Allows users to reconnect to their existing virtual desktops, RemoteApp programs, and session-based desktops.
  • Enables you to evenly distribute the load among RD Session Host servers in a session collection or pooled virtual desktops in a pooled virtual desktop collection.
  • Provides access to virtual desktops in a virtual desktop collection.
RD Web Access RD Web Access enables you the following services

  • RemoteApp and session-based desktops Desktop Connection through the Start menu or through a web browser.
  • RemoteApp programs and virtual desktops in a virtual desktop collection.
RD Licensing RD Licensing manages the licenses for RD Session Host and VDI.
RD Gateway RD Gateway enables you to authorized users to connect to VDI, RemoteApp

For a RDS lab, you will need following servers.

  • RDSVHSRV01- Remote Desktop Virtualization Host server. Hyper-v Server.
  • RDSWEBSRV01- Remote Desktop Web Access server
  • RDSCBSRV01- Remote Desktop Connection Broker server.
  • RDSSHSRV01- Remote Desktop Session Host Server
  • FileSRV01- File Server to Store User Profile

This test lab consist of 192.168.1.1/24 subnets for internal network and a DHCP Client i.e. Client1 machine using Windows 8 operating system. A test domain called testdomain.com. You need a Shared folder hosted in File Server or SAN to Hyper-v Cluster as Virtualization Host server. All RD Virtualization Host computer accounts must have granted Read/Write permission to the shared folder. I assume you have a functional domain controller, DNS, DHCP and a Hyper-v cluster. Now you can follow the steps below.

Step1: Create a Server Group

1. Open Server Manager from Task bar. Click Dashboard, Click View, Click Show Welcome Tile, Click Create a Server Group, Type the name of the Group is RDS Servers

2. Click Active Directory , In the Name (CN): box, type RDS, then click Find Now.

3. Select RDSWEBSRV01, RDSSHSRV01, RDSCDSRV01, RDSVHSRV01 and then click the right arrow.

4. Click OK.

Step2: Deploy the VDI standard deployment

1. Log on to the Windows server by using the testdomain\Administrator account.

2. Open Server Manager from Taskbar, Click Manage, click Add roles and features.

3. On the Before You Begin page of the Add Roles and Features Wizard, click Next.

4. On the Select Installation Type page, click Remote Desktop Services scenario-based Installation, and then click Next.

clip_image002

5. On the Select deployment type page, click Standard deployment, and then click Next. A standard deployment allows you to deploy RDS on multiple servers splitting the roles and features among them. A quick start allows you to deploy RDS on to single servers and publish apps.

clip_image004

6. On the Select deployment scenario page, click Virtual Desktop Infrastructure, and then click Next.

clip_image006

7. On the role services page, review roles then click Next.

clip_image008

8. On the Specify RD Connection Broker server page, click RDSCBSRV01.Testdomain.com, click the right arrow, and then click Next.

clip_image010

9. On the Specify RD Web Access server page, click RDSWEBSRV01.Testdomain.com, click the right arrow, and then click Next.

clip_image012

10. On the Specify RD Virtualization Host server page, click RDSVHSRV01.Testdomain.com, click the right arrow, and then click Next. RDSVHSRV01 is a physical machine configured with Hyper-v. Check Create a New Virtual Switch on the selected server.

clip_image014

11. On the Confirm selections page, Check the Restart the destination server automatically if required check box, and then click Deploy.

clip_image016

12. After the installation is complete, click Close.

clip_image018

 

 

Step3: Test the VDI standard deployment connectivity

You can ensure that VDI standard deployment deployed successfully by using Server Manager to check the Remote Desktop Services deployment overview.

1. Log on to the DC1 server by using the testdomain\Administrator account.

2. click Server Manager, Click Remote Desktop Services, and then click Overview.

3. In the DEPLOYMENT OVERVIEW section, ensure that the RD Web Access, RD Connection Broker, and RD Virtualization Host role services are installed. If there is an icon and not a green plus sign (+) next to the role service name, the role service is installed and part of the deployment

clip_image020

 

Step4: Configure FileSRV1

You must create a network share on a computer in the testdomain domain to store the user profile disks. Use the following procedures to connect to the virtual desktop collection:

  • Create the user profile disk network share
  • Adjust permissions on the network share

Create the user profile disk network share

1. Log on to the FileSRV1 computer by using the TESTDOMAIN\Administrator user account.

2. Open Windows Explorer.

3. Click Computer, and then double-click Local Disk (C:).

4. Click Home, click New Folder, type RDSUserProfile and then press ENTER.

5. Right-click the RDSUSERPROFILE folder, and then click Properties.

6. Click Sharing, and then click Advanced Sharing.

7. Select the Share this folder check box.

8. Click Permissions, and then grant Full Control permissions to the Everyone group.

9. Click OK twice, and then click Close.

Setup permissions on the network share

1. Right-click the RDSUSERPROFILE folder, and then click Properties.

2. Click Security, and then click Edit.

3. Click Add.

4. Click Object Types, select the Computers check box, and then click OK.

5. In the Enter the object names to select box, type RDSVHSRV01.Testdomain.com, and then click OK.

6. Click RDSVHSRV01, and then select the Allow check box next to Modify.

7. Click OK two times.

Step5: Configure RDSVHSRV01

You must add the virtual desktop template to Hyper-V so you can assign it to the pooled virtual desktop collection.

Create Virtual Desktop Template in RDSVHSRV01

1. Log on to the RDSVHSRV01 computer as a Testdomain\Administrator user account.

2. Click Start, and then click Hyper-V Manager.

3. Right-click RDSVHSRV01, point to New, and then click Virtual Machine.

4. On the Before You Begin page, click Next.

5. On the Specify Name and Location page, in the Name box, type Virtual Desktop Template, and then click Next.

clip_image022

6. On the Assign Memory page, in the Startup memory box, type 1024, and then click Next.

clip_image024

7. On the Configure Networking page, in the Connection box, click RDS Virtual, and then click Next.

clip_image026

8. On the Connect Virtual Hard Disk page, click the Use an existing virtual hard disk option.

clip_image028

9. Click Browse, navigate to the virtual hard disk that should be used as the virtual desktop template, and then click Open. Click Next.

clip_image030

10. On the Summary page, click Finish.

Step6: Create the managed pooled virtual desktop collection in RDSVHSRV01

Create the managed pooled virtual desktop collection so that users can connect to desktops in the collection.

1. Log on to the RDSCBSRV01 server as a TESTDOMAIN\Administrator user account.

2. Server Manager will start automatically. If it does not automatically start, click Start, type servermanager.exe, and then click Server Manager.

3. In the left pane, click Remote Desktop Services, and then click Collections.

4. Click Tasks, and then click Create Virtual Desktop Collection.

clip_image031

5. On the Before you begin page, click Next.

6. On the Name the collection page, in the Name box, type Testdomain Managed Pool, and then click Next.

clip_image033

7. On the Specify the collection type page, click the Pooled virtual desktop collection option, ensure that the Automatically create and manage virtual desktops check box is selected, and then click Next.

clip_image035

8. On the Specify the virtual desktop template page, click Virtual Desktop Template, and then click Next.

clip_image037

9. On the Specify the virtual desktop settings page, click Provide unattended settings, and then click Next. In this step of the wizard, you can also choose to provide an answer file. A Simple Answer File can be obtained from URL1 and URL2

10. On the Specify the unattended settings page, enter the following information and retain the default settings for the options that are not specified, and then click Next.

§ In the Local Administrator account password and Confirm password boxes, type the same strong password.

§ In the Time zone box, click the time zone that is appropriate for your location.

11. On the Specify users and collection size page, accept the default selections, and then click Next.

12. On the Specify virtual desktop allocation page, accept the default selections, and then click Next.

13. On the Specify virtual desktop storage page, accept the default selections, and then click Next.

14. On the Specify user profile disks page, in the Location user profile disks box, type \\FileSRV01\RDSUserProfile, and then click Next. Make sure that the RD Virtualization Host computer accounts have read and write access to this location.

15. On the Confirm selections page, click Create.

Step8: Test Remote Desktop Services connectivity

You can ensure the managed pooled virtual desktop collection was created successfully by connecting to the RD Web Access server and then connecting to the virtual desktop in the Testdomain Managed Pool collection.

1. Open Internet Explorer.

2. In the Internet Explorer address bar, type https://RDSWEBSRV01.Testdomain.com/RDWeb, and then press ENTER.

3. Click Continue to this website (not recommended).

clip_image039

4. In the Domain\user name box, type TESTDOMAIN\Administrator.

5. In the Password box, type the password for the TESTDOMAIN\Administrator user account, and then click Sign in.

6. Click Testdomain Managed Pool, and then click Connect.

Relevant Configuration

Remote Desktop Services with ADFS SSO

Remote Desktop Services with Windows Authentication

RDS With Windows Authentication