Slashdot Mirror
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!"
Stuff like this shows how non-network oriented Apple really is with their products. Despite claims to the contrary, when it comes down to nuts and bolts Apple falls short. Google does not return anything useful in regards to this question, it's definitely the fault of Apple for not supporting their business customers well that there is no web resource available for this Ask Slashdot query.
It's really not that surprising, though. Apple has always been geared towards publishing houses, whether they be print or online publishing, and not geared towards "Fortune 500" businesses. Their lack of developer support outside of the artistic arena is infamous.
Good luck finding stuff.
I have been pwned because my
try http://discussions.info.apple.com and search on "openldap"
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.
well, for windows, he's probably using pGina
... most likely a pam module
... i forgot the name of the package, but it's listed in one of the SysAdmin mags from a few months ago (w/screenshots)
for linux
and, for the macs
few hits on the developers website too. ADC Search results
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
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!
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.
You just inadvertently proved the first guy's point by giving him bad and incomplete advice from Google.
Don't use tools that default to LDAP v2, use v3 only.
Never bulkload with ldapxxxx tools, they are too slow and may run into server limitations on how many LDAP operations can be performed per client connection.
ldif2db and friends are derived from the umich distribution and have been superseded by the slapxxx family of tools. The IBM code fork may still use ldifxxx tools, though, and there are no doubt others in the Sun, HP and Netscape code forks. I recommend not using any of these with linux, use current OpenLDAP. Use Sun and HP tools only on those systems and don't use Netscape LDAP stuff at all if you can avoid it.
Don't use Microsoft or Novell LDAP tools on other platforms either, unless you can't avoid it. You should definitely use their native utilities if you must support AD and NDS, but try to keep from getting strangled by their "embrace and extend" philosophy. NDS is better than AD if you have to choose.
Use the current OpenLDAP doco, such as it is, and experiment, experiment, experiment. That's the ticket.
Yo, Cliff baby, more of the same. This is actually something that the questioner could conceivably get a good answer for from the /. crowd.
Unlike the usual "how do I get laid" and "how do I do something that's incredibly easy to find on any Internet search engine" type questions.
Thanks for posting it.
It's intended to be OS-independent free software, but it reportedly runs best on linux at this time.
LDAP stands for Lightweight Directory Access Protocol which is a IETF standard for accessing data stored in a hierarchical directory structure such as that used by Microsoft's Active Directory, Novell's Netware Directory Services, and X.500.
X.500 was an ambitious attempt to create a network-accessible data store that would hold all possible data pertaining to humanity in a hierarchical format. The original DAP protocol the X.500 droogies developed was too big and unwieldy, and posited X.500 as the directory. LDAP was born to serve the functions people actually need in real life, and is a trimmed-down version of the original X.500 DAP that is actually useable by people in the trenches.
Modules are available to integrate LDAP into most user authentication schemes. Google for nss_ldap, pam_ldap, pGina, that sort of thing. Sendmail can use ldap, as can ssh, and OpenLDAP readily integrates with Kerberos and TLS for state-of-the-art security.
OpenLDAP itself doesn't actually do the things you mentioned. It uses whatever backend you select (such as Sleepycat) to store the data, and you need pams or nss_switches or the equivalent to authenticate users. OpenLDAP just provides the protocol glue to bind such LDAP-capable gadgets to the backend database of your choice.
You still have to build the database the old-fashioned way, unless your end-users have plugs in their heads and you can suck their ID information directly out of their brains.
Hesiod made sense (we put 30k aliases into HESIOD therefore DNS TXT records) to serve a global directory for 500 email SERVERS (and 20k clients).
LDAP is hard to "get". Trying to read really bad documentation, I struggled. By working with someone who used it a lot, and in the context of getting mail (again) running, I suddenly "got it". The tools out there are generally either useless or too abstract to get a grip on what LDAP does.
Sendmail, Inc, has an LDAP tool through their ProServices group. (Not that you could find out from their web site). Not cheap, it's intended for high end sites and offered from the consulting group for that. Cheaper than Active Directory, once you count machines (2 - a master server that few people access and the slave server that people actually use) and software licenses?
A pretty web GUI lets a secretary add/remove/manage users in LDAP.
Linux, Solaris, MacOS and BSD all authenticate to it, mail is routed with it, it can even store student ID pictures for the librarians to see when the scan an ID. With ACLs, you can only let certain users/places see certain fields so administrators can see addresses (home or school), but anyone on campus can see their email address.
Quota information can be kept in it, pretty much any field you want in a directory could be put in there your your own apps to use (ie. this person can use this door access at this time, but not after midnight). That part's up to you.
As a database, it's not great (though 2.1 and DB 4 are indicating that it's not as bad at writes as previously experienced). As a repository for READING information, in small chunks, with mostly fixed queries, it's great. INFINITELY faster than SQL. I've heard big-shot consultants/ think tanks say that SQL will replace LDAP. These people didn't quite "get" that you can't access SQL server by $COMPANY_of_Choice in a single way. LDAP is a protocol and lets you do that.
LDAP is hard, it's powerful and complex, it scales like a MoFo (2 CPU, 1GB RAM machine handled beating hard on it with several million entries using OpenLDAP 2.0.x and DB3.x. Far more than we expected in tests.
(and I don't know what a GNU desktop is. Been hearing about HURD for several decades. Still waiting. Is someone going to port the BSD userland to Linux just to get stallman to shut up?)
It's a client and server suite that uses the LDAP protocol to talk to a simple database (typically the Berkeley DB) which is usually used to hold user identification and authentication data.
BZZZT. No!. LDAP is a PROTOCOL to access a DIRECTORY
But thank you for your information which will likely confuse many admins and get them thinking about LDAP in the wrong way.
X.500 was an ambitious attempt
LDAP a Lighter weight version of the rarely implemented bloat that is X.500 directory brought to us by the ISO (those euro's who wrote OSI, a clean room replacement for TCP/IP without the burdens of actually writing code; specs were available for $$$$ if you wanted to use it).
To the ex-ISO brit who whined about MAIL: being taken over for email use by Netscape's schema and that it was intended to be for postal mail, I've offered that well, X500 was thought up and imposed on the world and it never scaled well or really worked. It took the UMich team (many went to Netscape) to actually fix it to be where it works, where people can us it without a room full of machines and 20 administrators. The UMich goal was to have machines that people actually have (at the time, 4MB machines) be able to get information. X500 required a high end server to even LOOK at the data. Bloat.
It's intended to be OS-independent free software, but it reportedly runs best on linux at this time.
It is intended to be implemented on computers and runs really nicely on machines with lots of RAM and decent disk. Given that you can hit MILLIONS on a modest (by 2002 standards) machine, while it DOES scale really well on an 8 way machine (Sun, SGI), you generally don't need that. OpenLDAP 2.x screams on Solaris, BSD, Linux and AIX.
LDAP directories on Unix are often implemented using Berkeley/Sleepycat DB on the back end. Why? Cause its fast as hell. You can use SQL, you can use flat text files, if you wanted. You can write your own.
ldapman has some stuff that the guy wrote for Sendmail.net (RIP). Sorta helpful.
A directory entry basically consists of a blob of data lines about a user or machine or whatever. You can then look for those bits of data via structured queries (show me the MAIL entry for the user who's alias is $THIS and who's server is $THAT. Show me the PHOTO entry for the student whoes name is $THIS and whose class in $THEN.).
You still have to build the database the old-fashioned way...
You have to feed the server (not the database) the data somehow. This can be done via perl scripts (and web front ends), it's often initially done with some hand work to create LDIF files. A little perl or awk to merge several points of data into directory entries is done ONCE.
The biggest difference is re-thinking about your data.
You don't think about "I have this alias for that user, I have another alias for that user, I have this alias for a list".
Now you have "I have this user. Among his entries are THESE aliases." The user also has other features: An office, a phone, a picture maybe, vacation (email) information, and other attributes.
"I have this list, it contains these USERS (whose mail addresses might change" and these EMAIL addresses on it (for external users who aren't in your realm of control)"
The best documentation of Apple's LDAP schema I have seen is in Appendix A of the Mac OSX Server admin guide.
0 4d /www.apple.com/server/pdfs/MacOSXServer_AdminGuide _121902.pdf
http://a1776.g.akamai.net/7/1776/51/6dae8bbb980
Despite what you seem to think, the question was NOT "but.. what is LDAP?"
OpenLDAP is a software suite composed of clients and servers that use the LDAP protocol.
As I said.
Your comments pertain to LDAP, which is not what the previous poster was asking about!
But thank you for your display of illiteracy and fatheadedness.