The second one enables the use of NTL and V two session security only if it's negotiated.
The next one drops LAN manager and only uses Intel M version one.
The one after that starts to introduce Intel and version two.
However, the domain controller will still accept Elm and Intel in version one authentication.
The next setting starts to completely refuse LAN manager and the most secure settings starts to refuse
LAN Manager and Intel Version one.
Best practices dictate that you should start with a security level of three.
So that would be zero one, two and three.
So the authentication level to start with as you start to enforce in TLM version two is the setting
which is send Intel and V2 response only.
What this does is it enables Intel and V two as default, but still allows a fallback to land manager
in Intel in version one.
Once you configure this, you'll notice that there is a warning which will take you to a microsoft article
which dictates the possible impact of configuring this setting.
Since you need to ensure that Intel and V two is starting to be used as a default, you will accept
this change and allow the setting to be configured.
The next step from here would be to perform auditing again.
And the reason for performing additional auditing is to see which devices are still using land manager
and eliminate them from the environment.
If there are no devices that are using land manager anymore, you can then move to the next level of
four and perform auditing again and pretty much repeat the same process until you get to the most secure
level of five.
And that is when the system refuses.
Land Manager and anti elm.
So what if you wanted to remove anti Elm authentication completely?
Well, the two settings that are defined here under restrict anti elm incoming into elm traffic and
restrict anti elm and TLM authentication in this domain is what you could configure to completely stop
into Elm.
But again, a word of caution is to make sure that you have audited the environment to ensure that your
devices can support another authentication protocol such as Kerberos instead of 90 Elm.
These settings are extremely powerful and if they are configured incorrectly, you could pretty much
break your environment and have endless issues with devices that do not authenticate.
So best practice is to make sure that you perform a deep level of auditing to ensure that you have a
clear picture of any impacted devices as you define the settings for restricting anti elm.