Filter
Top Products
Other directory services store authorization information outside of the service. By providing an interface
between clients of directory services and the directory services themselves, authorization information that
is stored outside of the directory service can be shared. For example, you could design a system that controls
authorization based on a common token (such as a user entry in a common directory) so that when an
administrator creates, deletes, or modifies a token, all services use that same token for authorization.
Accordingly, the Open Directory dsDoDirNodeAuth function’s inDirNodeAuthOnlyFlag parameter tells
the plug-in whether the proof of identity process is being used to establish access to the foreign directory
or whether the proof of identity process is being used only to verify a password.
Here are some ways that could be used to establish an identity that is authorizedto access a foreigndirectory:
■ have the Open Directory client use a preference to establish a “configuration” identity that can access
a given directory
■ configure the Open Directory plug-in with identity information
It will be necessary for the administrator of the foreign directory to set up, provide, or configure an identity
with sufficient access so that a service or plug-in can access or modify all of the necessary information in the
foreign directory. Allowing anonymous read access is an alternative to storing a username and password on
each client machine. Whether this is possible depends on the directory server in use.
Mac OS X v10.4 optionally uses trusted directory binding, which establishes a trust relationship between a
client machine and the directory server.
Directory Native Authentication
Open Directory supports a mechanism that frees Open Directory clients from having to provide specific
information about a particular authenticationmethod. This mechanism is called directory nativeauthentication.
When using directory nativeauthentication to authenticate a user to a node, the Open Directory client passes
to the Open Directory plug-in the user’s name, password, and an optional specification that cleartext is not
an acceptable authentication method.
Upon receipt of the authentication request, the Open Directory plug-in determines the appropriate
authentication method based on its configuration (if the plug-in is configurable) or on authentication methods
the plug-in has been coded to handle. When the authentication is successful, the Open Directory client
receives the authentication type that the plug-in used.
When cleartext is the only available authentication method, the plug-in would deny the authentication if
the Open Directory client specifies that cleartext authentication is unacceptable.
Directory Proxy
In previous versions of Mac OS X, an application could only open an Open Directory session with the local
DirectoryService daemon. The Open Directory function dsOpenDirService is responsible for opening local
Open Directory sessions and returning an Open Directory reference that the application passes to subsequent
calls of Open Directory functions.
With Mac OS X v10.2and later, applications can open an authenticated and encrypted Open Directory session
with a remote DirectoryService daemon overTCP/IP.The Open Directory function dsOpenDirServiceProxy
is responsible for opening remote Open Directory sessions. As with dsOpenDirService,
dsOpenDirServiceProxy returns a Open Directory reference that the application passes to any Open
Open Directory Overview 21
2007-01-08 | © 2007 Apple Inc. All Rights Reserved.
CHAPTER 1
Concepts