[schwa]

Has anyone tried getting OS X client machines to authenticate user login against an LDAP server (other than NetInfo on OS X Server)?

I'd like to have our users auth against our instance of iPlanet. According to this article, Kerberos is required, which would require purchasing an additional plug-in for iPlanet.

Are there other paths to pursue?

[nonhuman]

One of my projects over the summer was to try and get this working on 10.1 so we migrate our macs over to os X and get all of our machines authenticating with the same method. Unfortunately I wasn't able to get it working in 10.1 within the time frame we had and so, although I'm sure it's possible it's a huge pain in the ass. I haven't tried in 10.2 yet because we've basically dropped LDAP for now, probably until next summer, but from what I've heard it should be relatively easy to get working in 10.2.

I seem to recall something about the default authentication methon in 10.2 being LDAP instead of NetInfo because they wanted to use a larger standard for better compatibilty. Does anyone know if this actually happened?

[piracy]

No, you don't need Kerberos; you can natively autheticate against LDAP as long as your LDAP server provides authentication services (LDAPAUTH). You'll add the server to Directory Access, map the required attributes, enable it as an authentication agent, and you'll be good to go. If your server uses a certificate for security, you'll have to get the cert and add a TLS_CACERT line to /etc/ldap.conf. This whole process DOES work: if it doesn't work on your first try, don't give up...it's just due to a typo or misconfiguration somewhere. The attributes that minimally need to be defined are:

RecordName -> uid
RealName -> cn
UniqueID -> uidNumber
PrimaryGroupID -> gidNumber
NFSHomeDirectory -> homeDirectory

Note that the LDAP attribute names don't matter; these are just common ones. If you don't have numeric uids and gids or home directory properties on your LDAP server, with 10.2.2, you can now statically map attributes by preceding a literal value with #. For example, on a generic machine that just has a common home directory, you might map RecordName and RealName, but statically map something like this:

RecordName -> uid
RealName -> cn
UniqueID -> #3000 (any unused local uid)
PrimaryGroupID -> #3000 (any unused local gid)
NFSHomeDirectory -> #/tmp/guest (any local, or network, home directory)

That would allow authentication, but just dump users into a generic home. If you need to have unique home directories, etc., hopefully you've already added numeric uids, gids, and home directory attributes to your directory.

Open Directory (which is a name for a pluggable directory services framework, of which LDAP is one) is the directory services layer. NetInfo and LDAP run side by side on Jaguar; but yes, NetInfo is being replaced by LDAP whenever possible, and going toward pure LDAP is the goal. Of course, OS X will support other directory archiectures as well via Open Directory.

[Oneota]

We're also trying to get LDAP authentication working at our institution.

Thus far, we've gotten it to recognize our user accounts. Now we're having trouble getting home directories to work. Our setup is this:

Each user has a home directory on a file server that's serving AFP using Netatalk. Each mount point is the same, called "My Home Directory", which points to their actual home directory on the same machine. The machine in question is a Sun Solaris box, which is also serving SMB, NFS (which we'd rather not use), etc.

This allows us to have a unified home directory regardless of platform, but it's proving to be very difficult to get Mac OS X to automount it.

What kind of information do we need to store on the LDAP server (and what does it need to map to on the client) to have OS X automount "afp://username:password@servername/My Home Directory" and use it as the home directory for the user who's currently logging in?

We've got uid/gid information already, and it won't be difficult to populate the LDAP server with home directory info, once we figure out the necessary syntax. Everything we've seen thus far seems to be leaning towards using NFS, which we're really trying to move away from.

Thanks!

[Oneota]

Originally posted by Oneota:
We're also trying to get LDAP authentication working at our institution.

Thus far, we've gotten it to recognize our user accounts. Now we're having trouble getting home directories to work. Our setup is this:

Each user has a home directory on a file server that's serving AFP using Netatalk. Each mount point is the same, called "My Home Directory", which points to their actual home directory on the same machine. The machine in question is a Sun Solaris box, which is also serving SMB, NFS (which we'd rather not use), etc.

This allows us to have a unified home directory regardless of platform, but it's proving to be very difficult to get Mac OS X to automount it.

What kind of information do we need to store on the LDAP server (and what does it need to map to on the client) to have OS X automount "afp://usernameassword@servername/My Home Directory" and use it as the home directory for the user who's currently logging in?

We've got uid/gid information already, and it won't be difficult to populate the LDAP server with home directory info, once we figure out the necessary syntax. Everything we've seen thus far seems to be leaning towards using NFS, which we're really trying to move away from.

Thanks!

bump

[el_humpo]

A client of mine has a few Linux and Mac OS X machines connected to a Linux LDAP directory. All of the machines use NFS to grab their home directories from the Linux server, and it works great.

If you want to use AFP shares (although I'm not sure what advantages they have over NFS), the mount command can use the afp protocol (mount -t afp server:/path/to/share /local/path).

Throw the share info in your /etc/fstab or write a /Library/StartupItems script to mount the share at say, /mnt/Users. Then just set the users' home dirs to be /mnt/Users/username, you should be good to go. See the man pages for mount and mount_afp for more info including Kerberos auth.

[Oneota]

Originally posted by el_humpo:
A client of mine has a few Linux and Mac OS X machines connected to a Linux LDAP directory. All of the machines use NFS to grab their home directories from the Linux server, and it works great.

If you want to use AFP shares (although I'm not sure what advantages they have over NFS), the mount command can use the afp protocol (mount -t afp server:/path/to/share /local/path).

Throw the share info in your /etc/fstab or write a /Library/StartupItems script to mount the share at say, /mnt/Users. Then just set the users' home dirs to be /mnt/Users/username, you should be good to go. See the man pages for mount and mount_afp for more info including Kerberos auth.

Thanks for the info; however, there's a problem..

Our AFP server uses the same sharename for everyone, but everyone gets a different share at that location, depending on their login.

So user A's home directory is at afp://servername.schoolname.edu/My Home Directory, and user B's home directory is also at afp://servername.schoolname.edu/My Home Directory

So we can't just mount afp://servername.schoolname.edu/ at /some/local/path and specify people's path to that within the LDAP info; we need OS X to be smart enough to automount the same share location for everyone, using the credentials they used to log in.

The advantages of AFP over NFS are mostly security-related -- our sysadmin doesn't trust NFS very much. But also, using NFS breaks anything that relies on the resource fork, which we'd rather not do.

[el_humpo]

Ohhh...hrm. That is a problem. Maybe you could try sticking a script in each user's Login Items that would run the mount command.

The only problem is if OS X looks at the home directory before running login items. You'd have to find out the exact sequence of events that occur during login.

[Oneota]

Originally posted by el_humpo:
Ohhh...hrm. That is a problem. Maybe you could try sticking a script in each user's Login Items that would run the mount command.

The only problem is if OS X looks at the home directory before running login items. You'd have to find out the exact sequence of events that occur during login.

Ya; if OS X can't find the home directory right away, the Window Server dies and dumps the user back to the login screen.

I suppose we could try revamping the Netatalk server to allow a guest mount at the root of the home directory hierarchy, then specifying pathnames from there. Couldn't hurt, I s'pose.

It just seems weird to me that there's no way to do what I want to do. It's such a natural way of doing authentication/home directory management that I'm surprised there isn't support for it built into the OS.