Skip to main content
Jackchenwork
Jackchenwork
Visitor III
December 9, 2021
Question

FortiAuthenticator PEAP(MSCHAP-V2): Is it Kerberos or NTLM?

  • December 9, 2021
  • 2 replies
  • 6847 views

I am doing some reading about Fortiauthenticator and PEAP in Windows AD environment and I would like to understand how it works.

 

There are some confusing statement from Fortinet.  In their NSE training site Secure Access 6.4 :01 LDAP and RADIUS, section 43:

Jackchenwork_0-1639054695951.png

It says using Kerberos to proxy password hash, which doesn't sound right. My understanding is for Kerberos to work, the client need to be able to reach a KDC, which is not possible before the client is authenticated. 

 

https://docs.fortinet.com/document/fortiauthenticator/6.4.0/administration-guide/416152/policies#Windows_AD_Domain_Authentication

says: "When enabled, authentication is performed using NTLM once the FortiAuthenticator has joined the AD domain, replacing the default LDAP authentication process. "

 

NTLM make better sense than Kerberos for the actual user authentication process. 

 

I also found some discussions for MS-CHAPv2 and Kerberos/NTLM:

https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=23108

"There is no way to run the actual MS-CHAPv2 authentication with Kerberos, as NTLM is the only defined authentication scheme in MS-CHAPv2."

 

 

 

    2 replies

    xsilver_FTNT
    Staff
    xsilver_FTNT
    Staff
    April 14, 2022

    Hello,

     

    "My understanding is for Kerberos to work, the client need to be able to reach a KDC, which is not possible before the client is authenticated."
    That's correct.

    But RADIUS documentation you are pointing out refer to Windows AD domain authentication in RADIUS policy. That can be achieved, enabled, for realm which is LDAP based, and if that LDAP from "Remote Auth. Servers" does have "Windows Active Directory Domain  Authentication" enabled and set properly.
    Because that setting will form/cause "domain join" and therefore FortiAuthenticator becomes domain member unit. And as such it then can authenticate users, similarly to Windows PC joined to domain. Difference is in fact that PC would get plaintext password from logon screen. While FortiAuthenticator will not get that in plain text, but thanks to MSCHAPv2 (not mandatory for PEAP, BTW) it can get that via RADIUS from NAS and user. But such password will be already encrypted (CHAP) and passed in RC4 form, however FortiAuthenticator being domain member can fake that encryption being done on his side by proxying acquired RC4 form of password to AD. Kerberos is then (preferably) used to process logon exchange.
    For Negotiate auth it is possible (unless disabled by GPO policy on AD side) to fallback to NTLM. The main difference is length of such tokens and their starting prefix. NTLM based64 token always begin with "TlR" while Kerberos starts as "YII" and is significantly longer.

     

    More on Windows auth can be found there:
    https://docs.microsoft.com/en-us/windows-server/security/windows-authentication/windows-authentication-overview

    Debbie_FTNT
    Staff & Editor
    Debbie_FTNT
    Staff & Editor
    April 14, 2022

    Hey Jakchenwork,

    to elaborate a bit on Tom xSilver's update and what exactly is going on (I'm paraphrasing a colleague with a lot of experience with FortiAuthenticator and all the gritty details of domain authentication):
    - you are correct, the MS-CHAPv2 challenge is forwarded to the domain controller via NTLM

    - For FortiAuthenticator to be able to set up SMB and NTLM, it needs to be joined to the domain

    -> this domain join authentication happens via Kerberos

    -> a Kerberos ticket is used to establish an SMB session, which then is used for the actual NTLM traffic

      Terms & ConditionsAccessibility statement