Local Logins Refused in AD Integration Scenarios

A customer with whom I had worked to fully integrate their ESX Server systems into Active Directory—using my instructions here—had run into a problem. The problem was that local logins were refused when the Service Console lost network connectivity. Clearly, this was a problem; if the customer couldn’t login as root when the network is down, even locally at the console, then we have problems. So I set out today to isolate and fix the problem.

After much trial and error, I had determined what was not the cause the problem:

  • The /etc/pam.d/system-auth file was not at fault; we tried numerous combinations in system-auth and there was no difference in behavior
  • The /etc/ldap.conf file was not at fault; we even tried adding a few additional entries (like “bind_policy soft”) to help with issues when LDAP was down and not responding
  • A lack of DNS resolution was not the problem; the behavior was the same whether DNS was working or not

Finally, I was able to track down this thread which discusses the behavior of the nss_ldap libraries when the LDAP service is not available across the network. In this specific message in the thread, it is noted that nss_ldap will try to contact LDAP to enumerate group membership, even if LDAP is down. So the problem was with using LDAP for group membership, and a quick edit to /etc/nsswitch.conf to remove LDAP from the group line proved that to be true.

As shown in the message, the only workarounds are:

  • Upgrade to v245 of nss_ldap, which allows the use of the “nss_initgroups_ignoreusers” directive; this instructs nss_ldap to not perform group enumeration for the specified users; or
  • Remove the “ldap” entry from the group line in /etc/nsswitch.conf.

Unfortunately, ESX Server 3.0.2 and ESX Server 3.5.0 only supply nss_ldap v207-17, which is too early to support that directive. Of course, we can’t really upgrade the library, either, since that’s not supported by VMware. So the only real fix for VMware ESX Server AD integration scenarios is to not use Active Directory for group memberships. User accounts can still be managed using Active Directory—and authentication occurs against Active Directory—but groups and group membership will have to be handled locally.

This issue is applicable to other operating systems besides ESX Server, though, and for those operating systems an upgrade of the nss_ldap library and the use of the “nss_initgroups_ignoreuser” directive in ldap.conf may be all that is needed to fix an issue with local logins being refused when network connectivity is not present.

UPDATE: It appears that local logins will work without network connectivity, even with full Active Directory integration, if you use the Emergency Console. Thanks to Magnus for the update!

Tags: , , , , , ,

5 comments

  1. Rob’s avatar

    I am having this same issue, but I followed the VMware document on enabling AD authentication which does not make any changes to nsswitch.con thus mine is still set to “files” on passwd, group, and shadow (no ldap). Any ideas?

  2. slowe’s avatar

    Rob,

    I can only suggest having a look at the /etc/pam.d/system-auth file, which controls the authentication process, to see in what order esxcfg-auth specified the use of local files and Kerberos. Perhaps changing the order to UNIX first then Kerberos might help, if they aren’t already in that order.

  3. Magnus’s avatar

    Scott,

    After doing some research it turns out that even with the full AD integration enabled I can still log in to the Emergency Console using local authentication.

    I would still rather VMware update to a bugfree nss-library but at least we won’t have to use local groups.

    Cheers,
    Magnus

  4. slowe’s avatar

    Magnus,

    Thanks for the update. I’ll update the article accordingly!

  5. Doug W’s avatar

    This is a problem also in RHEL3 and I have only found one workaround for it which is to use NIS for passwd, shadow and groups. I tried building a later nss_ldap module on RHEL3 and was dogged with segmentation faults when performing lookups.

    This doesn’t mean you are locked into using the shadow passwds given by NIS. I am using kerberos instead via your other instructions for Linux. Basically using NIS as the replacement for LDAP/AD in this case. http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/

    BTW, it will generally fail on the first attempt if the NIS server can’t be reached, but the second login try will succeed.

Comments are now closed.