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.
|
On this page
|
Appendix
|
|---|---|
Current State
Azure is recommended for customers with a cloud-based use case that requires connecting to a NETID domain controller. UW customers with an Azure subscription can request a VNET peering to a UW-IT hub VNET with NETID domain controllers, a DNS bridge solution, and optionally a gateway transit of a shared ExpressRoute. The Azure/UW DNS bridge solution enables resolution of hosts and services on private networks in both UW and Azure managed DNS zones. The shared ExpressRoute is not appropriate for use cases with large data transfer.
More information about all of these solutions is available at: NETID Domain in Azure | IT Connect (uw.edu).
As with on-premises NETID domain controllers, 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: /tools-services-support/it-systems-infrastructure/msinf/authn/firewalls-with-netid-domain/.
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:
- 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
- Product design requires AD join, but not necessarily directly to NETID, e.g. SQL server hosted in cloud
- 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: Entra ID Domain Services | 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
|
Secure
|
Cheap
|
Sharable
|
Supported
|
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: Entra ID Domain Services | 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 |
Recommendation
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 Entra ID Domain Services to provide a more palatable solution for other types of use cases. Entra ID Domain Services 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.