The open source community has mastered many challenges and has been successful in numerous areas. However, there is one glaring weakness that needs to be remedied.
Without progress in this area, open source in the enterprise will always play second fiddle to Microsoft, Novell, and other corporate computing entities. What is this critical weakness? Lack of support for Internet Explorer and MS Office? Hardware compatibility issues? Retraining users?
The critical weakness relates to a very basic function of any network operating system. That weakness is the lack of a standardized, secure, interoperable network authentication system. This is a very real stumbling block to the adoption of open source in the enterprise.
“But wait!”, you say. “A stock *BSD or GNU/Linux system has hundreds of security tools! Compared to Windows XP, my open source workstation is more secure, has more security tools, and is infinitely more flexible! What about S/KEY Kerberos, OpenLDAP, IPSec, OpenSSL, OpenSSH, RADIUS, PAM, GnuPG, and Samba 3?”
By default, your system uses flat files. It does not use secure, network-based authentication. “But that can be installed and configured!”, you say. Sure it can, but it always ends up being a customized, site-specific solution that requires lots of time and effort to test, document, setup, and maintain. Making multiple Linux distributions and Unices work together is a time-consuming nightmare. Do organizations typically do lots of in-house development work to make sure that web browsers and web servers on their intranets can talk to each other? Do they develop custom routing protocols for their internal networks?
No. So why do we put up with this for network authentication?
IT managers want to be able to install servers and desktop client machines on their network that securely authenticate users against a centralized database. This should be a straightforward procedure. Until there is a standardized, interoperable, community and industry supported network authentication system included with most open source operating systems, Microsoft will continue to rule the enterprise.
The Problem Described
There are two issues that need to be solved in a network authentication system for Unix-like operating systems:
- global naming
Global naming has to do with storing globally unique UIDs, GIDs, usernames, groupnames, and other network-wide information such as a user’s login directory and preferred shell. This can be handled by protocols like Hesiod, LDAP, and NIS/NIS+. This data is sometimes called directory information.
Authentication is the process of actually allowing (or not allowing) a user to login to a host or access a resource. Authentication can be handled by many protocols, including TACACS+, RADIUS, and Kerberos. In addition, authentication systems should be able to log authentication transactions.
For the remainder of this article, “network authentication system” will refer to both naming and authentication, since both are necessary to login to Unix-like systems and to access resources.
Microsoft, Novell, Sun, and Apple already support unified network authentication, and have been doing this for a long time. As long as you exclusively use the vendor’s proprietary system, all of your hosts will play together nicely. Microsoft, Sun, and Apple can utilize Kerberos and LDAP in their current systems. Novell is working on a Kerberos interface to their successful eDirectory system, and they can already authenticate Linux hosts to eDirectory via LDAP.
What we need is a system that is standardized to the point that any GNU/Linux or *BSD based system can be easily configured to use a standard network authentication scheme. I should be able to configure any common open source operating system to use centralized naming and authentication services after editing no more than two config files. It should just work.
In the Linux world, there is the Filesystem Hierarchy Standard (FHS) and the Linux Standard Base (LSB). These standards help all distributions work together nicely, and make life easier for application developers. Shouldn’t we have a standardized network authentication system? Having such a system would give IT managers more choices, prevent vendor lock-in, and make life easier for administrators and users.
For example, let us look at OpenSSH. OpenSSH runs on almost any Unix-like host, binary packages are available for most operating systems, and it allows terminal communication and file transfer between any two hosts. OpenSSH is ubiquitous. It is used as secure transport for an amazing number of protocols and applications. Wouldn’t it be nice if you could depend on your network authentication system to have the same amount of interoperability and flexibility between different Linux distributions and Unix flavors?
If IT vendors continue to develop their own special authentication systems and organizations using open source technology continue to “roll their own” custom authentication schemes, only Microsoft wins. An open source alternative is imperative.
I would like to see the open source community develop and promote a standard, open, easy-to-deploy network authentication system. The community should put funding, muscle, and top developers behind this effort. Obtaining corporate support may also be a good thing. Sun, Novell, and Apple have already done quite a bit of work in this field and could lend enormous credibility to the project. However, the project must stay completely vendor neutral and utilize existing open standards to the maximum extent possible.
For lack of a better term, I will call this system the Open Directory and Authentication System, or OpenDAS.
Key protocols/applications/functions which should be able to use OpenDAS for naming and authentication:
- Host logins
- Name Service Switch (NSS) lookups called by programs on the client
- E-mail (POP3/IMAP4/SMTP)
- Web (HTTP/HTTPS/WebDAV)
- Network File Systems (NFSv4, OpenAFS)
- File Transfer (FTP, SFTP, SCP, rsync)
- Remote Terminal (SSH, TELNET, RLOGIN)
- News (NNTP)
- Chat (IRC)
- Instant Messaging (XMPP/Jabber)
- Printing (IPP)
These are just examples of the types of applications and protocols which could be supported by OpenDAS.
What does an IT organization gain from a system like this?
- Unified sign-on (or single sign-on if certain technologies like Kerberos 5 are used)
- Centralized user and group administration
- Global password and account policy enforcement
- Enhanced security
- Vendor lock-in avoidance
- Ease of system configuration/deployment
- True choice in client and server operating systems
The server side of the system should be relatively simple to install, setup, and maintain. All the components would be integrated and work together nicely. Excellent documentation would be included. It should be vendor/OS independent, and allow replication and clustering for redundancy. Standard, scriptable command-line tools should be available for administering the servers. A standardized administrative web UI should also be developed (think of SWAT for Samba), which would obviate the need for installing a GUI on the OpenDAS servers. If installation and configuration is a grueling, arcane process, expect the adoption rate to be very low. Keep configuration simple, and standard.
It should only take a few moments to configure the client side of OpenDAS. It should work “out of the box” with Debian, Slackware, Fedora Core, Red Hat, SuSE, Mandrake, FreeBSD, etc. In other words, the client-side programs should be part of the base operating system release. Documentation should be excellent.
In addition to supporting open source GNU/Linux and *BSD operating systems, providing clients for Windows, Mac OS X,
and commercial Unix systems should be a priority. This will speed the acceptance and adoption of standardized, open,
network authentication systems in the enterprise.
Which components should OpenDAS be based on? There are many options, but we can look at what large IT vendors are deploying and what some organizations using open source solutions have already done. Utilizing existing open source projects that are relatively mature should be explored first.
For example, we could construct the system from the following protocols and components:
- Kerberos 5
Kerberos is used for authentication, NTP is used to keep all of the client and server clocks synchronized. LDAP is used for global naming and directory information. PAM is used on the client to allow applications to make calls to different authentication sources (like Kerberos) in a specific order, rather than having to hard-code authentication calls. OpenSSL can be used to encrypt plaintext authentication data or sensitive directory information. Perl can be used to integrate all of the server-side administration/configuration tools and processes.
SASL, GSS-API, and other protocols may be utilized as well. In this case, though, fewer is better.
The design should be such that a user with root access to an OpenDAS client machine cannot compromise the server-side authentication and naming infrastructure. In other words, there are no shared secrets between OpenDAS clients and OpenDAS servers.
On the OpenDAS server side, it may be wise to use some type of modular framework, so that adding things in the future like token cards or biometric information would be possible.
In order for OpenDAS to gain traction in the enterprise, all major open source operating systems would need to include the client software in the base install. On the server-side, the OpenDAS packages should be available as easy-to-install binary packages from the OS distributor’s CD or HTTP/FTP site. Automated, dependency-checking installs would be available for FreeBSD in the “ports” collection and for Debian in the APT repositories. RPM-based distributions could use Yum. It should be as easy to find and install OpenDAS as it is to find and install Samba.
Some people will argue that we can implement this type of OpenDAS today with Samba 3, or some type of Active Directory clone. However, I believe that the open source community can do better than simply mimicking Microsoft’s proprietary scheme, which can be changed at any time. The system should be completely open, and designed primarily for open source operating systems.
Being an open specification, commercial Unix systems could interoperate with the new standard. Mac OS X and Windows machines with OpenDAS client software could easily be added to the network.
If IT managers could add any Unix-like OS to the network with no authentication interoperability worries, then enterprise adoption of non-Microsoft platforms would accelerate.
Concerning the relative importance of this task in the hierarchy of open source projects:
- It is more important than new wireless card drivers
- It is more important than adding IPv7 support to the Linux kernel
- It is more important than supporting 256 CPUs
- It is more important than 3D video support or gee-whiz sound
Successful completion of a project like OpenDAS would push open source into the enterprise and the data center faster than many of the other projects that are being funded and pursued.
In short, centralized authentication and naming would become standardized, commoditized, and ubiquitous. This might be bad news for Microsoft and Novell, but everyone else would benefit.
The open source community has pulled together on many projects and standards. This particular challenge: developing, standardizing, promoting, and commoditizing an open source network authentication system, is both possible and practical to pursue.
This is a worthy goal. Let us join forces to accomplish it.
Links and References
OS X Server ships with OpenDirectory, which uses OpenLDAP and Kerberos 5. The server can also be configured to authenticate to other systems, such as NIS, eDirectory, and Active Directory. Regular OS X machines ship with MIT Kerberos, kerberized applications, and LDAP support.
Included with Solaris 9 and Solaris 10:
Kerberos 5 KDC
Sun One Directory Server
LDAP Support in Solaris Management Console
Secure LDAP Client
Solaris 9 Security Features
Solaris 9 Manageability Features
Novell’s eDirectory uses LDAP and works with Linux, Windows,
Solaris, AIX, NetWare and HP-UX.
The Open Group’s DCE utilizes LDAP and Kerberos.
MIT Kerberos 5
Heimdal Kerberos 5
Pluggable Authentication Modules (PAM)
About the Author:
Van Emery is a data Network Engineer/System Administrator. Currently he is working as a system administrator at Academia Sinica in Taipei, Taiwan. His homepage is here.