site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com From: Michael L Torrie <torriem@chem.byu.edu> I was referred to this list by Apple's tech support. I'm seeking to better understand how the parts of OpenDirectory all fit together. So here's my current understanding of how OpenDirectory is working: My questions so far are these: 1. Are my understandings so far correct? You're partially correct. For more on SASL, check out CMU's list of RFCs here: http://asg.web.cmu.edu/sasl/sasl-ietf-docs.html -Jason _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Hopefully I can help explain things some... despite our best efforts on documentation it seems there are always some questions left unanswered. I'm assuming you have seen the Open Directory API (also known as the Directory Services API) documentation already? http://developer.apple.com/documentation/Networking/Conceptual/ Open_Directory/ 1. netinfo provides a bridge between libc posix api calls (getpwnam, etc) and the OpenDirectory API provided by DirectoryService 2. DirectoryService communicates with OpenLDAP to get name switching information (uid-uidNumber mappings, user information, etc) and directly with PasswordService to do authentication. DirectoryService will not do an actual LDAP bind to authenticate a user in this case because the user is an OpenDirectory user and thus has information in the Password server. 3. OpenLDAP talks to PasswordService whenever asked to perform a SASL bind via standard LDAP protocol. This only occurs if the user in question is an OpenDirectory user. If not, and the user has a normal userPassword field, the bind is performed against that. DirectoryService is a daemon which provides various directory data to the rest of the operating system from a variety of sources. These are provided by plug-ins which use a common API. Current plug-ins include LDAPv3, NetInfo, BSD flat files and NIS, and others. NetInfo is a directory system which originated with NeXT and is most commonly used for the local directory information on every Mac OS X system. It also supports serving information over the network. Maybe the source of the confusion for item (1) in your list is that the "netinfo" project available through Darwin provides not only the NetInfo daemons and tools, but also lookupd. lookupd services many of the POSIX style APIs for looking up information on users, groups, mounts, hosts, services, etc. For example: getpwnam(), getpwuid(), getaddrinfo(), gethostbyname() and so on. There is a plug-in to lookupd called DSAgent which calls the Directory Services API and provides information from the DirectoryService daemon to clients of lookupd. For the following discussion, I'm describing how things work for a typical user in an Open Directory LDAP server. When authenticating as a Password Server based user in LDAP, there are two plug-ins involved inside DirectoryService. There's the LDAPv3 plug-in, which looks up the user record and looks for AuthenticationAuthority and Password attributes. In this case there is an authentication authority present which indicates a tag of ApplePasswordServer as the first value. Since this is a Password Server user, the PasswordServer plug-in is called with information from the AuthenticationAuthority data to perform the authentication. If the cleartext password was passed in by the client of the Directory Services API, the plug-ins can use the best authentication method available to verify the password. One extra wrinkle to this is the "authOnly" flag which is passed to dsDoDirNodeAuth(). This indicates whether the authentication is purely a password verification (in which case authOnly is true), or it is also intended to change the access to the node reference based on that authentication (in which case authOnly is false). The first case would apply to a mail server checking the password for example. The second case would apply to an administrative tool authenticating to make changes, such as dscl or Workgroup Manager. In the authOnly false case, there is a second authentication that must be performed to change access to the LDAP server. This is done using a SASL bind if possible. So in the case we're talking about, the second auth will be a CRAM-MD5 authentication through LDAP. On the backend, the password hashes are not stored in the LDAP server's database, so it must perform a "pass through" authentication to the Password Server. This is done in the case of a cleartext bind or a CRAM-MD5 SASL bind. 2. What protocols do remote OpenDirectory clients use to communicate with the server? If authentication is done using PasswordServer, is this done over a tcp/ip port other than ldap? Where are these protocols documented? As described above, LDAPv3 is used in addition to the Password Server protocol. The Password Server protocol is based on SASL for any challenge response authentications, and there are some additional commands specific to it. Currently there is no documentation but the Password Server plug-in source is available from the DSPasswordServerPlugin project. Password Server uses either port 3659 or 106. 3659 is the preferred port for current implementations. This email sent to site_archiver@lists.apple.com