"Anonymous Logon" vs "NTLM V1" What to disable?

Question

Working on getting rid of NTLM V1 logins all together in the AD environment; found lot of events, almost all of them from the user "Anonymous Logon"(4624 events) other 1(4624 events) percent coming from some users. So, here I have some questions.

• Is it better to disable "anonymous logon" (via GPO security settings) or to block "NTLM V1" connections? what are the risks going for either or both? These logon events are mostly coming from other Microsoft member servers.
• Does Anonymous logon use "NTLM V1" 100 % of the time? i.e if I see a anonymous logon, can I assume its definitely using NTLM V1?
• What exactly is the difference between anonymous logon events 540 and 4624? -> Note: Functional level is 2008 R2

Please let me know if any additional info required.

Solution

The question you posed, "Is it better to disable "anonymous logon" (via GPO security settings) or to block "NTLM V1", is not a very good question, because those two things are not mutually exclusive. You can do both, neither, or just one, and to various degrees. There are lots of shades of grey here and you can't condense it to black & white.

Disabling NTLMv1 is generally a good idea. It is done with the LmCompatibilityLevel registry setting, or via Group Policy. Beware that the same setting has slightly different behavior depending on whether the machine is a domain controller or a domain member.

http://technet.microsoft.com/en-us/library/cc960646.aspx

The potential risk in disabling NTLMv1 here is breaking backwards compatibility with very old Windows clients, and more likely with non-Microsoft clients that don't speak NTLMv2. You would have to test those. Any reasonably modern and patched version of Windows will handle NTLMv2 w/ Session Security with zero problems (we're talking like anything Server 2000 or better.)

Disabling anonymous logon is a different thing altogether. You can disable the ability of anonymous users to enumerate shares, SAM accounts, registry keys, all or none of those things or a combination. The more you restrict Anonymous logon, you hypothetically increase your security posture, while you lose ease of use and convenience. (e.g. your users could lose the ability to enumerate file or printer shares on a server, etc.)

So you can't really say which one is better. They are both two different mechanisms that do two totally different things.

Event 540 is specific to a "Network" logon, such as a user connecting to a shared folder or printer over the netwok. It's also a Win 2003-style event ID. You can tell because it's only 3 digits. Corresponding events in Vista/2008 were converted to 4-digit IDs:

Eric Fitzgerald said: I've written twice (here and here) about the relationship between the "old" event IDs (5xx-6xx) in WS03 and earlier versions of Windows, and between the "new" security event IDs (4xxx-5xxx) in Vista and beyond.

In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security events in WS03.

The exceptions are the logon events. The logon success events (540, 528) were collapsed into a single event 4624 (=528 + 4096). The logon failure events (529-537, 539) were collapsed into a single event 4625 (=529+4096).

Other than that, there are cases where old events were deprecated (IPsec IIRC), and there are cases where new events were added (DS Change). These are all new instrumentation and there is no “mapping” possible- e.g. the new DS Change audit events are complementary to the old DS Access events; they record something different than the old events so you can’t say that the old event xxx = the new event yyy because they aren’t equivalent. The old event means one thing and the new event means another thing; they represent different points of instrumentation in the OS, not just formatting changes in the event representation in the log.

Of course I explained earlier why we renumbered the events, and (in the same place) why the difference is "+4096" instead of something more human-friendly like "+1000". The bottom line is that the event schema is different, so by changing the event IDs (and not re-using any), we force existing automation to be updated rather than just misinterpreting events when the automation doesn't know the version of Windows that produced the event. We realized it would be painful but it is nowhere near as painful as if every event consumer had to be aware of, and have special casing for, pre-Vista events and post-Vista events with the same IDs but different schema.

So if you happen to know the pre-Vista security events, then you can quickly translate your existing knowledge to Vista by adding 4000, adding 100, and subtracting 4. You can do this in your head.

However if you're trying to implement some automation, you should avoid trying to make a chart with "=Vista" columns of event ID numbers, because this will likely result in mis-parsing one set of events, and because you'll find it frustrating that there is not a 1:1 mapping (and in some cases no mapping at all).

Eric

http://blogs.msdn.com/b/ericfitz/archive/2009/06/10/mapping-pre-vista-security-event-ids-to-security-event-ids-in-vista.aspx

Comments

[Darktux]

I think i have most of my question answered, will the checking the answer. One more clarification, instead of applying a domain wide GPO settings, can this be implemented on the OU's containing the servers which send the NTLM V1 requests to domain controllers and it would work the same way?

[Ryan Ries]

Yes - you can define the LmCompatibilitySetting level per OU. You might see it in the Group Policy Management Editor as "Network Security: LAN Manager authentication level." The setting in the Default Domain Controllers policy would take precedence on the DCs over the setting defined in the Default Domain Policy. Read the text in the "Explain" tab for the best possible explanation on how the same setting behaves differently on DCs vs domain members.