Following Steve's Question - Re Tokens in SPNEGO

[William Brown]

> 
> 
>> 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:
> https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration
> 
> and for user provisioning of a two-factor credential:
> https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning
> 
> and for user authentication:
> https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication

That's only the hybrid AD + Azure AD case isn't it?

> 
> 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 ...

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs