Posted  by  admin

Why Can't We Have Directory Services Like Open Directory (for Mac

Why can

Editor’s Note: This story is reprinted from. For more Mac coverage, visit. Directory services are a critical component of any enterprise environment. These services provide a database for central account management for both user and computer, as well as a framework for sharing that information among workstations and servers. Mac OS X’s native directory service is called Open Directory. Every Mac OS X computer includes a local Open Directory database—referred to as a domain—that stores information about local user accounts.

This local domain allows each user to have a computing experience and home directory, and the local domain works with the file system to manage permissions on files and folders. Mac OS X Server relies on shared Open Directory domains to provide network user accounts that can be used to log into computers that are bound to a shared domain.

The shared domain can also allow users to access resources on other servers that are bound to the domain. Shared domains also allow systems administrators to define custom user environments. Open Directory is a multipart architecture that performs the basic functions of any directory service in addition to providing mechanisms for accessing non-native directory services platforms such as Microsoft’s Active Directory and Unix Network Information Service servers. Read aloud epub for ibooks download for mac free.

It also has components that manage Mac OS X’s access to self-discovering network protocols including Apple’s Bonjour, Microsoft’s Server Message Block/Common Internet File System and the open standard Service Location Protocol. When discussing Open Directory, however, the phrase typically refers to its function as Mac OS X’s native directory service. NetInfo—The local Open Directory domain Each Mac OS X computer, including Mac OS X Server, has a local Open Directory domain. This domain stores all information about local users as well as information about the machine itself. The local domain for Mac OS X is a NetInfo domain.

NetInfo is a proprietary directory service originally developed by NeXT Computer that originally served as Mac OS X’s native directory service. As Mac OS X Server evolved, Apple replaced NetInfo with a service based on the Lightweight Directory Access Protocol (LDAP) that is often referred to as simply Open Directory. There is little administration that needs to be done with the local NetInfo domain on Mac OS X computers.

However, it is important to understand that the local domain is always the first source in which a Mac OS X computer will look for user information. It is also important to know that the local domain is visible in Mac OS X Server’s Workgroup Manager; this is the tool used for managing user, group and computer accounts. User and group accounts stored in a server’s local domain can access resources on the server, including share points, print queues and Internet services. Local accounts are not part of a shared domain, however, so they can’t be used for log-in at Mac OS X computers. Search paths for shared domains Mac OS X computers can be bound to multiple directory domains (both Open Directory and domains of other platforms such as Active Directory). This requires that a search path be established that defines the order in which available domains will be searched for account information. This is different from a Windows environment, in which a list of available domains is part of the log-in dialog.

As mentioned above, the local NetInfo domain will always be first in the search path on Mac OS X. However, you can place any other domains in any order that you choose. Search paths can be useful in a number of ways.

They allow you to have separate containers for different groups of users and/or computers. They also allow you to build support for multiple directory service platforms that can mix and match advantages of each system.

For example, you could rely on user accounts stored in Active Directory but manage computers using accounts stored in Open Directory, which enables you take advantage of Apple's client management architecture. Search paths are powerful tools, but it is important to recognize that if you have users with the same name in two domains in a search path, only the account in the first domain of the search path will actually be found. Directory binding Mac OS X computers can be bound to Open Directory domains in two ways. The first, and simplest, is Dynamic Host Configuration Protocol (DHCP). Mac OS X Server can include information about a domain with other information in response to a computer’s DHCP request. By default, Mac OS X will accept and use Open Directory configurations received by DHCP.

This is helpful both because it saves the time and effort of manually configuring each computer in a network. For static binding, you configure access to directory domains using the Directory Access utility, which is located in the Utilities folder inside Mac OS X’s Applications folder.

Directory Access includes plug-in modules that can be configured for each of Open Directory’s features. For instance, the LDAP v3 plug-in manages Open Directory domain configuration and binding. Search paths are set by using the Authentication tab in Directory Access. You can choose to use an automatic search that includes DHCP-supplied domains and the local domain; local-only, in which only the local domain is used; and custom, which allows you to manually configure and set the search path of available domains.

You can also use the Contacts tab to set up LDAP search paths of domains for Mac OS X’s Address Book application. Managing shared domains Mac OS X Server supports four Open Directory roles: stand-alone, Open Directory Master, Open Directory Replica and Connected to a Directory System. A stand-alone server relies solely on its local NetInfo domain and is typically not used as a file or print server. An Open Directory Master is a server that is hosting a shared domain. An Open Directory Replica is a server that hosts a read-only copy of the domain.

Why CanWhy Can

Why Can't We Have Directory Services Like Open Directory (for Mac Download

Replicas allow for load balancing and support remote locations where a slow network link makes direct access to the Open Directory Master impractical. Replicas also allow for fail-over in the case of a failure of the master. “Connected to a directory system” refers to a server that’s bound to a shared domain but that is not providing directory services.

Users can access servers connected to a directory system using accounts stored in the shared domain. Typically file, print and e-mail servers will use this role. In smaller environments, however, a server might offer these services in addition to being an Open Directory master or replica. Open Directory domains rely on the Domain Name System (DNS) to function.

For this reason, ensuring that you have a fully functioning DNS infrastructure is critical to setting up Open Directory in a network. Frequently, Open Directory failures can be traced back to problems with DNS. One of the pitfalls of simply walking through Mac OS X Server’s “Server Assistant” tool, which runs automatically after a basic installation, is that the Assistant offers you the option of setting up a new Open Directory domain. This can cause problems if the server you are setting up will serve as an Open Directory Master and DNS server. As complex as Open Directory is, both as a whole and in the structure of individual domains, Apple has made the set-up process extremely simple, provided you have DNS and other network services set up properly beforehand. You can easily change an existing server into an Open Directory Master by simply selecting that role from a pop-up menu in Mac OS X Server’s “Server Admin” utility. Then you enter basic information about the domain, including an account that will have administrative authority over the domain, the LDAP search base for the domain and the Kerberos realm that the domain will use.

Why Can't We Have Directory Services Like Open Directory (for Macbook Pro

You can elect to set additional features at this time (or later) as well, including default domain password policies, whether computers must communicate with the domain over secure connections, and whether computers accessing the domain must be bound to it. All of these options can substantially increase security. Setting up replica servers and binding other servers to the domain are equally simple. There are, of course, more advanced tools for some administrative tasks, many of them being command-line tools that are beyond the scope of this article. However, for most environments, the graphical tools in Server Admin are all you need to get an Open Directory infrastructure up and running. Kerberos and the Open Directory password server Open Directory provides multiple mechanisms for securing passwords.

The original mechanism used by Mac OS X Server was to store passwords as an attribute of the user account object. This feature is referred to as “basic passwords” and is still supported for backwards compatibility with older versions of Mac OS X and Mac OS X Server, though it must be chosen as a specific option for each user account. Basic passwords are stored and transmitted in encrypted form. However, because they are stored in Open Directory domains, basic passwords are susceptible to offline security attacks using either Workgroup Manager or command-line Open Directory tools. Open Directory also offers the default Open Directory password type. This technique stores user passwords outside of the domain itself in two places. The first is in a Kerberos realm.

The second is in the Open Directory Password Server database. Both offer enhanced security because the password is only set and verified and is never actually read by Open Directory.

When these password types are used, only hashed information identifying the location of a user’s password in either the Kerberos realm or Open Directory Password Server is physically stored in the user record. By default, when a server is set up as an Open Directory Master, it is also set up as a Kerberos Key Distribution Center (KDC). This makes Mac OS X Server one of the easiest platforms to set up as a KDC because the process is almost entirely automated. It is also possible to use an alternate KDC—including an Active Directory domain controller, which is helpful in a multiplatform environment. In addition to securing password storage, Kerberos offers significant password security for user connections because it relies on tickets to authorize access to any “Kerberized” services within a network.

Thus, a user’s password is transmitted only when he first logs in. Kerberos also provides a seamless, single sign-on environment where users will not be repeatedly asked to authenticate as they connect to servers and browse for Kerberized services.

Under Mac OS X Server, these Kerberized services include the Mac OS X log-in window, e-mail, Apple Filing Protocol and Server Message Block protocols for Mac and Windows file/printer sharing, virtual private networks, file transfer protocol services, Apache and Secure Shell access. Because Mac OS X Server uses a standard Kerberos installation, you can offer additional Kerberized services within your network using servers and clients of other platforms, including Unix. Telnet and Rlogon are two examples of Unix services that can now be used with Kerberos. The Open Directory Password Server is good for those situations when Kerberos isn’t an option. This can be useful for applications and services that don’t support Kerberos as well as for times when there is a Kerberos failure. The Open Directory Password Server supports a broad range of standard encryption types for interaction with a range of platforms and services. Although it doesn’t offer the secure and single sign-on advantages of Kerberos, the Open Directory Password Server provides solid security that is much better than basic passwords.

By default, when a user’s password type is set to Open Directory, Open Directory will attempt to authenticate the user using Kerberos first and only use the password server in those instances where Kerberos isn’t available. Managed client environment Open Directory offers a rich managed client environment that can be used to secure and define the user environment for all users and computers.

Virtually every aspect of the Mac OS X user experience can be preset for new users or can be permanently defined so that it can’t be modified. When using Mac OS X Server 10.4 (Tiger) with computers running the same Mac OS X release, it is also possible to create preference manifests. These are XML files that can be used to define the preferences settings of virtually any Mac OS X application. Managed preferences under Mac OS X can be set for individual users, groups or lists of computers. Integrating with other directory service platforms Active Directory integration is often the easiest, and there are several easy methods of integration for both Mac OS X computers and Mac OS X Server.

Beyond Active Directory, Open Directory can be integrated with almost any platform that is LDAP-based or supports LDAP queries. In fact, true integration between Open Directory and Active Directory is often done using LDAP.