SMB Access and Identity for Nutanix Files in Azure
A retail company runs a three-node NC2 cluster in Azure North Europe with Nutanix Files providing 12 SMB shares to 200 users. The on-premises Active Directory domain controllers are reached over a site-to-site VPN with 30-45 ms latency; the NC2 VNet uses the on-premises DCs as DNS servers. Microsoft Entra Connect syncs identities, and a Conditional Access policy requires MFA for the Azure portal. After a second Files instance was added, users report intermittent Kerberos errors and slow share enumeration. The security team will not allow domain controllers to be exposed to the internet and wants to avoid domain trust changes. The company also wants to eliminate public IPs on management components. The network team can add subnets and NSG rules but cannot change the on-premises DC IP addresses.
1. Recommend an identity and DNS architecture for the NC2 workload VNet. Should the company deploy writable domain controllers in Azure, read-only domain controllers, or keep using on-premises DCs? Explain.
Read the worked answer
Keep the same AD domain and avoid a new trust. Because authentication and SMB enumeration cross a 30-45 ms VPN, deploy at least two writable domain controllers in the NC2 VNet in a separate subnet with no public IP, and make them the DNS servers for the workload VNet. Place the Azure subnet in an AD site with the lowest-cost site links so Kerberos and LDAP prefer local DCs. Keep on-premises DCs as additional DNS/AD for resilience, but forward unresolved zones to on-premises DNS; do not point VNet DNS only at remote DCs. RODCs are possible but can complicate write operations and password caching; writable DCs are simpler for Files domain join and SMB. Entra Connect can remain on-premises or in Azure, but it is separate from SMB Kerberos. This avoids domain trust changes, removes internet exposure, and cuts authentication latency.
2. Diagnose the intermittent Kerberos and slow enumeration symptoms. What would you check and change?
Read the worked answer
Intermittent Kerberos errors after adding a second Files instance point to time skew, SPN or duplicate name issues, DNS resolution, or AD site selection, not merely bandwidth. Check that all Files nodes and CVMs are synchronized to a reliable time source, because skew over five minutes breaks Kerberos; verify forward and reverse DNS records for both Files instances and DCs; check SPNs and duplicate computer accounts; determine whether clients resolve a DC across the VPN instead of the local Azure DC; review NSG rules for Kerberos, LDAP, SMB, and RPC dynamic ports; and consider SMB signing or encryption overhead. Slow enumeration can also come from antivirus or large ACLs. Fix by correcting AD site and subnet mapping, making Azure DCs the preferred DNS, cleaning stale SPNs, and testing from a client in the same VNet. Do not widen NSGs to all ports; allow only required AD and SMB ports between workload and DC subnets.
3. Design private management access to Prism Central and Files while meeting the no-public-IP requirement.
Read the worked answer
Remove public IPs from Prism Central and Files management interfaces. Put Prism Central behind an internal load balancer or private IP, and allow TCP 9440 only from a management subnet that is reachable through ExpressRoute or VPN. Deploy Azure Bastion in a dedicated subnet for administrator RDP/SSH to a jump host; administrators then reach Prism Central from that host, not directly from the internet. Use NSG flow logs and Azure Monitor to audit access. If remote admins are outside the corporate network, require VPN with MFA rather than a public endpoint. For Files, keep SMB private to workload subnets and use private DNS zones for name resolution. Validate that backup, monitoring, and Entra Connect traffic use private paths. This meets the no-public-IP requirement without domain trust changes.