[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP for Mac OS X Login and Authentication
>1. OpenLDAP's slurpd will not work due to the OS X threading scheme. (I
>don't need slurpd, so I haven't spent any time trying to figure out how to
>make it work yet.)
FWIW, a buildable version of OpenLDAP for OS X is check-outable from
the Services/ldap project in the Darwin CVS repository. As soon as threads
are fixed in a GA release (10.1?) I will re-enable threading in the top-
level makefile.
>4. The LoginHook and LogoutHook parameters for customizing loginwindow do
>not work (official word from Apple) and ~rumor says~ they will be removed
>from future OS X releases.
As I pointed out in my other message, these are irrelevant. The
LoginAuthenticator parameter (from memory) is the one you want; the API
is noted in the Libraries/Other/pam_loginwindow project in the Darwin
CVS repository, and I suggest that you really want to get this PAM
shim working first before writing arbitary loginwindow authenticators,
as it is likely that Apple will switch to PAM (or something very close)
in a future release of OS X.
>5. lookupd is supposed to allow you to change the order of lookups for
>authentication. It doesn't. On a Mac OS X Development list, it has been
>suggested that looking at, and modifying, lookupd's source might be the way
>to go, but I haven't done this yet.
It does. Lookupd is highly configurable. See lookupd(8).
>6. I have posixGroup and posixAccount objects for the people in my OpenLDAP
>database. (Right now I just have the userPassword field MIME encoded. I
>haven't checked which encryption method Mac OS X uses.) They work fine from
>the command line and from test apps I've written.
Mac OS X uses crypt(3) authentication for UNIX accounts, although if you
are using our PAM port you can choose not to use crypt(3) passwords. I
don't quite see how the encoding of the userPassword attribute is relevant to
the encryption method.
-- Luke
--
Luke Howard | lukehoward.com
PADL Software | www.padl.com