IT Connect
Information technology tools and resources at the UW

‘NETID DCs ready for cloud’ analysis

This page provides analysis related to ‘NETID DCs ready for cloud’. This page summarizes details found in the appendices, whose sections you can see listed in the table below.

Current State

At this time, a VPN solution is recommended for customers with a cloud-based use case that requires connecting to a NETID domain controller. This recommendation is not clearly documented.

There are many protocols used to connect to a domain controller:

  • Kerberos or NTLM for authentication
  • LDAP or LDAPS for directory operations
  • SMB for group policy and DFS
  • DNS for DDNS registration & resolution

More details about our current requirements for these protocols are documented here:

Problem Statement

UW customers are adopting cloud-based solutions in growing numbers. Some of their use cases depend on connecting to a NETID domain controller, but customers struggle with implementing their own VPN for these use cases.

NETID domain controllers are on a private network for security and usability reasons. Finding a solution which permits cloud-based use cases but doesn’t compromise the security and usability is desired.

Representative use cases:

  1. Software-as-a-Service (SaaS) app which uses LDAP for integration, e.g. an app hosted off UW network which wants UW identity integration via LDAP
  2. Product design requires AD join, but not necessarily directly to NETID, e.g. SQL server hosted in cloud
  3. Product design requires that computer must be joined to NETID, e.g. Microsoft Infrastructure’s ADFS servers/AD-CS servers/AIP connector servers

Additionally, UW’s CTO is interested in determining whether there are certain services that can not be moved to public networks to enable cloud-ready architectures (and why).

Possible Solutions

More detail about the possible solutions is found in the appendices.

Table 1 – Possible solutions and the problem class they address

1: LDAP only
2: Domain join
3: NETID join
a: DCs on internet X X X
b: Site-to-site (S2S) VPN(s) X X X
c: Bridgehead DCs X X X
d: Azure AD Domain Services (AAD-DS) X X
e: Federated or hybrid authentication ? ? ?
f: Forest trust model ?1
g: AD Lightweight Directory Services (AD-LDS) on internet X
h: IPv6 global addresses for DCs X X X
i: Virtual directory on internet X

Table 2 – Traits of potential solutions

Independently possible
a: DCs on internet No No Yes No2 No
b: S2S VPNs Yes3 No Yes Yes Yes
c: Bridgehead DCs Yes4 No Yes No5 No
d: AAD-DS Yes Yes Yes Yes No
e: Federated or hybrid authN Yes Yes Yes Yes Yes
f: Forest trust model No6 Yes7 Yes Yes Yes
g: AD-LDS on internet Yes Yes Yes Yes Yes
h: IPv6 global addresses No No Yes Yes8 No
i: Virtual directory on internet Yes No Yes Yes Yes



There is no completely palatable single solution which addresses the three classes of use cases customers need. Use cases which require domain join to the NETID AD are more problematic and best solved via a S2S VPN. This means either the UW needs to accept the costs of a S2S VPN solution, possibly with some of the mitigations discussed or accept that those use cases can not be solved centrally. A decision by UW-IT which factors in the costs and advantages is needed.

Regardless of whether a centrally provided S2S VPN is provided, we should enable Azure AD Domain Services to provide a more palatable solution for other types of use cases. AAD-DS may not be needed if the UW provides a S2S VPN, but in the long run it is more desirable for non-domain join scenarios, so should be deployed as the strategic solution and used where possible.

The UW should create customer documentation describing the possible solutions in the order of preference.