While Microsoft's Active Directory (AD) is an effective play to circumvent the inherent central authentication foibles of Linux, getting the technology synced with servers has been a complex undertaking for IT practitioners, to say the least.
The problems of authentication stem from Linux's Unix roots, said John Enck, research director at Stamford, Conn.-based research firm Gartner Inc. "[Like Unix], the issue with Linux is there's no [centralized] management structure. Nor does the OS have a solid directory story," he said.
For global credit information firm Experian Group Ltd., this Linux hurdle meant that as administrators authenticated users on a server-by-server basis, every password or group policy change to its 40 Linux servers would take roughly a minute per server. Ferris Rezvani, an IT infrastructure manager at Costa Mesa, Calif.-based Experian, said Linux also lacks easy, out-of-the box, network-wide single sign-on (SSO) functionality.
By contrast, Active Directory does have a solid central management structure, and many analysts view AD as a way to circumvent Linux's authentication shortcomings. In fact, with Windows still the dominant server platform in the enterprise, many IT shops already have Active Directory authenticating mission-critical areas of their environment. Many analysts, like Sally Hudson at Framingham, Mass-based IDC, believe that enterprises should begin testing ways to leverage the technology as soon as possible.
LDAP or Kerberos: For the experts
For IT shops that are comfortable with standard network authentication protocols, a logical choice may be Kerberos or the Lightweight Directory Access Protocol (LDAP), but they're not for everyone, Enck said. Mastering these environments can be difficult, so it's no surprise that the majority of IT departments using them for Linux authentication are at highly technical educational institutions with the manpower to spare, he said.
For example, to join non-Windows platforms with an AD/Kerberos server, you have to modify the MIT Kerberos implementation; that's because Microsoft uses a field in Kerberos that most implementations don't include automatically, Enck said.
Alternately, some shops opt to use LDAP, but it presents its own set of issues in heterogeneous environments. "If you want to set up a separate directory like LDAP in Linux, you can use a syncing technology like a management information system [MIS] and maintain parallel directories between Windows and Linux," Enck said. "This is ineffective, [however], because you then have a duplicate set of users. People still do it, though."
Trying to authenticate Linux LDAP objects with AD may also require changes to the AD schema. But many users refuse to make alterations because changes can affect their support contracts with Microsoft.
Samba and Active Directory
A second route is Samba, the open source project that provides file and print services to Server Message Block/Common Internet File System clients, including Microsoft Windows. As of version 3.0, Samba also integrates with a Windows Server domain, either as a Primary Domain Controller (PDC) or as a Domain Member. It can also be part of an Active Directory domain.
As is the case with network authentication protocols, however, the consensus among experts is that Samba is tricky to administer.
Enck is among the Samba skeptics. "Samba has Active Directory interfaces, so you could put that on your Linux servers and establish a 'trust' relationship with Active Directory, but this is difficult to do," he said. "Is it worth the effort? I'm not so sure." Establishing trust is crucial for Linux servers running under AD, as AD uses trusts to allow users in one domain to access resources in another.
A Samba component called Winbind helps in this regard, although it is hardly the holy grail of Unix-Linux-Windows interoperability that the Samba development team hopes to perfect. Jerry Carter, the Samba project release manager, said Winbind uses a Unix implementation of Microsoft remote procedure calls, pluggable authentication modules (PAMs) and the name service switch to "fool" Windows into working with Linux servers.
But in an email, Sherwood Botsford, an IT manager at an educational institution, said that Samba is indeed a work in progress.
Botsford uses Samba as a PDC with modest results, but deletions from the profile of Windows 2000 clients don't propagate back to the server, so users occasionally lose their connection to the PDC.
A third option is an automated third-party application that places an agent on each Linux server in the network. Each Linux server is then managed using a Windows-themed UI and appears in AD as a Windows one.
Products of this type include Likewise 3.0, from Bellevue, Wash.-based Centeris; Vintela Authentication Services from Quest Software Inc. of Aliso Viejo, Calif.; DirectControl from Moutain View, Calif.-based Centrify; and PowerADvantage from newcomer Symark Software, which the Agoura Hills, Calif., company launched in September. The average price of these applications is approximately $290 per server and $50 per workstation.
Metadirectory alternatives from IBM Corp., CA and Hewlett-Packard Co. can also be grouped in this category, although they typically cost hundreds of thousands of dollars more. Gerhard Bartsch, an enterprise systems engineer at Center for Advanced Study of Language in College Park, Md., said the lower price point of applications like Likewise 3.0 mean that Big Blue's Tivoli Directory Integrator and HP's Select Identity software aren't options for many IT shops.
Going with a third party for cross-platform authentication might sound convenient, but Enck said third-party automation software can add an extraneous layer for some users. Enlisting their skills to leverage LDAP or Kerberos protocols, for example, may be the better choice, he said. "If you have the expertise, then use it," he said. "This way you won't have to worry about applying [third-party] patches to Windows or Linux and what the results will be, because you already know your system top to bottom."
Even so, according to Gartner about a third of enterprise-level Linux administrators use or are evaluating Active Directory for authentication via specialized, third-party software. Another 10% are technical users implementing LDAP or something similar, and more than half have taken a wait-and-see approach, where they perform separate administration of Linux and Windows manually, he said.
And the third-party option has become appealing. "[It] gives you the agent to run on your Linux servers, it gives you commercial support for problems, and it gives you the benefits of AD's group policies," Enck said.
According to Microsoft, Group Policy is a feature of Windows NT that provides centralized management and configuration of computers and remote users in AD. By installing an agent on a Linux server, third-party cross-management applications can leverage Group Policy features to control a target object's registry, audit and security policy, software installation, logon/logoff scripts, folder redirection, and Internet Explorer settings as though they were on a Windows machine.Manual administration and the long wait
But what about the remaining majority of users who are waiting for the cross-platform management market to mature? They may even be reading this article.
Enck said most of these users have single sign-on in place or have decided for the short term to implement a user-provisioning application for stored accounts as they manually administer Linux boxes.
Utilizing SSO provides a layer above Active Directory that masks the complexity of the underlying platforms. "In this case, it's not about leveraging AD to sign on to Linux; it's about using one username and password to sign on to everything, including AD, Linux, Unix," Enck said.
User provisioning, on the other hand, allows the user to take a common username and password and have it updated on multiple systems. There's no single sign-on in this case, but users can use the same username and password to sign on to each system. "Both SSO and user provisioning can fully embrace AD -- or not," Enck said.
In the former case, SSO uses AD as the SSO directory and the user provisioning application monitors for username/password changes in AD and then syncs them with other platforms/directories. In the latter case, the SSO comes with its own directory that sits on top of AD (and other platforms) and the user provisioning product comes with its own directory that drives changes into AD (and other platforms/directories). In either case, users still manage Linux servers at a local level, Enck said.
Still other users could be looking for ways to migrate off of Sun Microsystems' aging Network Information Service (NIS) architecture, which many have used to manage user passwords. This approach often fails Sarbanes-Oxley Act compliance regulations, but some managers use it anyway.
In the meantime, the cross-platform authentication market will probably remain in flux until at least 2009, Enck said, as those shops on the fence commit to one option over others.
Email Jack Loftus, News Writer, with your questions and comments on Active Directory and Linux.