By Prince McLean

Published: 10:05 AM EST (07:05 AM PST)

Problems for NetInfo

NetInfo could potentially pose a problem, however. Because requests for DNS lookups were routed through NetInfo, if an external DNS server failed to reply the system could simply get stuck waiting for a response, as no other lookup information could take place. Also, because NetInfo also stored its user account information in a local database, any corruption of that database required the user to shut the system down and restore the database from a backup, or simply delete it and generate a new one, recreating all of the local accounts by hand. On Unix systems, a corrupted Users configuration text file might be easier to manually repair or rebuild, or replace on the fly with a known good version.

User documents were not affected by a NetInfo failure, nor were the user's application settings and preferences, because all of these were stored separately in the user's home directory. After rebuilding the NetInfo database, users simply logged in again and all of their settings and files appeared just as they had been.

NeXT made plans to sell NetInfo for other Unix-like systems, but little interest was expressed. Sun also found little enthusiasm for NIS+, its revised system that addressed security issues in the original NIS. Instead, the industry began looking for open, interoperable standards that weren't controlled by a single vendor.

Standardized Directory Management: X.500

International standards bodies, led by the ITU and later the ISO, began work in the 80s to create interoperability in networking. Existing network protocols in use among PC and workstation users were all proprietary to specific vendors, including Apple's AppleTalk, Novell's NetWare, Digital's DECnet, IBM's SNA, and Microsoft's LANmanager.

The ITU set up a series of networking standards called Open Systems Interconnection, which included the X.400 specification for email and X.500 for directory services. Major vendors announced support for the new standards, particularly in directory services; Apple incorporated support for a X.500 gateway in its PowerTalk email architecture, Novell released its Novell Directory Server based on X.500 in 1993, and Microsoft promised support for X.500 in its 1991 Cairo vision, which was eventually delivered as part of Exchange Server in 1996, as noted in Microsoft's Yellow Road to Cairo.

The development of OSI rapidly began to crumble with the emergence of the simpler and more effective standards forwarded by the Internet Society. Rather than representing the needs of companies making up the OSI, the open alternatives to network standards developed by the Internet community addressed the needs of actual users. By 1996, the failure of the OSI had ripped apart the strategies of big companies and forced them to rapidly retool to support Internet standards, as noted in Apple's Open Source Assault.

The OSI bureaucracy had resulted in specifications that were heavy, inefficient, and complex. In contrast, the process for submitting Internet protocols was more open and competitive, allowing the best proposals to advance through a peer-reviewed Request For Comment process managed by the Internet Engineering Task Force, which then adopted and implemented, proven RFC proposals as Internet standards. The OSI had largely drafted specifications that were only theoretical.

Standardized Directory Management: LDAP

In 1995, the University of Michigan began work to access X.500 directory data over the Internet. After determining that the X.500 Directory Access Protocol was unnecessarily complicated, the U of M developed a replacement called the Lightweight Directory Access Protocol. LDAP used a specifically tuned database to return directory information lookups over the Internet similar to NetInfo, but it was implemented as an interoperable open standard. LDAP also provided authentication and encryption services missing from Sun's NIS; that encouraged Unix directory services to rapidly migrate over to LDAP.

Novell and Microsoft also scrambled to offer LDAP support in their PC directory services products. Novell delivered an LDAP plugin for NDS in 1996, when Microsoft was rolling out its X.500 product. After announcing plans to support LDAP that year, Microsoft first delivered Active Directory 1.0 four years later in Windows 2000. Active Directory replaced both the X.500 directory services in Exchange Server as well as the proprietary NetBIOS and WINS systems used by Windows for its networking name services. Active Directory is an "embraced and extended" version of LDAP, but is similar enough to allow other vendors to develop support for it.

LDAP in Mac OS X

After Apple acquired NeXT in 1996, it adapted the NetInfo system to work with a new LDAP-based directory services architecture called Open Directory, starting in 2002 with the release of Mac OS X Jaguar 10.2. In Leopard, Open Directory has also replaced the last remnants of NetInfo on the local system.



Apple's Open Directory can also plug into Microsoft's Active Directory and standard LDAP systems now in wide use in corporate environments, and can also fall back to reference the standard Unix files on the system, such as the local Host file; these are referred to as "BSD Flat Files." Once bound to a directory server (above), the system can then login with a given network account.

Open Directory supports MIT's Kerberos single sign on authentication. Users who log in as an Open Directory user have their credentials securely passed on to other services by Kerberos. That means a signed in user won't have to repeatedly provide their username and password to access file shares or other network resources that require authentication; their login does it for them.

Open Directory can also act like a Domain Controller for Windows PCs, allowing them to login to roaming profiles and network home directories on the same server, using the same account as they would to login to a Mac. This is configured in Server Admin (below), and is based on features supplied by the Samba open source project.



Origins of Managed Preferences

While NetInfo addressed directory services, it did not manage user preference settings. These settings were all stored in regular preferences files separate from the NetInfo system. Like other other Unix systems, NeXT stored those config settings in text files.

NeXT introduced a structured file format for this called a property list. Because it was human readable text, it could be edited by hand, just like Unix config files. However, the graphical environment of NeXTSTEP typically updated these "plist" files itself, such as from the Preferences application (below). Because the files were organized using a specific structure, the system Defaults command could also be used to manage or update preference settings, even those not exposed anywhere in the graphical interface.



Apple's Macintosh stored its Preferences files in binary files, as they were not intended to be edited by hand or in a command line environment. If a preferences file became corrupt, the solution was to delete the file, and applications were designed to be resilient to this. If a launched application could not find its preferences file, it was supposed to create a new blank one. Deleting preferences was a handy troubleshooting step, because a corrupted file could commonly cause any number of problems. Once deleted, the application simply reverted to its default settings and the user was back in business.

On page 3 of 3: Microsoft's Windows Registry; Preferences in Mac OS X; Managed Preferences; New In Leopard: Parental Controls; and New In Leopard: Employee Policy and Organizational Directory.