If you watched the previous version of this course on ADF's 2016, then you saw that a major theme of
that release was providing authentication methods that didn't require a user to enter their password
for primary login.
A big advancement in ADF's 2016 was the ability to use Azure multifactor authentication for primary
authentication.
Actually the token code generated on the Microsoft Authenticator app on a user's device prior to ADF's
2016.
You could use Azure MFA for second factor authentication, but not for primary authentication.
ADF's 2019 goes farther by adding the ability to use third party non Microsoft authentication providers
for primary authentication.
ADF's previously had the ability to allow non Microsoft MFA providers to plug into ADF FFS and provide
the second factor in a multi-factor authentication scenario.
But now they can be used for primary authentication also.
And as of ADF's 2019.
You can now configure ADF to have the user enter their password as the second factor of authentication
after the user authenticates in some other way, like one of those MFA providers or Azure MFA or a certificate
or Windows Hello for business.
So this is all part of Microsoft's effort to eliminate passwords altogether, or at least protect them
as much as possible by having some guarantee of who the user is before it's possible to even enter a
password.
You have more control over the claims rule engine in this release of PDFs with the introduction of a
pluggable risk assessment model.
You can run your own code at different stages of the claims pipeline, like when the user first accesses
EDF's.
Maybe you want to compare their IP address to a list of risky apps.
Then you can run custom code before and after they authenticate and either stop the process or issue
a risk assessment score for the rest of the claims pipeline to use.
There are some improvements to the extra net lockout functionality that's existed with ad FS since Windows
Server 2012 or to extra net lockout prevents users from getting locked out on the internet when too
many failed attempts are made from the extra net, possibly as part of an attack of some sort.
You can now set different thresholds for lockout depending on whether the user is coming from a familiar
location or from an unknown location.
You can now customise HTTP headers sent from DFS, which can be used for things like cross origin resource
sharing, but it's also a flexible framework that lets you send any custom header.
You can specify the second factor of authentication at the relying party trust level so you're not confined
to using one single provider for all the applications and relying party trusts.
If you're using the ADF's sign in page, you can now configure it to look like the standard Azure login
screen with multiple pages for username and password, as well as being centered in the middle of the
browser.
There are some improvements for applications that use both.
There's a new device flow profile for authenticating devices that don't have a user interface, so you
can do the authentication on another device.
There's also support for the authorization code flow with proof key for code exchange or PKC for short,
which is a security standard in OAuth, which introduces a secret created by the calling application
that can be verified by the authorization server.
There are other new capabilities in ADF's also, but those are some of the major ones and you'll be
seeing examples of many of these as we move through the course.
So next, let's talk about the lab environment that I'm using before we install ADF's in a brand new
Windows Server 2019 environment.