Yesterday, we discussed WorkPlace Join and the msDS-Device object. Over the past months, these technologies sparked conversations with several people, some of which have very strong opinions on the exclusivity of domain join and a passion for loosely-coupling devices to Active Directory.

This conversation could best be titled WorkPlace Join versus Domain Join.

I’ll use this blogpost to express my opinion.

Trusted and untrusted networks

Domain Join conforms to the old client-server model where clients reside on the same network as the servers and this internal network is trusted. Protocols like LDAP, NetBIOS and Kerberos are suitable for this type of network. For this type of network, domain join offers single sign-on, based on available authentication modules in LSASS. (NTLM, Kerberos)

Nowadays, clients wander off these internal networks. For years, we’ve expanded these internal networks through VPNs. More recently, we’ve used more advanced tunneling scenarios like DirectAccess. All these scenarios expand the ‘trusted’ network to allow for ‘trusted’ protocols like Kerberos.

The right protocol for the right network

The Internet, of course, is an untrusted network. Kerberos and LDAP have no reason to exist there, nor did the people behind these protocols envision untrusted networks. For these networks, we need protocols designed specifically for them: SAML, Oauth, OpenID Connect. All working on the universal firewall bypass ports TCP80 and TCP443.

ADFS makes the distinction between Intranet and Extranet in its Authentication Policies. (unless you screw it up…) By default, An ADFS Server allows for Kerberos on the Intranet (trusted network), but not on the Extranet (the Internet). Through LSASS, clients on the intranet (the trusted network) that are domain-joined (and logged onto with a domain account and the client has no more than 5 minutes time difference with the DC and the ADFS Server) have single sign-on without re-authentication (commonly known as silent single sign-on) to ADFS-enabled resources: The ADFS server acts as the STS and transforms the Kerberos token into SAML/OAuth tickets.

WorkPlace Join and Domain Join

On the Extranet, an ADFS servers presents forms-based authentication. People on clients on the Internet, therefore, will need to authenticate per (browser) session. To make this experience smoother for them, you can Workplace Join these machines to achieve single sign-on (SSO) beyond the session through the cookie/certificate.

When all applications that need to be accessible from clients both from the Intranet and Extranet allow for claims, the need for expanding the trusted network – provide VPN access, DirectAccess – goes away. The Web Application Proxy can help there…

With WorkPlace Join and Domain Join combined on a device for an Active Directory-based user account, a dual protocol stack emerges, supporting both Identity 1.0 (Kerberos) and Identity 2.0 (SAML, OAuth, OpenID Connect).

Concluding

In my opinion, WorkPlace Join and Domain Join are complementary.

Hat tip

I’d like to thank Sean Deuby for helping me articulate my opinion.