1 00:00:03,020 --> 00:00:08,810 If you watched the previous version of this course on ADF's 2016, then you saw that a major theme of 2 00:00:08,810 --> 00:00:13,580 that release was providing authentication methods that didn't require a user to enter their password 3 00:00:13,580 --> 00:00:14,720 for primary login. 4 00:00:15,560 --> 00:00:22,520 A big advancement in ADF's 2016 was the ability to use Azure multifactor authentication for primary 5 00:00:22,520 --> 00:00:23,450 authentication. 6 00:00:23,480 --> 00:00:30,980 Actually the token code generated on the Microsoft Authenticator app on a user's device prior to ADF's 7 00:00:30,980 --> 00:00:32,220 2016. 8 00:00:32,270 --> 00:00:37,880 You could use Azure MFA for second factor authentication, but not for primary authentication. 9 00:00:38,720 --> 00:00:45,800 ADF's 2019 goes farther by adding the ability to use third party non Microsoft authentication providers 10 00:00:45,800 --> 00:00:47,480 for primary authentication. 11 00:00:48,320 --> 00:00:55,160 ADF's previously had the ability to allow non Microsoft MFA providers to plug into ADF FFS and provide 12 00:00:55,160 --> 00:00:58,640 the second factor in a multi-factor authentication scenario. 13 00:00:59,480 --> 00:01:03,080 But now they can be used for primary authentication also. 14 00:01:03,920 --> 00:01:06,230 And as of ADF's 2019. 15 00:01:06,260 --> 00:01:12,020 You can now configure ADF to have the user enter their password as the second factor of authentication 16 00:01:12,020 --> 00:01:18,130 after the user authenticates in some other way, like one of those MFA providers or Azure MFA or a certificate 17 00:01:18,140 --> 00:01:19,760 or Windows Hello for business. 18 00:01:20,690 --> 00:01:26,000 So this is all part of Microsoft's effort to eliminate passwords altogether, or at least protect them 19 00:01:26,000 --> 00:01:31,070 as much as possible by having some guarantee of who the user is before it's possible to even enter a 20 00:01:31,070 --> 00:01:31,670 password. 21 00:01:32,570 --> 00:01:38,180 You have more control over the claims rule engine in this release of PDFs with the introduction of a 22 00:01:38,180 --> 00:01:39,950 pluggable risk assessment model. 23 00:01:40,860 --> 00:01:45,930 You can run your own code at different stages of the claims pipeline, like when the user first accesses 24 00:01:45,930 --> 00:01:46,770 EDF's. 25 00:01:47,010 --> 00:01:50,700 Maybe you want to compare their IP address to a list of risky apps. 26 00:01:51,600 --> 00:01:56,700 Then you can run custom code before and after they authenticate and either stop the process or issue 27 00:01:56,700 --> 00:02:00,210 a risk assessment score for the rest of the claims pipeline to use. 28 00:02:01,130 --> 00:02:06,860 There are some improvements to the extra net lockout functionality that's existed with ad FS since Windows 29 00:02:06,860 --> 00:02:13,790 Server 2012 or to extra net lockout prevents users from getting locked out on the internet when too 30 00:02:13,790 --> 00:02:18,680 many failed attempts are made from the extra net, possibly as part of an attack of some sort. 31 00:02:19,610 --> 00:02:24,860 You can now set different thresholds for lockout depending on whether the user is coming from a familiar 32 00:02:24,860 --> 00:02:27,080 location or from an unknown location. 33 00:02:27,950 --> 00:02:34,490 You can now customise HTTP headers sent from DFS, which can be used for things like cross origin resource 34 00:02:34,490 --> 00:02:38,930 sharing, but it's also a flexible framework that lets you send any custom header. 35 00:02:39,830 --> 00:02:45,590 You can specify the second factor of authentication at the relying party trust level so you're not confined 36 00:02:45,590 --> 00:02:50,030 to using one single provider for all the applications and relying party trusts. 37 00:02:50,930 --> 00:02:56,450 If you're using the ADF's sign in page, you can now configure it to look like the standard Azure login 38 00:02:56,450 --> 00:03:01,550 screen with multiple pages for username and password, as well as being centered in the middle of the 39 00:03:01,550 --> 00:03:02,090 browser. 40 00:03:02,990 --> 00:03:06,290 There are some improvements for applications that use both. 41 00:03:07,220 --> 00:03:12,590 There's a new device flow profile for authenticating devices that don't have a user interface, so you 42 00:03:12,590 --> 00:03:14,990 can do the authentication on another device. 43 00:03:15,900 --> 00:03:21,780 There's also support for the authorization code flow with proof key for code exchange or PKC for short, 44 00:03:21,960 --> 00:03:27,450 which is a security standard in OAuth, which introduces a secret created by the calling application 45 00:03:27,450 --> 00:03:30,090 that can be verified by the authorization server. 46 00:03:30,990 --> 00:03:36,420 There are other new capabilities in ADF's also, but those are some of the major ones and you'll be 47 00:03:36,420 --> 00:03:39,390 seeing examples of many of these as we move through the course. 48 00:03:40,320 --> 00:03:45,900 So next, let's talk about the lab environment that I'm using before we install ADF's in a brand new 49 00:03:45,900 --> 00:03:48,480 Windows Server 2019 environment.