site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com 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. Essentially DirectoryService acts like a combination of pam and the name-switching service on linux? 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. 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. For more on SASL, check out CMU's list of RFCs here: There are at least two cases for password changes: - a user changing his own password - an administrator changing another user's password One of my goals is to somehow get a pam module created for linux to interface with OpenDirectory. LDAP is adequate for many things, but talking to the SASL repository would be even better. _______________________________________________ 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... This email sent to site_archiver@lists.apple.com DirectoryService provides an abstraction for reading directory data, as well as authentication (including secure authentications). It also handles write operations like creating and modifying records as well as changing passwords. So I think your statement is correct, but I believe this is a superset of what PAM and the name-switching service on Linux are providing. I have observed that on occasion when the ldap server goes weird, things slowly start to not work. Eventually, if left long enough, even DirectoryService freezes. If I kill it, it won't restart, but just freezes immediately. At this point, any application that makes any libc call that goes to lookupd or any DirectoryService call blocks indefinitely. This almost seems like a deadlock. IE the DirectoryService system cannot respond because LDAP is not responding (still accepting connections but blocks indefinitely). And at this point I cannot get lookupd or DirectoryService to restart because they both need to do some call that depends on LDAP. So it is kind of circular. The only way I can break the cycle is if I kill lookupd, DirectoryService, PasswordService, and slapd (whatever is still running) all simultaneously. Only then does the whole system unstick so that I can get slapd and all the other parts of OpenDirectory running again. In this case PasswordService won't start automatically so I have to start it manually. Have you tried sampling the various daemons when you get into this state? In 10.3.x, DirectoryService and lookupd are started by mach_init and should restart automatically. PasswordService should be restarted by watchdog. slapd is started by a startup item so you would need to restart it manually if you killed it. http://asg.web.cmu.edu/sasl/sasl-ietf-docs.html So essentially all an opendirectory client (say an iMac) uses is straight LDAP and SASL protocol? How are things like authenticating to change a password handled (the auth flag thing you were talking about)? Changing passwords is actually a fairly complicated topic once you get into the details... for the specific case of Password Server, it is necessary to first authenticate using the DHX authentication method to negotiate a session key and establish an encrypted channel, then the new password is sent over that encrypted channel. This falls more under the "additional commands" I referred to above as there is nothing in SASL for password changes. For the first case, there is a kDSStdAuthChangePasswd authentication method in Directory Services which allows the client to specify the old and new passwords (which is probably what you'd want to do from a PAM module I suppose). This does not require the authOnly flag to be set to false since it is a "one-shot" authentication method that includes the necessary credentials to make the change. In the case that you are an administrator using Workgroup Manager for example, the Password Server node reference is held onto by the LDAPv3 plug-in when authOnly is false. This allows that existing encrypted channel which was established when the administrator authenticated to be reused for set password operations that happen later on. This is handled internally to the LDAPv3 plug-in, so a DS client only needs to call dsDoDirNodeAuth using the kDSStdAuthSetPasswordAsRoot method (essentially, set the password with current credentials) in this case. Michael Bartosh's suggestion of using Kerberos works great if you have Kerberos set up. You should be able to change passwords and authenticate through Kerberos. It would be possible in theory to create a PAM module based on the DSPasswordServerPlugIn project that uses the Password Server to do the same thing as well. -Jason smime.p7s