Archive for June, 2017


Description

Today AD FS is made highly available by setting up an AD FS farm. Some organizations would like a way to have a single server AD FS deployment, eliminating the need for multiple AD FS servers and network load balancing infrastructure, while still having some assurance that service can be restored quickly if there is a problem. The new AD FS Rapid Restore tool provides a way to restore AD FS data without requiring a full backup and restore of the operating system or system state. You can use the new tool to export AD FS configuration either to Azure or to an on-premises location. Then you can apply the exported data to a fresh AD FS installation, re-creating or duplicating the AD FS environment.

Scenarios

The AD FS Rapid Restore tool can be used in the following scenarios:
1.Quickly restore AD FS functionality after a problem•Use the tool to create a cold standby installation of AD FS that can be quickly deployed in place of the online AD FS server

2.Deploy identical test and production environments•Use the tool to quickly create an accurate copy of the production AD FS in a test environment, or to quickly deploy a validated test configuration to production

What is backed up

The tool backs up the following AD FS configuration
•AD FS configuration database (SQL or WID)
•Configuration file (located in AD FS folder)
•Automatically generated token signing and decrypting certificates and private keys (from the Active Directory DKM container)
•SSL certificate and any externally enrolled certificates (token signing, token decryption and service communication) and corresponding private keys (note: private keys must be exportable and the user running the script must have permissions to access them)
•A list of the custom authentication providers, attribute stores, and local claims provider trusts that are installed.

Download and usage

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-rapid-restore-tool

 

Problem description, security issue?

When i log on to my Adfs link below https://sts.mydomain.com/adfs/ls/idpinitiatedsignon.aspx

It showing two of my replying parties asking me sign in.

I have up to 8 other applications i am federating but they are not showing up on this link.

Is this Normal? If its not, how can i remove it? Is this something my relying partner has to fix?

 

Solution:

Do not disable the /adfs/ls endpoint from ADFS management snap-in.

Ask to the application provider (SP) to use WS-Fed and not SAML; using WS-Fed (like MS online 365 RP) will not show the list of RP trusts.

As long as your Relying Party trust has a SAML Assertion Consumer Endpoint, it will show up in the list of RP available for IDP initiated logon.

You can check if you have such endpoints in the graphical interface, or in PowerShell:
(Get-AdfsRelyingPartyTrust -Identifier “<ID of your RP>”).SamlEndpoints

In Windows Server 2012 R2, you cannot not disclose the information. You can use a JavaScript to hide it from the users, but the info will still be available in the code (if the users are curious and look at the HTML source, they will see them). If this is acceptable for you, you can go ahead and create a custom JavaScript for that. I can provide a sample if you want to, but the info is essentially there: https://technet.microsoft.com/en-us/library/dn636121.aspx and on the Internet.

Note that ADFS on Windows Server 2016 changed that behavior and the IdpInitiatedSignon page is not enabled by default. Although once enabled, you still need the JavaScript to hide the list or a part of the list.

This is normal. The Relying Party Trusts showing up are the ones using the SAML Federation Protocol since that protocol has a ‘feature’ called IdP Initiated Sign On where the user can first be authenticated by your ADFS and then choose which of these Relying Party Trusts/Service Providers they want to access (by having ADFS issue them a SAML Token) and POST/Redirect the browser to that Relying Party Trust/Service Provider.

Do note that just because a Relying Party Trust/Service Provider is listed doesn’t automatically mean that they actually DO support IdP Initiated Sign In. Some Service Providers using the SAML Protocol might only accept Service Provider Initiated Sign In.

I’ve hidden this list on my ADFS 2.0 Proxies for un-authenticated users (but not on our ADFS 3.0 WAPs yet).

In ADFS 2.0 edit C:\inetpub\adfs\ls\IdpInitiatedSignOn by adding SetRpListState(null, null);

You can’t disable the page on Windows Server 2012 R2. You can hide the list in JavaScript onload.js:
var checkidp_OtherRpPanel = document.getElementById(‘idp_OtherRpPanel’) ;
if ( checkidp_OtherRpPanel ) {
checkidp_OtherRpPanel.style.display = ‘none’ ;
}

You’ll find the guidance on how to modify the default JavaScript of the page there:

Customizing the ADFS 3.0 Sign-in page:

Credit/Source:

https://social.technet.microsoft.com/Forums/windows/en-US/5f3787ec-a1a6-44de-93ca-12be341506db/relying-party-showing-up-in-idpinitiatedsignonaspx?forum=ADFS

AD 2016 what are the news?

https://adsecurity.org/?p=3646

What’s new in ADFS 2016?

https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/overview/whats-new-active-directory-federation-services-windows-server-2016?f=255&MSPPError=-2147217396

  • Eliminate Passwords from the Extranet
  • Sign in with Azure Multi-factor Authentication
  • Password-less Access from Compliant Devices
  • Sign in with Microsoft Passport
  • Secure Access to Applications
  • Better Sign in experience
  • Manageability and Operational Enhancements

 

You can upgrade an AD FS 2012 R2 farm using the “mixed farm” process described here. It works for WID or SQL farms, though the document shows only the WID scenario. Also another upgrade procedure:

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016

 

ADFS v 3.0 (2012 R2) Migration to ADFS 4.0 (2016) – Part 1

ADFS v 3.0 (2012 R2) Migration to ADFS 4.0 (2016) – Part 2

ADFS v 3.0 (2012 R2) Migration to ADFS 4.0 (2016) – Part 3 – Azure MFA Integration

 

ADFS 2016 operations

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/ad-fs-2016-operations

ADFS 2016 deployment

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/ad-fs-deployment

ADFS 2016 design

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/design/ad-fs-design-guide

To detect lateral movement on Windows infrastructure I recommend to collect the following events:

It’s based on events (4648 + 4672 from member servers, 8004 from DCs) + network traffic (AS/TGS).

Regarding both event 4648 (A logon was attempted using explicit credentials) and event 4672 (Special privileges assigned to new logon):
=> Collect events and send to a SIEM (splunk, logrythm …) or even Windows Event collector (WEF)

Reference:

https://docs.microsoft.com/en-us/windows/threat-protection/use-windows-event-forwarding-to-assist-in-instrusion-detection

https://www.jpcert.or.jp/english/pub/sr/ir_research.html