OpenLDAP on Linux for Apple Clients?

groovemaneuver asks: "I've managed to get a working OpenLDAP directory running on my network. Linux, Windows, and Apple boxes are all happily authenticating. I have imported the 'apple.schema' file to the LDAP server from one of my Macs, but I cannot seem to find any info on the proper syntax for the various apple schema attributes. Anyone have any idea where one could find this? This is the one obstacle keeping my network from having a single source of authentication, and I'm sure this info would be useful to more than just myself. Thanks!"

Comments

apple discussions pages have some hits. relevent?

[davidyorke]

try http://discussions.info.apple.com and search on "openldap"

You need to check MacOS X Secrets.

[PorkCharSui]

Since most users are users are not using LDAP on Jaguar, Apple does not tend to document the steps necessary to set it up. Jaguar Server on the other hand is a different question though.

Integrating Mac OS X with Active Directory BTW this also includes using secure LDAP authentication!

A quick search at Mac OS X Hints turns up some usefull sources too.

Re:Redundant.

[Anonymous Coward]

well, for windows, he's probably using pGina

for linux ... most likely a pam module

and, for the macs ... i forgot the name of the package, but it's listed in one of the SysAdmin mags from a few months ago (w/screenshots)

Look in NetInfo, or just use RFC 2307

[plsuh]

Apple's version of OpenLDAP uses NetInfo as its backing store -- the apple.schema file merely exports the contents. Go to a Mac OS X Server machine and look at the values it puts into NetInfo. This will give you examples of what you need to put into the corresponding LDAP server entries on your Linux server.

Probably easier is to just use the LDAP values you already have in the RFC 2307 schema for your Linux machines, and set the Mac OS X machines to use the RFC 2307 schema by using the Directory Access application.

--Paul

Re:Stream of consciousness

[nbvb]

Wish I had mod points today. Sadly enough, although lines 2-5 are off topic, lines 0 & 1 absolutely are.

www.padl.com is one of the best LDAP resources around. Luke Howard's been at this longer than anyone!

LDAP warning

[sofar]

After 4 years of professional experience in running routers, general multipupose servers and all the way to full GNU desktops, I decided to try to install a LDAP server so everyone here can keep a joint company address book.

Bad idea

almost a year later this project is still not finished. I've prolly stumped into this once a month and spent a days reading and trying to figger out how to get the backend bootstrapped. No such luck.

I've completely dropped the idea of having LDAP as a database server because of this and I'm very disappointed because of it. In the end you can get the software everywhere, the user-howto's are sublimely stupid (open netscape and click "my addressbooK"), but there is no adequate support, help or whatever information about what to do when you have slapd running, but no data in there yet.

I've no time to dig into this deeper, but I think LDAP should be shot dead for this. I hope you don't fall into the same pifall I did.

Re:LDAP warning

[Ashurbanipal]

I'm sorry you couldn't get LDAP going. I am just finishing up implementation here and it looks pretty sweet - we've got Samba, Apache, and Linux all using the same OpenLDAP database, and we are going to integrate HP-UX as well if possible. This allows us to have digitally signed work orders and help desk trouble tickets without setting up a bunch of crypto stuff that the users would invariably screw up due to lack of crypto knowledge.

Your experience highlights the problem with the technology - it's new, raw, fast-moving, and there is a tremendous amount of conflicting and poorly organized documentation that can be physically painful to try to sort out.

I never found any "how to" that relected the current state of the art - I found how-tos for the current version of samba and an old version of OpenLDAP, or the current OpenLDAP and older samba, etc. ad nauseum, but nothing totally up-to-date. You have to be a bona-fide hacker to get it going at this point in a real production environment.

A couple of small examples: Red Hat 7.3- doesn't ship LDAP-enabled RPMs, you have to unroll their source and modify the specfile, then roll your own samba-ldap .rpms, or give up the advantages of RPM package management. More subtly, the modified IDEALX script they ship for migration from /etc/group to OpenLDAP has a subtle flaw - it takes the members of the group, adds them to a list that also contains the name of the group itself, then they strip out all duplicates with a CASE-INSENSITIVE uniq function. This means that when you have a group ADMIN that contains a user named admin, the user is silently, secretly removed from the group during your migration process. There are other, similar subtle traps as well, that you really have to be a hacker to catch on to.

As for your conundrum:

no adequate support, help or whatever information about what to do when you have slapd running, but no data in there yet.

You write scripts (using perl (or awk if you have uberhacker chops)) to turn your existing data into LDIF format as defined by your schema files (if slapd runs you have schema files) turn slapd off, and use the slapadd program to batch-load your LDIFs into the database. Then turn slapd back on again, put nss_ldap in your name service switch configuration and pam_ldap in your pluggable authentication modules configuration, and you are up and running.

You don't use ldapadd on the running database because it's insufferably slow. LDAP databases are optimized for READ access not WRITE access which makes sense if you think about it. Use slapadd with the daemon turned off instead.

And don't put your root and daemon accounts into LDAP. Have them in the local /etc/passwd with MD5 shadow passwords enabled, so that you can function temporarily if you somehow hose your LDAP infrastructure (if you never make mistakes, you're not doing anything innovative). This also allows you to have separate root passwords on your machines (which is wise) but requires you to have a slightly more complex PAM and NSS configuration.

Integrating samba gets harder. You have to learn how to protect the database, which is still a "trail of errors" technique even if you know backus-naur, but it's essential because the MS-windows password hashes are trivially crackable.