By Prince McLean

Published: 10:05 AM EST

Mac OS X Leopard not only makes it easy to do new things, it also allows you to restrict functions based on permissions. In home settings, this feature is presented as Parental Controls. In business settings, the same technology is used to provide Managed Preferences, essentially setting up controls and guidelines for employees rather than children. This is another example of applying technologies in both the client and server side of the product, and how Apple is leveraging its strength in its core markets to expand into new areas. Here's how the features work in Leopard and Leopard Server, what you can do with them, and where the ideas behind managed preferences -- and the underlying directory services supporting them -- came from.

This report goes to great lengths to explore the origins, history, and maturity of managed preferences and parental controls. For those readers with limited time or who are only interested in what's due in Leopard, you can skip to page 3 of this report.

The Origins of Network Directory Services

In the early days of computing, client users worked on terminals attached to a central computing system. This made it easy to control what logged-in users could do, because updated changes to the central computer could immediately restrict access or simply boot connected users off the system.

The development of Unix for minicomputers, described in the previous article Road to Mac OS X Leopard Server: Collaborative Info Sharing Services, followed many of the conventions of existing systems to build a portable operating system that supported multiple users with centralized permissions.

The arrival of the personal computer in the 80s shifted computing resources from a centralized model to a distributed one, where simple terminals were replaced by more powerful PC and workstation systems running their own complete computing environment. That also distributed the work of managing access permissions -- as well as device and application configuration settings -- across large numbers of independent client systems, rather than managing all of that work in one place.

Distributed Config File Management: NIS

As Unix-based workstations replaced simple terminals, the effort of managing complex software installations mushroomed. User and application settings, account passwords, and the addresses of other hosts on the network were all configured in text files on the system. Making a system-wide change to any of those settings therefore required administrators to run around updating every system manually.

Simply adding a new client system to the network required not only configuration of that new system, but also updating the settings of every other system on the network to make them aware of the new machine's presence and its network address.

To automate the updating of information between client systems, Sun developed a network service called Yellow Pages to push text configuration file updates out to all of the workstations installed at a site. Sun later renamed the service NIS, for Network Information Service. Sun's NIS greatly simplified network administration and was rapidly adopted by other Unix vendors, but it offered limited security features because it was built primarily for use on internal networks that were assumed to be trustworthy and secure.

Distributed Name Management: DNS

The arrival of the Internet changed all that because computer systems were now exposed to untrusted hosts. The implications for security breaches became obvious in an wide open environment where individual systems could be passed maliciously designed settings files on the sly. The Internet also dramatically increased the work needed to manage network settings, because rather than just accounting for the needs of perhaps hundreds of systems within a company, the thousands of companies attaching to the Internet now needed a system for managing traffic between all of their many thousands of client computers.

Prior to the development of the Domain Name System by Paul Mockapetris in 1983, computers connecting to the Internet had to maintain local "Host files" that listed names and network addresses of all the systems they knew about. Just as with password, application, and device settings, these text files had to be manually updated whenever changes were made to the network. DNS solved the addressing problem for Internet users by setting up a hierarchy of servers that centrally manage computer naming records.

Client systems can then ask the DNS server for addressing information when they need it. The only problem with DNS is that the server had to be reachable; if it was not, a computer could not resolve addresses and had to fall back to consulting its local Host file.

Automatic Configuration and Addressing: AppleTalk

In 1984, Apple introduced an automated networking system for the original Macintosh called AppleTalk. When plugged into a network, each system would make up its own address, then confirm that it was unique. It would also automatically discover other systems on the network, and adapt to changes as they occurred. This meant that Mac administrators didn't need to manage services like NIS or DNS on a local network to allow users to find file and print servers.



PC users connecting to local area networks commonly used Banyan Vines, Novell NetWare, or Microsoft's LANManager, but unlike AppleTalk, all of these required a centralized server to manage names on the network, similar to DNS. Neither AppleTalk nor any of the DOS PC "Network Operating Systems" were designed to manage user, application, or configuration settings outside of basic file sharing between local systems, and all of them used proprietary network protocols that prevented them from interoperating with the open Internet Protocol rapidly deploying among Unix systems in the 80s.

All of these other networking protocols were rapidly replaced by IP starting around 1996. Apple moved its AppleShare server to use IP as its network protocol, but continued to also use AppleTalk for automatic discovery. In Mac OS X, AppleTalk was only used for browsing the network; actual server connections were performed over IP.

In 1997, Apple implemented the automatic networking configuration and name resolution features of AppleTalk to work over standard IP using Multicast DNS and DNS-Service Discovery, and began offering the technology as an open standard called Zeroconfig. In Mac OS X 10.2 Jaguar, these features were collectively marketed under the name Rendezvous, later changed to Bonjour. Apple has also ported Bonjour to Windows and offers an open specification and open source code for other Linux and other Unix-like operating systems to use, as is detailed in A Global Upgrade for Bonjour: AirPort, iPhone, Leopard, .Mac.

Distributed Directory Management: NetInfo

In the late 80s, NeXT took the concept of DNS and applied it to a new system called NetInfo (below, configured from NetInfo Manager) for distributing not only machine addressing, but other information as well, collectively referred to as directory services.

For example, directory services are used in a network environment to look up user accounts. While local user accounts can be created on a client system, managing account lists between systems is difficult because two systems may have accounts that overlap. For example, two independent systems may happen to have the same user name but refer to different people. A directory services system uses a centralized server that acts as a repository for network account information, similar to how a DNS server provides centralized name services.

Administrators then only need to manage account information in one place. When users with network accounts log into a client machine, they enter a user name and password that are checked against the directory server, rather than a local list of users. Directory services can also supply other network information, such as a listing of the printers or file servers available on the network, or a company directory of users, the groups they belong to, and their contact information.

NeXT's NetInfo replaced the text config files found in a typical Unix system with a local database that managed a directory of user and group accounts, machine configuration, and network services. Rather than consulting text files on the system to look up these settings, applications on NeXTSTEP consulted NetInfo. If the local database didn't have the requested information, it could forward the query to centralized NetInfo Directory Servers. NetInfo could also plug into Sun NIS servers to obtain information about the network.



On page 2 of 3: Problems for NetInfo; Standardized Directory Management: X.500; Standardized Directory Management: LDAP; LDAP in Mac OS X; and Origins of Managed Preferences.