Readers of the vSphere 7.0 release notes have noticed that, in the “Product Support Notices” section, Integrated Windows Authentication is listed as deprecated. Naturally, there are quite a few questions about this, especially in the wake of all the changes Microsoft has been suggesting to Active Directory. Let’s try to answer some of these!
What is Integrated Windows Authentication?
Integrated Windows Authentication (IWA) is an authentication method in vSphere that relies on the OS that vCenter Server runs on to be joined to a Microsoft Windows Active Directory (AD) domain. IWA uses that connection to the domain to authenticate users into vCenter Server.
What is meant by “deprecation?”
Deprecation means that a feature is still present in a product, and still fully supported, but will be removed in a future release.
In this case Integrated Windows Authentication is still present in vSphere 7.0. When you upgrade to vSphere 7 your previous IWA settings will be moved to the upgraded vCenter Server instance. You can still configure it from scratch on a new installation. You can also call support and be fully supported, until vSphere 7.0 is not supported any longer. That’s April 2, 2025 for the end of general support, and April 2, 2027 for extended support.
Don’t I need Integrated Windows Authentication to connect to Active Directory?
Not necessarily. There are a few different ways to connect vCenter Server to Microsoft Active Directory:
Using IWA, which uses the proprietary Windows interfaces to authenticate.
Using LDAP. All Active Directory domain controllers offer LDAP, and if configured, LDAPS, as an interface for accessing Active Directory.
Using Identity Federation, introduced in vSphere 7.0. This feature allows vCenter Server to connect to Active Directory Federation Services (ADFS) using the standard OAUTH2 & OIDC protocols.
Why is Integrated Windows Authentication deprecated?
vCenter Server 6.7 and earlier have Windows versions and can be installed directly on a Windows Server. As such, IWA made a lot of sense because many of those Windows Servers were already joined to a domain. However, vCenter Server 7.0 is only available as an appliance, and there is no longer an installable Windows version. While we encourage people to treat vCenter Server as an appliance and not as something with a separate operating system, the truth is that the appliances run the Photon OS, which is a distribution of Linux. Not surprisingly, Linux distributions do not natively connect to Windows domains. They require additional software installed to do so, which adds complexity.
Joining infrastructure to a Windows domain introduces other complexities, too. There is the potential for dependency loops, where the infrastructure relies on systems that are running on that same infrastructure. Things might be fine when everything is up & running, but a major incident like a power outage exposes the dependency loop and is then much harder to recover from. There are also political & people issues, too. For good security reasons many organizations have tight controls over who can join devices to Active Directory. Joining infrastructure systems to corporate Active Directory instances requires appropriate access, and that is not always a smooth relationship between teams. In many organizations a domain join is an infrequent occurrence for the vSphere Admins, so when the AD support team audits accounts for inactivity they end up disabling the vSphere Admin’s domain-joining account, which then surprises the vSphere Admin at some – likely extremely inopportune – time in the future. This is not to blame either team. Each team has differing goals and needs, especially for security, and it is hard to reconcile the two in the face of compliance demands.
The adage that good fences make good neighbors is just as true in IT as it is in a neighborhood. LDAP and OAUTH2 are industry-standard authentication protocols, and their use provides a nice clean interface not just between vCenter Server and Active Directory, but also between the teams that support those systems. The change to LDAP/LDAPS also will likely have positive effects on other systems, such as firewalls, by reducing complexity in rules and troubleshooting. It’s easier to control dependencies & dependency loop situations with LDAP. Last, while we only officially support direct connections from vCenter Server to domain controllers, use of protocols like LDAP & LDAPS may offer opportunities for introducing redundancy & failover using application load balancers and other techniques, which is a flexibility that the Linux-based Windows domain connections used for IWA could never have.
Is this related to the Microsoft AD LDAP signing changes and the Event ID 2889 log entries?
ESXi can be joined to an Active Directory domain as well, and that functionality continues to be supported. We recommend directing all configuration & usage through the Role-Based Access Controls (RBAC) present in vCenter Server, though.
So, what should my vCenter Server be using for authentication moving forward?
The two main authentication mechanisms moving forward will be AD over LDAPS and Identity Federation. vSphere 7 supports both equally well, and older versions of vSphere support AD over LDAPS, too.
While AD over LDAP is also supported, we always recommend securing all network communications with TLS. Please configure your Active Directory domain controllers with certificates to enable TLS and configure vCenter Server to use LDAPS. Identity Federation is deeply dependent on cryptography, and communications between vCenter Server and ADFS are secured.
How do I switch my authentication methods?
You can remove the old authentication method and then recreate it with a different protocol using the same domain information. A great example of this is shown in TAM Lab 048, done by Bill Hill, one of our Technical Account Managers. His video shows switching vSphere from LDAP to LDAPS.
We always encourage vSphere Admins to test changes before they make them in their production environments. A great way to do that is with nested ESXi. Deploy a small vCenter Server for testing and install ESXi in a VM for that vCenter Server to manage it (when you’re configuring the new VM choose “ESXi 6.5 and newer” from the list of operating systems). Once it is set up you can shut it all down and take a snapshot, so that if the environment gets messy you can restore it to a working & clean state. While we do not support nested ESXi directly, it is how the Hands-on Labs work, and how many of us do our testing. It’s a great way to test things like authentication.
Conclusion
When it comes to vSphere & security we’re making it easy to do the right things, and making vSphere secure by default. Change can be unwelcome, but when it’s to reduce complexity, improve support, and better draw the boundaries between authentication systems and their clients we feel that’s a big win. The transition is made easier with the continued full support of Integrated Windows Authentication through the life of vSphere 7.0, and the standard options available as replacements. We hope you agree!
As always, thank you for being our customer, and please let us know how we can help make your lives and infrastructure more secure.
We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Kubernetes Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and stay safe!
Readers of the vSphere 7.0 release notes have noticed that, in the “Product Support Notices” section, Integrated Windows Authentication is listed as deprecated. Naturally, there are quite a few questions about this, especially in the wake of all the changes Microsoft has been suggesting to Active Directory. Let’s try to answer some of these!
