Usually after building an AD FS/WAP farm I test locally from the Internet and the Intranet using (to-date) a fairly reliable source of verification that the service is up and running. I’m referring to, of course, the IdP sign-in page (../adfs/ls/idpinitiatedsignon.aspx). This offers a simple way of validating login via AD FS.
With Windows Server 2016, this page is no longer surfaced “out-of-the-box”.. if you want to do a SAML 2.0 IdP-initiated sign-on, this functionality will need to be enabled. Otherwise, connecting to the obligatory sign-in page, will produce an error similar to the following:
Testing from the Web Application Proxy itself directly, pointing to the AD FS farm, we may see an HTTP 503 Service Not Available error.
Via Powershell, it can be switched back on:
set-adfsproperties -EnableIdpInitiatedSignon $True
Now, before we get too hasty, knowing that we can turn it back on versus actually turning it back on are two different things 🙂 If it’s directly required, IdP-driven sign-on is a feature of your federation setup, then you may have no choice. For example, certain SaaS/Cloud applications simply don’t support SP-initiated workflow.
For some organizations I’ve worked for though, this page is seen as insidious because it reveals the relying parties configured on your AD FS farm anonymously.
AD FS 2.0
AD FS 2012 R2
Going back to AD FS 2.0, customers are often unwilling to float this data anonymously via the sign-in page and want to hide the RP enabled trusts visible on the page, sometimes re-writing the code behind to do so or even hiding it from the browser via obfuscation.
Whatever your view, it’s off by default in Windows Server 2016. Those of a paranoid bent may now breathe …………. in….. out….in… out…. there you go 🙂
2 thoughts on “AD FS – Old Habits (idpinitiatedsignon.aspx)”
I saw your other blog as well and facing a similar issue.
In our case we are using SAP ERP and trying to get rid of this sign in to one of the following sites and want to make it to a fixed site. Even though I read your blog I am quite unsure on what is that you are suggesting us to do. Kindly help tks mate.
I’ve been getting tons of hits to my Debian server with this /adfs/ls/idpinitiatedsignon garbage tacked on the end recently. It would seem that a vulnerability has indeed arisen, and the script kiddies are on it…