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

 

Advertisements

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

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 for WEF and event forwarding:

Deploying WinRM using Group Policy: http://www.vkernel.ro/blog/how-to-enable-winrm-http-via-group-policy

Microsoft official document well documented:

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

Detecting Lateral movement using Event logs:

http://blog.jpcert.or.jp/.s/2017/12/research-report-released-detecting-lateral-movement-through-tracking-event-logs-version-2.html

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

Fresh How-to from Intrusion detection perspective:

https://medium.com/@palantir/windows-event-forwarding-for-network-defense-cb208d5ff86f

How-to easy to follow from Intrusion detection perspective:

https://www.root9b.com/sites/default/files/whitepapers/R9B_blog_005_whitepaper_01.pdf

https://joshuadlewis.blogspot.fr/2014/10/advanced-threat-detection-with-sysmon_74.html same than previous one but more appendix

From Intrusion detection perspective:

https://hackernoon.com/the-windows-event-forwarding-survival-guide-2010db7a68c4 help to manage error of WEF deployment

 

ANSSI AD control paths:

https://github.com/ANSSI-FR/AD-control-paths

Lucas Bouillot, Emmanuel Gras – ANSSI – 2014 Presented at the French conference SSTIC-2014. Slides and paper can be found here: https://www.sstic.org/2014/presentation/chemins_de_controle_active_directory/.