OpenLDAP on Linux for Apple Clients? 22
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!"
Re:Redundant. (Score:2, Informative)
for linux
and, for the macs
apple discussions pages have some hits. relevent? (Score:4, Informative)
You need to check MacOS X Secrets. (Score:5, Informative)
Integrating Mac OS X with Active Directory [sc.edu] BTW this also includes using secure LDAP authentication!
A quick search at Mac OS X Hints turns up some usefull sources too. [macosxhints.com]
Re:Stream of consciousness (Score:3, Informative)
www.padl.com is one of the best LDAP resources around. Luke Howard's been at this longer than anyone!
try the developers website too... (Score:1)
Look in NetInfo, or just use RFC 2307 (Score:5, Informative)
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
LDAP warning (Score:4, Interesting)
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 (Score:1)
Re:LDAP warning (Score:1)
7.8 Command Line Utilities
Administration of the data in a directory is a sensitive point. Data administration concerns data management with a directory structure and content. The IBM SecureWay Directory server comes with a set of management utilities to assist an administrator in managing the directory's contents.
There are command line utilities that are used to handle large amounts of data, for example, to import thousands of entries in one single step. These utilities include the following:
* ldif
* ldif2db
* bulkload
* db2ldif
Because they access data in the database directly, the tools listed above must run on a directory server. Note that the ldif2db, bulkload, and the db2ldif utilities support the conversion from a specified local character set to/from UTF-8 (see also 4.3, "UTF-8 Support" on page 83).
Another set of utilities are more geared towards handling of single (or a few) entries at a time. These include:
* ldapsearch
* ldapmodify
* ldapdelete
* ldapmodrdn
* ldapadd
These latter tools use LDAP to communicate to an LDAP server, and they can, therefore, be run on a server or a client. They are, therefore, included in the IBM SecureWay Directory Client SDK. Source code for these utilities is provided, too, to allow application programmers to modify them as required or as sample programs to learn about LDAP programming. A parameter allows to specify whether LDAP Version 2 or Version 3 is to be used (the default is Version 2).
Do not entirely trust above advice. (Score:1)
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.
Re:LDAP warning (Score:3, Informative)
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
As for your conundrum: 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
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.
Re:LDAP warning (Score:2)
I hate to be the one to ask.. but.. what is openldap?
I had a look at their site, and read the both FAQ's (Jeez, what a nightmare that is - is there anything worse than that faq-o-matic?).
As far as I understand so far:
* Users authenticate against it.
* It stores user information (So it can be used like a phone book).
Is there anything else it does?
Here you go - OpenLDAP is: (Score:1)
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.
ER No (Re:Here you go - OpenLDAP is:) (Score:2)
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 [ldapman.org] 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)"
WRONG WRONG WRONG (Score:2)
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.
LDAP is hard (Score:2)
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?)