Turn off NTLM in ISE, Use Kerberos instead.

[GeorgePerkins0204]

I cannot find documentation or blogs or tips where I turn off NTLM authentication in ISE. Like the original post, we are a customer that needs to turn off NTLM on all domain devices and users. Audit of NTLM group policy settings are enabled to find all sources of NTLM authentication in the domain. I see ISE continuously using NTLM for user and device lookup in AD.

I use ISE Administration > Identity Management > External Identity Sources > Connection > select ISE node > Test User 

There are three Authentication Type options in the Test User dialog: Kerberos, Lookup, MS-RPC. When I test each type they all work, returning expected results. Only the MS-RPC authentication type logs an NTLM audit record. The question then becomes, how do I disable MS-RPC lookups in ISE and require ISE to use only Kerberos?

Log Name: Microsoft-Windows-NTLM/Operational
Source: Microsoft-Windows-Security-Netlogon
Date: 1/12/2024 10:01:59 AM
Event ID: 8004
Task Category: Auditing NTLM
Level: Information
Keywords:
User: SYSTEM
Computer: GHCDC003.corp.blur.com
Description:
Domain Controller Blocked Audit: Audit NTLM authentication to this domain controller.
Secure Channel name: ONSNS3615ISE
User name: gperkins@corp.blur.com
Domain name: NULL
Workstation name: \\ONSNS3615ISE
Secure Channel type: 2
Audit NTLM authentication requests within the domain NULL that would be blocked if the security policy Network Security: Restrict NTLM: NTLM authentication in this domain is set to any of the Deny options.
If you want to allow NTLM authentication requests in the domain NULL, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Disabled.
If you want to allow NTLM authentication requests to specific servers in the domain NULL, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Deny for domain servers or Deny domain accounts to domain servers, and then set the security policy Network Security: Restrict NTLM: Add server exceptions in this domain to define a list of servers in the domain NULL to which clients are allowed to use NTLM authentication.
Event Xml:
<Event xmlns=http://schemas.microsoft.com/win/2004/08/events/event>
<System>
<Provider Name="Microsoft-Windows-Security-Netlogon" Guid="{e5ba83f6-07d0-46b1-8bc7-7e669a1d31dc}" />
<EventID>8004</EventID>
<Version>0</Version>
<Level>4</Level>
<Task>2</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2024-01-12T16:01:59.8876250Z" />
<EventRecordID>8663101</EventRecordID>
<Correlation ActivityID="{91cb7c06-3883-0001-a87c-cb918338da01}" />
<Execution ProcessID="768" ThreadID="1440" />
<Channel>Microsoft-Windows-NTLM/Operational</Channel>
<Computer>GHCDC003.corp.blur.com</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="SChannelName">ONSNS3615ISE</Data>
<Data Name="UserName">gperkins@corp.blur.com</Data>
<Data Name="DomainName">NULL</Data>
<Data Name="WorkstationName">\\ONSNS3615ISE</Data>
<Data Name="SChannelType">2</Data>
</EventData>
</Event>

Originally a reply in thread ISE and Kerberos Only Q&A, but that thread is closed, so starting a new Q&A. Thanks.

[Arne Bier]

Out of curiosity, why are you asked to disable NTLM on all domain devices ? 

All the reading I have done around this topic suggests that if password checking is involved (e.g. EAP-PEAP) which is more complex than PAP, then NTLM is required. But I guess in an environment using only EAP-TLS, there are no password checks required. So in theory we could get away with not needed NTLM for those types of auths. My first thought would be then, why join AD at all? You could use LDAP instead and retrieve your AD Groups that way - I haven't thought it through all the way, but I think it might do the job. Then you could remove the AD Join config entirely.

But if you also used AD Join to log into your ISE Admin GUI, I would assume that uses NTLM to validate your password during the login to ISE Admin Portal (I can't recall whether you can use LDAP instead).

When I tried to be clever some years ago, I proposed to a customer to use LDAP for many things - and back then they were using EAP-PEAP a lot. Of course, with LDAP, the complex password checking required for an EAP-PEAP transaction is not supported (because it's a challenged handshake, instead of a simple static password looking in the LDAP directory) - so, I think bottom line, if you are doing more than PAP password checking, then you're forced to use a protocol smart enough to handle it - and NTLM seems to be the glue. I don't know of anything that current supersedes this, at least for our traditional on-prem AD deployments. 

[GeorgePerkins0204]

I believe there is some confusion here on what I'm asking for.

1. We can use LDAP or an IDP or local accounts for logging into the ISE admin portal (for network and security admins to login and manage ISE or use ISE reports, etc.) and avoid NTLM. This is not the question.

2. For clients which lack supplicant support (dumb devices like printers, cameras, etc.) that device's MAC is managed in ISE for network access without an authentication (thus, no NTLM for these type of devices either). This is not the question.

3. The question is (what I'm asking for):  How do I disable NTLM for all enterprise Microsoft (computer and user) client authentication during the client's supplicant 802.3 + 802.1x negotiation for ISE permission to access the network? 

Digging into this question I've got some theories, but no documentation from Cisco. My speculation is that because the Microsoft supplicant (configurred using group policy) is using MSCHAPv2 in the PEAP tunnel to get ISE to learn the supplicant's identity (authentication) and then query Active Directory for group membership (access) and recording the transaction for reporting (accounting): AAA.

I have found some statements in blogs and other unofficial sources, that seems like MSCHAPv2 has a requirement of NTLM. 

So the 802.1x supplicant therefore would need to use something other than MSCHAPv2 and here is where I'm asking Cisco, what are my options to require Kerberos?

[Arne Bier]

Thanks, that makes more sense to me now.

I hope I read your response right. When I see PEAP and MSCHAPv2 I have to wonder though, if you have considered using EAP-TLS (certificate-based authentication) instead? I believe that with Windows Credential Guard, EAP-PEAP will become somewhat harder to implement, because MSoft is also trying to stop us using username/password auth on the network. Although EAP-PEAP MSCHAPv2 is super easy and handy to implement (no requirement to issue client certs ... a hurdle too high to climb for some folks). 

EAP-TLS is the answer - even if you just use GPO to push a computer cert to all AD joined Windows assets - and make the supplicant EAP-TLS Computer Authentication.  Next better thing for Windows 10 (20H2 and upwards) is EAP-TEAP - EAP chaining. Just try avoiding MSCHAPv2, and use certs instead. You can still check your AD Groups by binding ISE to the DC using LDAP.

Lastly, just spit-balling here ... there is EAP-TTLS - the outer method makes a secure tunnel for the inner method to be something as simple as PAP. This is what is used for ISE to talk to MS Azure AD (Entra ID) - the user creds are passed as simple creds in the secure TLS tunnel.  I wonder if you can put EAP-TTLS to your Windows supplicants - but I can't recall if Windows supports EAP-TTLS in its native supplicant.

[GeorgePerkins0204]

You are confirming what I think I have surmised in my readings elsewhere. But I'm afraid it is mostly alphabet soup to me. Which is why I had hoped Cisco could provide a document, white paper, KB, -=something=- that explains this in sufficient detail to avoid the "try that [fail], try this [fail], try again [success]" approach to late-night configuration changes on a live production network.  

Here are the last two PEAP properties pages in the Microsoft group policy settings for 802.3 802.1x supplicant that would be great to have a Cook Book to show us alphabet soup averse to get this right the first time:

[Arne Bier · Accepted solution]

Yeah - alphabet soup indeed. But if you're dealing with this level of networking security you just have to learn these things and get over the pain barrier a bit.

802.1X is a complex beast. But to break it down simple, here are the actors involved:

• Supplicant - piece of software that runs on a computer that communicates on the Wi-Fi/LAN and speaks EAP protocol - this protocol has nothing to do with TCP/IP - it happens on layer 2 before IP is even a thing. 
• Authenticator - the switch/WLC that accepts or sends the EAP traffic - think of it as the traffic cop that controls access to the network - the traffic cop is a bit dumb though - it just passes the message on to the brains (ISE) via the RADIUS protocol.
• Authenticating Server - e.g. ISE - this entity gets the RADIUS packet, decodes the EAP inside and processes/responds to the supplicant. 

So far so good, I hope.  Supplicant is an industry term. You are using EAP-PEAP (MSCHAPv2) from the screenshots provided. This is perhaps the Windows default option, and it uses username/password for network authentication. When your PC boots up, it will send the computer name and some internal password that you have no access to. AD knows these credentials and checks them for you. EAP-PEAP is frowned upon and soon may be a thing of the past with Microsoft's Credential Guard.  

The industry standard terms is also EAP-TLS for what Microsoft calls "Smart Card or other certificate" - if you select that option in the Windows supplicant, then you're telling the PC to do EAP-TLS when the PC boots up or if a user logs out.  You can put computer certs on your AD domain joined PCs via Group Policy auto-enrol - if done correctly, it's a no brainer. Microsoft has this down to a fine art.  Once all your PC's have a computer cert, you can use GPO once again, to flip your supplicants from using EAP-PEAP to using EAP-TLS ... sorry "Smart Card or Other Certificate". 

This stuff has been discussed on this forum and other internet forums since the dawn of time. And Cisco published many different articles, but my google foo is hopeless. If you feel overwhelmed by this topic, rest assured. So is the rest of the world. But there is help on hand. www.labminutes.com- I can't stress this enough - the guy's is a legend with all the videos he's published for free. Check out his ISE series on how to implement 802.1X on wired and wireless Cisco gear - step by step.  

[Arne Bier]

I forgot to add a link to the December 2023 Cisco Live presentation from Thomas Howard (Cisco TME) who gave a brilliant talk about ISE and I think you'll like it.

ISE Deployment Staging and Planning - BRKSEC-2705 on Cisco Live On-Demand

There is a presentation to download - but watch the video!

His stuff is also on Youtube - ISE channel on Youtube.

[GeorgePerkins0204]

Link directly to BRKSEC-2705

[GeorgePerkins0204]

>>> Out of curiosity, why are you asked to disable NTLM on all domain devices? <<<

NTLM is vulnerable to man-in-the-middle attacks (among other issues) and is widely understood to be insecure. Auditors require plans to decommission its use. Microsoft's direction to all of its customers has been for many years to work to eliminate it. Kerberos is the default authentication method since Windows 2008 with NTLMv2 as a fall back. Kerberos is an open standard. NTLM is proprietary. Kerberos is a higher-performing less-chatty protocol. NTLMv2 is a technology created in 2000, an enhancement to NTLMv1 created in 1993; ancient history. I could go on.