LinuxDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


Unfinished Business Part 2: Closing the Circle
Pages: 1, 2

The big win here is that the homogeneity of Windows allows this to work as an integrated system that can be set up and managed using one set of tools.



Compare this to UNIX and Linux environments, where login and authentication information can come from:

  • Local files (/etc/passwd, /etc/group) and their shadows
  • NIS files (/var/yp)
  • LDAP
  • NIS encapsulated in LDAP
  • Databases (PostgreSQL, MySQL, etc.)
  • Third-party enterprise directories (though none are generally shipped with major Linux distributions)

Authorization and access-control information can come from:

  • File system permissions
  • Kerberos (only for a very small range of objects unless you've done a lot of work)
  • Third-party enterprise directories (though none are generally shipped with major Linux distributions)
  • Homegrown authorization systems

Access control lists are not yet generally/widely implemented, except on experimental platforms such as the NSA's SELinux or via homegrown ACL-like systems.

User, group, and organizational policies are not yet implemented.

Host information (IP addresses, resource records, etc.) can come from:

  • Local files (/etc/hosts)
  • BIND

Systems management information can come from:

  • DNS (Resource Records, SNMP HINFO data, etc.)
  • External SNMP management systems

And so on ...

What's Missing?

What's missing from this picture is, to hearken back to the XWindow team's observation, a religion. Linux and UNIX have several tools and processes that may be applied (policy) but almost none that must be applied (religion). In order to both play in and compete in the enterprise directory space, the Linux/UNIX community needs to come up with three things:

  • A unified set of PAM modules that provide the glue so that workstations and servers can fully operate with Active Directory without the use of third-party products. Right now, most Linux distributions ship with the ability to get login information from an LDAP directory, but login data only accounts for a small part of AD's available metadata and resource and access controls. Adding more access modules that allow Linux to have more complete native access to AD will get it on more desktops and more servers in sites that are right now stuck with Windows systems.
  • Changes to glibc and the kernel that enforce compartmentalized security and mandatory access controls. I believe that some of these features will be part of the 2.6 kernel, but a really complete implementation can, again, be seen in the NSA's SELinux.
  • A unified set of metadata and services that map directly to those supported by Active Directory so that the open source community can develop and deploy a native enterprise directory service on the scale of Active Directory.

In order to meet AD on its own turf (so that Linux can seamlessly integrate today) and do what AD does, but do it better and more cost-effectively, all of these services must be able to be driven by LDAP and secured through Kerberos.

The most interesting part of this story is that 95% of the hard work has already been done! Microsoft didn't invent totally new LDAP schemas to make Active Directory as comprehensive as it is &mdash as usual, they embraced and extended the work of others. LDAP schemas already exist, and are publicly available to cover:

Of course, Microsoft's own schemas are available for perusal on any Active Directory server (or, if you happen to have a Macintosh OS X box, look in /etc/openldap, for all of Microsoft's schemas are there). Microsoft's schemas are interesting in that they allow us to determine where they have deviated from the published standards (notably in ACL information in Kerberos extensions, which was the point of some heated debate back in 1998-1999).

Finally, we (the Linux community, in particular) tend to think that a lot of what we're doing is new, but the MIT Athena project had done a lot of this way back in the late '80s and early '90s. They did it across multiple versions of UNIX (AIX, Ultrix, SunOS, and several others).

Where Do We Go From Here?

There are two directions that Linux and UNIX must go in simultaneously in order to get up to speed in this important area of integration:

At the Workstation Level

Take the ACL code and other security hooks from the NSA's Security Enhanced Linux (SELinux) and use them as the platform into which PAM modules can be used to tie Linux into AD (and eventually a native Linux directory). SELinux enforces MACs (Mandatory Access Controls) in the system — some people will bridle at the thought of adding such potentially draconian security into what is a very friendly OS, but the addition of such security controls will only help the community write better software that only uses a privilege where it's needed, and not just because someone didn't take the time to code a correct solution. It will also help cut down on potential security breaches down the road.

At the Enterprise Level

First and foremost, Linux vendors need to ship fully configured LDAP and Kerberos servers with their distributions with full-fledged database back ends, not just a DBM-style library, as is currently the case. The single hardest part of either of these systems is the setup. Wizards need to be provided (the existing ones in most distributions are dreadfully inadequate) that make the configuration of parameters simple and activate available schemas without forcing the administrator to become either an expert in LDAP or Kerberos.

Next, from the perspective of making a Linux enterprise directory AD compatible, is frankly to dissect Active Directory's schema and implement the proprietary bits under Linux. When Microsoft does such things they call it "embrace and extend" because they usually take an open standard and add some proprietary extension to make it non-portable and lock in their customers, as they did with their extensions to Kerberos. I would suggest we take a page from their playbook but call it "enhance and open." As long as this is not done with internal Microsoft documents that are subject to NDAs, this should not be a problem. (Hint: the information was reverse-engineered long ago and is readily available).

LDAP and Active Directory Tools/Notes:

There are several tools already out there that make setting up and administering LDAP a bit easier. Here are some of the most complete:

LDAP Admin Tools

Active Directory and LDAP Implementation Notes

David HM Spector is President & CEO of Really Fast Systems, LLC, an infrastructure consulting and product development company based in New York


Return to the Linux DevCenter.


Linux Online Certification

Linux/Unix System Administration Certificate Series
Linux/Unix System Administration Certificate Series — This course series targets both beginning and intermediate Linux/Unix users who want to acquire advanced system administration skills, and to back those skills up with a Certificate from the University of Illinois Office of Continuing Education.

Enroll today!


Linux Resources
  • Linux Online
  • The Linux FAQ
  • linux.java.net
  • Linux Kernel Archives
  • Kernel Traffic
  • DistroWatch.com


  • Sponsored by: