Following Steve's Question - Re Tokens in SPNEGO

Alexander Bokovoy ab at
Sun May 31 09:21:47 UTC 2020

On la, 30 touko 2020, William Brown wrote:
> > 
> > 
> >> IE think bearer tokens from oauth being passed in that can be
> >> validate, or a saml assertion where you can check as the passdb has a
> >> registered handler.
> > 
> > Right. You wouldn't push SAML assertion or bearer token to PASSDB.
> > Instead, in negoex plugin you would perform mechanism-specific lookup of
> > the details and associate that with the security context in a way
> > expected by higher level GENSEC code in Samba. This is similar to how
> > Kerberos part of GENSEC expects to pull PAC record and parse it further.
> > Or GENSEC's NTLM code extracts security token and parses it further.
> <snip>
> > 
> >> It would be interesting to know how a windows server + windows
> >> desktop, both joined to azure AD conduct their authentication in this
> >> case, since there should be no ntlm or krb involved ....  
> > 
> > They still involve Kerberos, with PKINIT-based authentication using
> > certificates bound to machine TPMs. These certificates are issued and
> > tied into information about those machines in Azure AD. There is a
> > reason why Microsoft Windows logo certification requires TPM from a
> > hardware platform.
> > 
> > See details here for machine enrollment:
> >
> > 
> > and for user provisioning of a two-factor credential:
> >
> > 
> > and for user authentication:
> >
> That's only the hybrid AD + Azure AD case isn't it?

My understanding it is not only for that but this is the only place I
found it described in detail for all types of scenarios.

For non-enrolled clients two use cases of binding external identity to a
local one: authenticating with a cloud auth provider and trusting a user
from a different host are covered with PKU2U which uses NEGOEX:

> > Windows does everything in terms of NT security token that needs to
> > be created for the session setup on Windows side. For Kerberos and NTLM
> > the token's content is based on the content of PAC in Kerberos
> > ticket and security token from NTLM exchange correspondingly. It is
> > then amended with whatever local details are needed in the local security
> > authority (add local groups, for example).
> > 
> > In the user authentication link above you might think there is no
> > Kerberos involved in the first case (Azure AD join authentication to
> > Azure AD) but there an encrypted session key is returned by Azure AD
> > through the cloud AP provider which is then decoded by the cloud
> > authentication security support provider (SSPI module) using the
> > device's transport key.
> <snip>
> > Essentially that online identity is bound to a local account you have
> > and then reuses details from LSA after successful authentication has
> > been done via interactive logon with the help of SSPI extension. In
> > practice then means triggering use of that extension via SPNEGO NEGOEX
> > offer.
> Do you have any documents on the cloud SSP functionality? What details does it reuse?
> It seems like being able to support this extension would be the answer to Steve's question ...

This is just standard Windows SSPI stuff. It is built around using
NEGOEX internally to call out to other providers but in general there is
nothing different to standard SSPI API.

/ Alexander Bokovoy

More information about the samba-technical mailing list