Re: OpenDirectory, DirectoryServices, OpenLDAP architecture questions
Re: OpenDirectory, DirectoryServices, OpenLDAP architecture questions
- Subject: Re: OpenDirectory, DirectoryServices, OpenLDAP architecture questions
- From: Jason Townsend <email@hidden>
- Date: Wed, 16 Mar 2005 16:19:07 -0800
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?
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.
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.
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.
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:
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.
There are at least two cases for password changes:
- a user changing his own password
- an administrator changing another user's password
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.
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.
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden