VPN Exit in 90 Days with Kerberos, Contractors, and OT
A global manufacturer acquires a 600-person distributor with 12 legacy Windows apps that authenticate via Kerberos and cannot be changed before the ERP migration in 14 months. The combined workforce is 2,400 employees and 400 contractors; the existing IdP supports SAML, OIDC, and SCIM but has no device-posture signal. The current VPN concentrator at headquarters terminates 3,000 sessions on Monday mornings and provides full network access after login. The board has mandated VPN elimination for workforce access within 90 days, least-privilege access for contractors to exactly three applications, and no flat access to the four OT sites. A pilot ZTNA connector in Dublin saturated at 900 Mbps during a Windows update cycle, and users in Singapore reported 220 ms added latency. The distributor's IT team insists on retaining direct RDP to two application servers for break-glass administration.
1. Design least-privilege access for the 12 Kerberos apps without changing them. What enforcement points and identity translation are needed, and what risks remain?
Read the worked answer
Because the apps cannot change, the ZTNA layer must translate an IdP identity into Kerberos without granting network-level access. Put an application connector in the same segment as each app, or a small connector group per app cluster, and publish only the specific host and port as an application. At the IdP, enforce MFA and group entitlement; at the connector, use Kerberos constrained delegation to a dedicated service account limited to the SPNs of those 12 apps. Do not give the connector domain admin or unconstrained delegation. If an app supports header-based authentication, prefer that over delegation.
The enforcement points are IdP authentication and group membership, per-app authorization at the ZTNA policy layer, and the connector's protocol proxy. Users never get an IP route to the server. For RDP, publish the specific server and restrict clipboard and drive redirection; for file shares, publish the share, not the server.
Residual risks: the connector holds delegated credentials and becomes a high-value target; harden it, patch it, restrict outbound access, and monitor ticket requests. The app sees the connector's service identity, so user-level audit must come from ZTNA session logs; retain and forward them. Kerberos delegation can be abused if scope is too broad; review SPNs quarterly. Test with a disabled account and a user outside the group to prove deny. This removes flat VPN access, but it is not invisible: plan an ERP migration path to SAML or OIDC.
2. Contractors need exactly three apps, there are 400 of them, and there is no device posture today. What policy and compensating controls do you use? Would you block unmanaged devices?
Read the worked answer
Start with identity-centric entitlements: create a contractor IdP group mapped by SCIM to exactly the three applications, with time-bound membership and quarterly access review. Require phishing-resistant MFA, impossible-travel and risky-sign-in policies, and separate contractor from employee policies. No contractor gets a network tunnel or a broad role.
Without device posture, the key decision is whether to block unmanaged devices or contain them. Blocking all unmanaged devices will likely break the distributor's contractors and drive shadow workarounds. A better default is an isolated browser for the three apps: the browser runs remotely, so files and clipboard can be controlled and no endpoint agent is required. For the highest-risk app, such as ERP or finance, require a managed device with posture (disk encryption, patched OS, EDR), because session isolation alone does not stop a compromised endpoint from stealing credentials.
Compensating controls: short session lifetimes, re-authentication for sensitive actions, download restrictions, watermarking, DLP, session recording for admin roles, and anomaly alerts. Do not use SMS-only MFA for contractors with access to financial data. If device posture is truly unavailable, make the exception explicit and time-limited and add user behavior analytics. Measure contractor access denials and support tickets; if the isolated browser blocks legitimate work, add a managed-device path rather than widening network access.
3. Address the Dublin connector saturation, Singapore latency, break-glass RDP, and OT segmentation. What architecture and operational controls do you put in place?
Read the worked answer
The Dublin saturation is a capacity and path problem, not a reason to abandon ZTNA. Scale connectors horizontally and place them close to the applications, not the users. Put a connector group in Singapore and route via global server load balancing to the nearest healthy group. Investigate the 900 Mbps spike: Windows updates should not traverse the ZTNA fabric at all. Use split tunneling or local internet egress for OS updates and trusted SaaS, and apply QoS to business apps. If the apps are centralized in Dublin, Singapore latency may be physics plus backhaul; measure hop-by-hop and consider app localization or a regional gateway rather than hiding the latency.
Break-glass RDP: do not publish direct RDP to user endpoints. Provide a privileged access jump host in an isolated management VLAN with MFA, approval workflow, session recording, and time-bound credentials. The distributor's IT team can use it for break-glass, but every session is logged and alerted. Test it monthly and keep it out of the normal ZTNA policy path so a ZTNA outage does not lock out administration.
OT: do not bridge IT and OT through the same connector. Use a separate OT access architecture with unidirectional or tightly brokered flows, no flat routes, and vendor access through a privileged remote access service. The board's no-flat-access requirement is met by per-app policies, default deny, and separate connector groups per security zone. Document residual risk for the legacy apps and set the ERP migration as the deadline to retire delegation.