For Unix/Linux shops, the security and compliance shortcomings of NIS and NIS+ have become evident in recent years. Lightweight Directory Access Protocol (LDAP) initially seemed a viable alternative that would also allow organizations to manage their Microsoft and Unix user populations in a standard way.

So why are LDAP-based management systems now increasingly falling foul of auditors? And what can enterprises do to avoid this?

When it was first introduced, NIS provided a handy mechanism for centrally managing user and host information in large networks. However, the protocol lacks any inherent support for authentication and authorization, and it is difficult to produce audit trails keeping track of changes to user and host definitions across the system.

With the advent of LDAP, many organizations saw the opportunity of consolidating user data for both Microsoft and Unix/Linux systems in one centralized directory. The problem is that organizations running LDAP are still failing security and compliance audits. LDAP simply does not per se include enough security features to satisfy auditors.

Unmanaged LDAP – that is, LDAP implemented as a core provisioning service within the enterprise, but without add-on functionality to secure and control its use - includes support for central controls on passwords, but without integrating security add-ons, LDAP password is the only authentication choice, unless users are allowed to set up their own authentication. In the latter case, a lack of centralized controls over authentication, for example being unable to prevent users from setting up SSH Public Key authentication with no password, can prove costly in audits.

Unmanaged LDAP does not provide enough fine-grained access controls to satisfy IT and compliance auditors. They want to know exactly who can access what resources, when. Unmanaged LDAP cannot control access for individual users or hosts, let alone at the service level.

Audit trails are another problem. Unmanaged LDAP provides no greater central auditing capabilities than NIS, and does not deliver the kind of documented output showing that provisioning and access policies are actually being enforced in the network that auditors require.

Finally, one of the biggest problems with relying on LDAP for network management is the issue of local functional accounts. When business critical applications require these local functional accounts to operate, application managers are rightly reluctant to hand over control of these accounts to external LDAP systems. However, not doing this leaves the enterprise with perhaps dozens of local accounts that are not under centralized control and not subject to policies. This leads to audit failures.

Given recent audit failures, more and more organizations are looking at strategies to manage LDAP across the different operating systems they use, releasing its potential as a provisioning and management tool while ensuring that it does not become a compliance liability.

One strategy on the table is to use Active Directory, Microsoft’s implementation of LDAP, to manage all the resources in the network, both Microsoft and non-Microsoft. This category of solutions attempts to extend Active Directory authentication and Group policies to non-Microsoft resources including Unix and Linux systems.