Migrate Office 365 Relying Party Trust to Different ADFS Farm

To migrate Office 365 Relying Party Trust from an existing ADFS Farm to new ADFS Farm, follow the step by step guide. Migrating Office 365 Relying Party Trust will incur a minor disruption to SSO environment.

Prerequisites:

  • Existing ADFS Farm with FQDN sts.domain.com
  • New ADFS Farm with FQDN sts1.domain.com
  • Existing Certificate CN=sts.domain.com or a wildcard certificate
  • New certificate with CN=sts1.domain.com
  • New public IP address for the public CNAME sts1.domain.com
  • A public CNAME record sts1.domain.com
  • An internal CNAME record sts1.domain.com

Note: keep the existing AAD Connect unless you have a requirement to build a new one.

Here are the steps:

Step1: Verify AAD Connect Configuration

  • Open AAD Connect, View Sign-in Option.
  • Check AAD Connect Wizard to make sure you did not configure “Federation with ADFS” Sign-in option. If you have done so then run AAD Connect Wizard again and replace the certificate and ADFS farm details to new ADFS server sts1.domain.com

Step2: Build ADFS and WAP Servers

Build a new ADFS farm side by side with an existing ADFS farm. It would be redundant effort to write another blog. Please follow my previous blog to deploy ADFS and WAP.

Building Multiple ADFS Farms in a Single Forest

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

Branding and Customizing the ADFS Sign-in Pages

Step3: Test SSO

Log on to the https://sts.domain.com/adfs/ls/idpinitiatedsignon.aspx using on-premises credentials to make sure you can single sign-on.

Step4: Gather list of existing federated domains from existing ADFS Farm

Log on to the existing primary ADFS Server, Open PowerShell as an Administrator, execute the following cmdlets.

$cred=Get-Credential

Connect-MsolService –Credential $cred

Get-MsolDomain

Record a list of Federated Domains.

Step5: Update Office 365 RP within the new ADFS Farm

Log on to the new primary ADFS Server, Open PowerShell as an Administrator, execute the following cmdlets.

$cred=Get-Credential

Connect-MsolService –Credential $cred

Update-MsolFederatedDomain –DomaiName “Domain.com” –SupportMultipleDomain –Confirm  Execute Update-MsolFederatedDomain Cmdlets if you have additional federated domains such as DomainB.com

GetMsolDomain

Open ADFS Management Console, Make sure Office 365 RP has been created with necessary tokens and permissions. If necessary, clone all incoming and outgoing claims and permission from previous ADFS farm to new ADFS Farm and apply to the newly created Office 365 RP.

Step6: Test SSOOnce you have completed the Step5, wait for Microsoft to update their backend Identity and Federation systems. In my previous implementation work, it took 30 minutes the change to take effect.  Sign on to portal.office.com; you will be redirected to https://sts1.domain.com to authenticate. Once you have sign-in successfully, you have completed the migration work.

Step7: New AAD Connect Server (Optional)Check step1 before running AAD Connect Wizard and reconfigure sign-in options. If you need to change sign-in options, please follow the guide to change Sign-in Option.

Relevant Articles:

Upgrading AD FS to Windows Server 2016 FBL

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

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

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

Migrate Windows Server 2008/R2 Active Directory to Windows Server 2012/R2 Active Directory

Forest Functional Prerequisites

  1. Check to ensure the Domain Functional Level is currently setup to at least Windows 2003 mode.
  2. Open the Active Directory Users and Computers console, select the domain via the right mouse button on it.
  3. Select Raise Domain Functional Level and review the Current domain functional level reported minimum Windows Server 2003.

RBAC Requirement

Your account must be a member of Domain Admins, Schema Admins and Enterprise Admin.

Systems Requirement

Processor 1vCPU
RAM 4GB
Free disk space requirements 32 GB
Screen resolution 800 x 600 or higher
Network 1 Ethernet
DVD 1

Prepare Windows Machine

  1. Download Windows Server 2012 R2.
  2. Build Windows Server 2012 R2
  3. Join the Server to Domain with a static IP

Prepare Forest and Domain

  1. Mount Windows Server 2012 R2 ISO on to the Windows Server 2008 R2 Domain Controller.
  2. Log on to Windows 2008 R2 Domain as an administrator.
  3. Open command prompt as an administrator, and type adprep /forestprep and press enter.
  4. Open command prompt as an administrator, and type adprep /domainprep and press enter.

Install AD DS Role

  1. Open the Server Manager console and click on Add roles and features
  2. Select Role-based of featured-based installation and select Next.
  3. Select the Active Directory Domain Services role.
  4. Accept the default features required by clicking the Add Features button.
  5. On the Features screen click the Next button.
  6. On the Confirm installation selections screen click the Install button. Check off the Restart the destination server automatically if required
  7. Click the Close button once the installation has been completed.
  8. Once completed, notification is made available on the dashboard highlighted by an exclamation mark. Select it and amidst the drop down menu select Promote this server to a domain controller.
  9. Select add a Domain Controller into existing domain
  10. Ensure the target domain is specified.  If it is not, please either Select the proper domain or enter the proper domain in the field provided.
  11. Click Change, provide the required Enterprise Administrator credentials and click the Next button.
  12. Define if server should be a Domain Name System DNS server and Global Catalog (GC). Select the Site to which this DC belongs to and define Directory Services Restoration Mode (DSRM) password for this DC
  13. Click the Next button on the DNS options screen.
  14. Click the Next button once completed.
  15. Specify location for AD database and SYSVOL and Click the Next button.
  16. Next up is the Schema and Domain preparation.  Alternately, one could run ADPrep prior to commencing these steps, if ADPrep is not detected, it will automatically be completed on your behalf.
  17. Finally, the Review Options screen provides a summary of all of the selected options for server promotion. As an added bonus, when clicking View Script button you are provided with the PowerShell script to automate future installations. To click the Next button to continue.
  18. Should all the prerequisites pass, click the Install button to start the installation.
  19. After it completes the required tasks and the server restarts, the new Windows Server 2012 R2 Domain Controller setup is completed.

Check New Domain Controller in AD Sites and Services

  1. Open Active Directory Users and Computers, expand <Your Domain> and click the Domain Controller OU to verify your server is listed.
  2. Open DNS Manager, right-click on <Your Domain>, select Properties and then click Name Servers Verify that your server is listed in Name Servers: lists.
  3. Open Active Directory Sites and Services; verify that your server is listed in Servers under Default-First-Site-Name.

Check New Domain Controller in DNS Manager

  1. Open DNS Manager in new Domain Controller
  2. Expand Forward Lookup Zone
  3. Select FQDN of domain> Double Click on Name Server (NS)>Properties>Check New Server in Name Server Tab.

Transfer FSMO Role

Now transfer all the FSMO roles from windows 2008 domain controller to windows 2012 R2 domain controller. Log on to windows 2008 domain controller as enterprise admin. Open command prompt type these command as follows:

ntdsutil

roles

connections

connect to server WIN2012R2SERVERNAME

q

Transfer domain naming master

Transfer PDC

Transfer Schema Master

Transfer RID master

Transfer infrastructure master
Change DNS Properties of Servers and Workstation

On each server and workstation within the target domain require a NIC properties configuration update to point to the new Domain Controller. Open the DHCP management console, select Option no. 006 and under server scope options and add the IP address of your new Domain Controller as DNS server.

Removing the Windows 2008 R2 domain controller

  1. On the Windows 2008 R2 server click Start, Click Run, type dcpromo, then click
  2. After the Welcome to the Active Directory Installation Wizard page, be sure to leave the Delete the domain because this server is the last domain controller in the domain
  3. On the Administrator Password Page, enter your password and click Next.
  4. On the Summary page, click Next, wait for the process to end, then click
  5. On the Completing the Active Directory Domain Services Installation Wizard, click
  6. On the Active Directory Domain Services Installation Wizard page, click Restart Now to Restart the server.
  7. After the reboot is completed, delete the Windows Server 2008 R2 server from the domain to a workgroup and remove any unnecessary record from Active Directory Sites and Services.

Note: Wait for all schema object to be cleaned automatically. Do not rush to clean any schema object or DNS record in new Domain Controller.

Why you should not use yourdomain.local domain?

Microsoft recommended use of .local domain when Microsoft released Microsoft Small Business Server. Microsoft also understood that an SBS customer may not have in house expertise to manage Active Directory Domain and Exchange Server. Microsoft understood that SBS user will not have proper firewall. It is obvious that Exchange autodiscovery, single sign on for SharePoint and Lync Server was not in scenario at that time. So Microsoft recommended use of .local domain in Active Directory. Those who worked in SBS environment thought that they could take that concept now and implement .local domain in any organization which is a fundamental design flaw.

You have to understand  that .local domain was a past concept. Moving forward technology has changed a lot since then. You should change yourself when technology changes. But when I visit clients I see that old dog doesn’t learn new trick. Which means their autodiscovery doesn’t work. These clients end up with many issues including blaming Microsoft. You should ask yourself did you design your Active Directory and DNS correctly. Why you expect your autodiscovery to function correctly when your DNS is messy?

When you are promoting a new domain or a new forest, it is highly recommended that you use registered domain name for example yourdomain.com.au. Again those who worked in past SBS era they will raise concern of hacking, TLD etc. I would address their concern by putting the question to them, did you design and configure a correct firewall and security in your corporate infrastructure. If not then you should hire a security professional who will address your concern. Simply promoting a yourdomain.local domain will not secure your domain and you will have a false sense of security that your Active Directory is safe. In realty your corporate network might be open and vulnerable to hacking.

Here are why you should use yourdomain.com.au or registered domain in Active Directory.

  • To implement correct Exchange Autodiscovery
  • To discover correct registered domain for SharePoint and Lync Server
  • To implement single sign on
  • To install correct public certificates for Exchange, SharePoint and Lync. Note that Public Certificate Authority no longer issue certificate using .local domain
  • To use correct UPN of your registered domain
  • To setup correct local and public DNS
  • To design correct Active Directory. You shouldn’t use SBS server as your model. Microsoft retired SBS for many reasons. Brutal truth is Microsoft didn’t want to lose poor customer who couldn’t afford an open license or software assurance so most of SBS users got OEM license through hardware vendor or a reseller.
  • To follow the guidelines of IANA and IEEE when you deal with a domain.

What should you do if you already have a .local domain in SBS server?

If your SBS server is 2008, then create an Active Directory DNS zone using registered domain example: yourdomain.com.au then add HOST (A) record with PTR of webmail or mail and autodiscovery in yourdomain.com.au zone. Create public DNS record for webmail.yourdomain.com.au and autodiscover.yourdomain.com.au.

http://www.yourdomain.com.au (example registered domain) doesn’t resolve after creating yourdomain.com.au?

This happened when http://www.yourdomain.com.au is hosted with third party web hoster not internally. There is an easy fix, create a DNS forwarder or conditional forward for your http://www.yourdomain.com.au. Follow this URL to configure a conditional forwarder. For example: you can forward http://www.yourdomain.com.au to Google DNS server or the DNS server of your ISP or your web hoster who is actually hosting http://www.yourdomain.com.au. To find out who is hosting your website and their DNS record, go to https://www.easywhois.com/ type yourdomain.com.au and hit enter.

Further Study:

http://microsoftguru.com.au/2011/05/28/microsoft-active-directory-best-practice/ 

http://microsoftguru.com.au/2012/07/29/microsoft-active-directory-best-practice-part-ii/

http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html 

http://technet.microsoft.com/en-us/library/cc757172%28v=ws.10%29.aspx

http://technet.microsoft.com/en-us/library/cc754941.aspx

http://technet.microsoft.com/en-us/library/cc794735%28v=ws.10%29.aspx