1
00:00:03,060 --> 00:00:08,010
The second one enables the use of NTL and V two session security only if it's negotiated.

2
00:00:08,880 --> 00:00:12,810
The next one drops LAN manager and only uses Intel M version one.

3
00:00:13,650 --> 00:00:16,710
The one after that starts to introduce Intel and version two.

4
00:00:16,830 --> 00:00:21,810
However, the domain controller will still accept Elm and Intel in version one authentication.

5
00:00:22,650 --> 00:00:29,040
The next setting starts to completely refuse LAN manager and the most secure settings starts to refuse

6
00:00:29,040 --> 00:00:31,140
LAN Manager and Intel Version one.

7
00:00:32,000 --> 00:00:35,650
Best practices dictate that you should start with a security level of three.

8
00:00:35,660 --> 00:00:38,450
So that would be zero one, two and three.

9
00:00:39,350 --> 00:00:44,360
So the authentication level to start with as you start to enforce in TLM version two is the setting

10
00:00:44,480 --> 00:00:46,910
which is send Intel and V2 response only.

11
00:00:47,780 --> 00:00:53,330
What this does is it enables Intel and V two as default, but still allows a fallback to land manager

12
00:00:53,330 --> 00:00:54,620
in Intel in version one.

13
00:00:55,460 --> 00:01:00,410
Once you configure this, you'll notice that there is a warning which will take you to a microsoft article

14
00:01:00,410 --> 00:01:03,740
which dictates the possible impact of configuring this setting.

15
00:01:04,610 --> 00:01:09,290
Since you need to ensure that Intel and V two is starting to be used as a default, you will accept

16
00:01:09,290 --> 00:01:11,600
this change and allow the setting to be configured.

17
00:01:12,470 --> 00:01:15,410
The next step from here would be to perform auditing again.

18
00:01:16,220 --> 00:01:21,380
And the reason for performing additional auditing is to see which devices are still using land manager

19
00:01:21,380 --> 00:01:23,210
and eliminate them from the environment.

20
00:01:24,080 --> 00:01:28,640
If there are no devices that are using land manager anymore, you can then move to the next level of

21
00:01:28,640 --> 00:01:33,470
four and perform auditing again and pretty much repeat the same process until you get to the most secure

22
00:01:33,470 --> 00:01:34,310
level of five.

23
00:01:35,150 --> 00:01:36,980
And that is when the system refuses.

24
00:01:36,980 --> 00:01:38,750
Land Manager and anti elm.

25
00:01:39,620 --> 00:01:43,310
So what if you wanted to remove anti Elm authentication completely?

26
00:01:44,180 --> 00:01:49,490
Well, the two settings that are defined here under restrict anti elm incoming into elm traffic and

27
00:01:49,490 --> 00:01:54,920
restrict anti elm and TLM authentication in this domain is what you could configure to completely stop

28
00:01:54,920 --> 00:01:55,580
into Elm.

29
00:01:56,420 --> 00:02:01,070
But again, a word of caution is to make sure that you have audited the environment to ensure that your

30
00:02:01,070 --> 00:02:06,380
devices can support another authentication protocol such as Kerberos instead of 90 Elm.

31
00:02:07,250 --> 00:02:11,750
These settings are extremely powerful and if they are configured incorrectly, you could pretty much

32
00:02:11,750 --> 00:02:15,800
break your environment and have endless issues with devices that do not authenticate.

33
00:02:16,670 --> 00:02:21,080
So best practice is to make sure that you perform a deep level of auditing to ensure that you have a

34
00:02:21,080 --> 00:02:25,760
clear picture of any impacted devices as you define the settings for restricting anti elm.