2 ms·

Normal Kerberos. For SSO NTLM was a fallback with no SSO power only.

• cryptonector 3y ago
  For the line of sight issues that Kerberos doesn't normally deal with MSFT is adding an implementation of IAKERB, which is a Kerberos-related protocol by which an application server can proxy messages between the client and the Kerberos KDCs on behalf of the client.
  • bodeadly 3y ago
    The blog article doesn't actually say the IAKERB impl will proxy to KDCs. Strangely it is entirely specific to Windows 11 and by extension Windows clients. There is no mention of Windows Server. So it's not crystal clear to me that the implementation will be able to authenticate domain accounts. Maybe it will only authenticate against the "LocalKDC" on top of the local SAM just to work around the issue of being able to log into a machine without line-of-site to a KDC (or NTLM or VM console) and nothing more.
    • cryptonector 3y ago
      > The blog article doesn't actually say the IAKERB impl will proxy to KDCs. But that's all IAKERB does. There's two use cases here: proxying to the local, SAM-backed KDC for workgroup mode authen., and proxying to domain controller KDCs for RDP and RAS and what not where the [K]DCs are not reachable directly by the client. (There's a third use case that they don't currently seem to intend to support, which is when you try to authenticate to a Windows system by IP instead of by name. In that case they could extend IAKERB to use the Microsoft user-to-user Kerberos protocol to discover the server's name.) > Strangely it is entirely specific to Windows 11 and by extension Windows clients. There is no mention of Windows Server. Steve Syfuhs addressed this on twitter: there's only one Windows now, so there's no need to mention "Windows Server" because "Windows Server" == Windows.