Slashdot Mirror

MongoDB uses mmap but the similarity ends there. It uses a journal, not COW. It suffers from a number of durability and consistency vulnerabilities. LMDB has no such weaknesses.

http://www.slideshare.net/mong...

This research group at University of Wisconsin cites 1 vulnerability for LMDB, but they were mistaken:

https://www.usenix.org/confere...

http://www.openldap.org/lists/...

Is anyone other than Debian zealous enough to use GnuTLS?

I rarely agree with Howard Chu of OpenLDAP fame, but... http://www.openldap.org/lists/...

You really need to read ITS#5361 as well.

http://www.openldap.org/its/in...

"given enough eyeballs, all bugs are shallow"

Apple had their goto bug in TLS for about 18 months before they spotted it.

GnuTLS and therefore Linux has had their goto bug in TLS since 2005 (9 years) and it's only been spotted now as a result of the bow wave from Apple's disclosure.

First off, the GnuTLS bug is *NOT* a "goto bug" at all, it is a serious design flaw built that way from the start and would really require a rewrite and API changes. Basically it's a "bug" of the authors not really understanding the standards before designing their API.

Second, it is not "only now been spotted" - this bug has been *KNOWN* about since 2008. OpenSSL - GnuTLS considered harmful - Feb 2008 Quite unlike Apple's "bug", this one was identified *6 years ago* and yet still has not been fixed.

They *did* find it, back in 2008... 8 years since then absolutely nothing has been done to fix it.

OpenLDAP Thread - Feb 2008

Except this bug
WAS discovered back in 2008 and ignored.

Sorry, the OSS's mantra that it's more secure because it's peer reviewed is the emperor's new clothes.

From February 16 2008: Howard Chu of OpenLDAP: GnuTLS Considered Harmful

Looking across more of their APIs, I see that the code makes liberal use of strlen and strcat, when it needs to be using counted-length data blobs everywhere. In short, the code is fundamentally broken; most of its external and internal APIs are incapable of passing binary data without mangling it. The code is completely unsafe for handling binary data, and yet the nature of TLS processing is almost entirely dependent on secure handling of binary data.

Incredible that GnuTLS is used anywhere at all. It's just mind boggling.

Why not LDAP?

Not speaking w/ any authority, but afaik LDAP is just an over-the-wire protocol. It says nothing about the underlying database(s) or what the directory services actually represent. That said, Open LDAP and LDAP vs RDBMS

Why not LDAP?

Not speaking w/ any authority, but afaik LDAP is just an over-the-wire protocol. It says nothing about the underlying database(s) or what the directory services actually represent. That said, Open LDAP and LDAP vs RDBMS

References:

http://stackoverflow.com/questions/997424/active-directory-vs-openldap

http://www.openldap.org/lists/openldap-software/200507/msg00185.html

http://blog.is4u.be/search?q=openldap

Oh ... so it's more like an LDAP server, instead.

Wasn't OpenLDAP written on top of BDB?

(Although I don't know how well OpenLDAP handled replication -- the 'many servers' part ... I've only administered the Netscape/SunOne LDAP servers ... which are also key/value stores)

Surely the rise of SQLite [wikipedia.org] has something to do with what you perceive to be Berkeley DB's decline?

Don't tell that to the OpenLDAP people.

But a lot of F/OSS software is developed to solve a particular (maybe rather specific) problem and the suggestion that it could be modified to solve both the original problem and another, new problem winds up getting shot down in flames.

What if the authors of the software in question have what they believe is a good reason (Internet Standards) to shoot down what they think is a bad suggestion?

(notwithstanding the fact that by this time virtually every major LDAP server on the planet except for OpenLDAP supported multimaster replication)

Except that OpenLDAP v2.4.xx now has multi-master replication support: http://www.openldap.org/faq/data/cache/1240.html

That was at the top of my Google search. Did you not know, or did you deliberately leave that out of your "example"?

Even if this support isn't the same as, or as complete as, the other implementations, that fact that it now exists ruins your use of openldap as an example of... wait, what *was* your point anyway? That people can disagree over technical issues, or what is the best way to implement something? That FOSS often places a higher value on standards than proprietary alternatives? And you think thats a *bad* thing?

At least with FOSS you can always fork it and do what you want anyway. With proprietary software, if begging doesn't work, you are SOL.

I've migrated a metric crapload of LDAP apps

Yes, you've migrated them into ActiveDirectory, not another LDAP server.

Here's a little taste of the LDAP-like problems.

http://www.openldap.org/lists/openldap-software/200312/msg00240.html

As my original post states, you are an Active Directory admin. You have made the classic mistake of thinking the *very* limited LDAP functions in AD are similar to running an LDAP server.

THat means making the schema by hand.

No, it does not. If you mean that there isn't an "Active Directory Wizard", that would depend what distribution you use, and you will need to do some tasks to populate the initial DIT (but there are scripts to do this, such as smbldap-initialize from smbldap-tools).

OpenLDAP does not do multimaster replication.

2.4 does.

You will have to manage most maintence tasks by hand, using tools like some Java LDAP UIs, which expose raw LDAP information to you.

Well, there is no standard tool that does everything everyone wants (not all people have the same needs in a directory server ...), but smbldap-tools are decent command-line utilities, and a number of good web front-ends are available (lam etc.). If you set samba up correctly, you can use the Windows NT4 admin tools (User Manager for Domains, available for XP) to manage users.

You will not have an easy interface to 'create users'.

smbldap-useradd joe
works just fine, or any of the tools mentioned above.

It does not take care of DNS. It does not do Kerberos.

It is quite easy to set bind up to use LDAP for reading DNS records, and Heimdal (and MIT since 1.6 I think) can use LDAP for retrieving Kerberos principals (from the same entries Samba etc. use).

If Windows is the only consideration, sure, a Windows server makes sense. However, you really seem to be stuck in 2001 with your descriptions of the options for people who need to consider other desktop operating systems.

That's some kind of contradiction along the lines of "military intelligence." I kid.

Slightly off topic:
Vista desktop + openldap win32 binaries + apache and bind = GNU Windows Server?

openldap on win32: http://www.openldap.org/lists/openldap-software/200705/msg00152.html
apache2: http://httpd.apache.org/download.cgi
kerberos5: http://web.mit.edu/Kerberos/kfw-3.2/kfw-3.2.2.html

Granted, the average win32 admin will hit a wall because Microsoft does not design their product, documents and services for an admin smart enough to DIY.

Openldap/kerberos5/apache2 opens many, many more security/identity/authentication possibilities than Microsoft's active directory.

I'm surprised you need to ask. http://www.openldap.org/

IMHO the future direction taken with Kerberos should be merging the protocol into LDAP (e.g. for the future LDAPv4 revision of LDAP protocol).

Here's my rationale behind this: The problem with Kerberos being a distinct protocol from LDAP is that the distinction causes lots of confusion among the implementors, system architects, developers and administrators. This results in lots of cases where the two protocols are misused.

The correct distinction should be that you use Kerberos for authentication (that is, proving that a user is someone he claims to be) and LDAP for authorization (that is, given an authenticated user, determining information related to granting access to some resources - such as group memberships, possibly some application-specific ACLs etc) and for other data for which a directory is useful (hard to list all possible uses of LDAP, but e.g. mail aliases are a fine example).

But because the protocols are separate and very hard to setup together on a single authentication/authorization/directory server (or a group of servers!), people go along with only one of them, usually using LDAP for authentication instead of Kerberos (see mod_auth_ldap for Apache), effectively prohibiting themselves from implementing usable single sign-on

For an example, let's have a look at available OSS solutions. Apache Directory has Kerberos and LDAP integrated from the start, but it's painfully slow as a server at its current state. A mail server using LDAP for aliases can perform quite a bit of hammering on the LDAP server. MIT Kerberos cannot use LDAP databases. So doesn't Shishi Kerberos, although they plan implementing this in the future. That leaves us with Heimdal Kerberos. Heimdal requires the LDAP server to be on the same machine and support LDAPI connections. So that rules out Fedora Directory Server, whose stable version 1.0.4 doesn't support LDAPI yet (although the CVS development version recently got LDAPI support, finally).

I've tried setting up a Heimdal Kerberos server with OpenLDAP (with SASL2 daemon in the middle), and succeeded, but it was a royal pain in the *ss.

All HOWTOs I've found on the web described a brain-dead design where Kerberos maintains a classic file-based database on its own, separate from OpenLDAP database, and one has to make sure they both are in sync (because it's possible that one can have a user that the other doesn't). In such a setup replication is really troublesome and has to be done using 2 different channels and mechanisms (e.g. LDAP syncrepl + Kerberos' own redundant servers).

I wanted an integrated design, where Heimdal stores its data directly in OpenLDAP.
This way, I couldn't possibly create a Kerberos account without an LDAP account (well, I could if I omitted Kerberos objectclass and attributes, but it would be harder to do and easier to detect). Also, I could use only LDAP's replication mechanisms and easily provide fault-tolerant cluster of LDAP and Kerberos servers.

Unfortunately, the diagram for this setup looks quite daunting for a beginner implementor, as you can see for yourself.

There were also lots of gotchas:

• Heimdal can connect to LDAP as its database only using LDAPI - a networkless LDAP connection over UNIX domain socket. So you have to configure OpenLDAP in a quite non-standard way, and latest

"I would still like to see more about LDAP, authentication and authorization, single sign-on, etc."

I've scoured the web for a GOOD reference for this and have been disappointed (however I haven't looked lately). If anyone know of a particularly good site for this please let us all know. Oh, and please realize that LDAP isn't really the problem. The problem is trying to archive "single sign-on" with LDAP.

OpenLDAP is one such package.
Fedora Directory Server is another.
Heck, you can even use Active Directory *and* Linux.

If you're comfortable with two databases, consider LDAP (OpenLDAP is free) for the call-routing part and an RDBMS (MySQL is already working) for the reporting part.

With a proper OpenLDAP install, you should be able to handle over 15000 queries per second (PDF reference). For redundancy, or if you need more capacity, LDAP replication is straightforward.

As far as keeping the two databases synchronized, it's hard to say without knowing a lot more about your requirements. It may be as simple as periodically dumping the call-routing data from the LDAP server and loading it into the MySQL reporting environment.

the proposed .tel TLD would allow individuals and companies to keep all of their contact information in an easily accessible location.

Wow! If only someone had thought of that before!

One year porting to linux?
I think that the mindless post is your post.

There was Netscape Directory Server for Linux many years ago. By example a link:
http://www.openldap.org/lists/openldap-software/20 0201/msg00054.html

Please inform before sending thse e-mails

I think that Java Directory Server is a better product, and a more mature product. And this is free. (It is based on Netscape Directory Server). I think it is pointless the move of RedHat with Netscape products. I think that they give free, because Sun gave it free.
(Look at http://www.sun.com/ Java Enterprise System, it includes directory server and provisioning, etc)
They can't charge for a product, if there is a better and free alternative.

Regards.

Anyways, let us examine the different components and see how far OSS can take us. Maybe it can't go the whole journey, but if it can do some, then a hybrid solution will work.

Open Groupware, SuSE's Open Exchange and OSER will handle the Exchange part, including support for all those MS Exchange clients, such as Outlook.

That just leaves the Active Directories part. ISC's DHCP supports Dynamic DNS. However, you may want to add in DHCP2LDAP to get a good link between DHCP and BIND. OpenLDAP provides the LDAP implementation part. Kerberos and DNS are easy (although some may quibble with my choice of Kerberos version!)

Provided you're not planning on having both MS Active Directory and the above amalgam running, you should then be set to go with a comprehensive Active Directory lookalike which will interact with client systems in the same way Microsoft's software will.

The problem I found is that there's almost no way of getting from a Linux solution -to- Active Directory. If AD is present, it must be a root server, which Linux CAN pull from.

Do I recommend this kind of a setup? Probably not. The Exchange and Groupware stuff should be fine, but the Active Directory stuff isn't as coherent as it could be and I've heard of nobody who has completely replace AD with an Open Source solution, even though from a purely technical perspective it should be possible.

Open directory is (as I understand it) basically openLDAP with a config file and a nice GUI. Don't get me wrong, GUIs are useful, but if you want to go OSS, cut out the middleman.

Of course since the questioner didn't mention openLDAP to begin with, he's probably better off with a "managed" solution like MS or Apple.

LDAP is the "Lightweight Directory Access Protocol". (simplest example: Start typing a name in an LDAP email client and it will fetch matching names from the LDAP server.) Much more reading at http://www.openldap.org/

• How about that spiffy big Postfix or Sendmail box you've got sitting out there, whose sole purpose in life is to act as a relay? Sure, it'll process millions of messages per day. It doesn't have to do much.
• What if you're running a virus checker like ClamAV or a spam checker like SpamAssassin? Those take up CPU cycles. Sure, delivery is slower, but value was added.
• What if your back end mail system is something like the Citadel groupware platform, where MIME content drives an event handler system? Again, delivery is impacted, but the functionality of the system depends on it.
• What if your org has a global directory and your mail hub is responsible for making complex routing decisions for each message? Again, delivery is impacted; it'll be slower than the mega-fast-box, but mail won't be delivered correctly otherwise!

Fed up with Windows systems management? A Linux conversion may be your ticket away from the daily hassles...

Flame me for this, but Windows is a hell of a lot easier to learn and manipulate for the regular Joe users. In windows, if you want to change settings, you hit Start, Settings, Control Panel and you just select what you want to play with. In Linux, you actually have to know (very well) what you're doing and how to do it. Now compare this. What will common users choose? Ease of use and user-friendliness, or painful, long and extensive research (read: understanding how it works first, then understanding the 3rd party softwares to administrate it, then learning how that one works, then learning the command syntax) before typing shit out in a console?

The article just says "Windows ID management is bad. LDAP is better. Why is Windows' ID management bad? I'm not telling. Why is LDAP better? I'm not telling." It does nothing explain the position the title purposes.

This isn't to say I disagree but calling this article "news" is like calling the OpenLDAP FAQ news.

Finally ! this is the only Open Source Directory that can compare to the features that Active Directory has to offer, especially multi-master replication.

Unfortunately, this will probably mean OpenLDAP will fade into insignificance, but I may be wrong !

This is the 'stronger rope' I needed to hang the guys planning on making Linux authentication depend on MS AD where I work :)

There is no such animal. There is such a thing as object/relational technology. Some common examples of this are hibernate and EJB. These are not alternatives to relational databases. Rather, they serve to persist objects to and from relational databases. They are built on top of relational databases. They do not replace relational databases.

Alternatives to relational databases are LDAP databases such as openLDAP, OLAP databases such as Hyperion, and XML databases like exist. None of these technologies will replace the relational database. It's more about using the right tool for the job. Relational databases work best with operational data. OLAP works best for planning and forecasting. Think of LDAP as a distributed hierarchical database.

Various relational database products have proprietary extensions that may confuse you into thinking that they are alternatives to relational databases. For example, there are extensions to SQL Server that make them seem to act more like OLAP or XML databases.

AD to OpenLDAP doesn't go, because OpenLDAP is just a directory protocol -- I wish people would start to understand that. There is no directly usable management interface, no business logic, no nothing. It is just a protocol....

kerberos is only for authentication

All it does is verify (securely) whether you are who you say you are. Everything else must be done with other mechanisms.

So you want to make sure that certain attributes are only visible over encrypted links? See the section on using the SSF parameter in your access controls in the slapd.conf documentation

OpenLDAP is a very capable LDAP server. I've found very little that it can't do (with some research).

OpenLDAP fully supports kerberos authentication (and many other types) via Cyrus (and maybe GNU) SASL libraries.

See the OpenLDAP SASL Instructions that document how to do it.

If I'm not mistaken, according to this official OpenLDAP Admin Guide, OpenLDAP supports SASL framework, which, in turn, supports Kerberos V authentication via GSSAPI. It took me some time to put all the pieces in the right places on my Gentoo server installation, but after some Google searching, I finally had OpenLDAP over Kerberos authentication, and on top of all that, an AFS cell (using OpenAFS, of course).

I'm confused, are you attempting to refine your security to the application level or looking to integrate your applications with a centralised security model?. These are separate and distinct requirements!

For free authentication look to LDAP or RADIUS.

Wow, you think somebody would have come up with a solution for this by now...

After that, it depends on my OS. For most of the Linux installs I do, the next few things I install will be MySQL, OpenLDAP, Apache, and PHP, which takes care of most of my needs. My Windows box (which, I admit, I use at home) is a little more fun:

2. iTunes
3. Whatever freeware Shisen-Sho app I can find
4. Starcraft
5. Several games later, OpenOffice.org

Let's be honest: does a computer really need anything else? I certainly don't think so.

"Microsoft was kind of pushing Passport for a problem that didn't exist..."

The problem of single sign on (SSO) does exist, particularly in the corporate world. Vendors implimenting Web Portals (MS SharePoint, Sun Java System Portal Server, BEA WebLogic Portal, Vignette Portal, etc...) have a particular interest in SSO and identity management via Identity Services to present a single interface to various systems in an enterprise.

My main problem with MS Passport is that it's Microsoft's version of a standard rather than a community standard. Applications can connect via MS's SDK rather than publishing the standard. Using Open LDAP, Sun's Identity Server, etc... will generally follow open standards and have better compatibiltiy to other open source/standard applications.

Is there an open-standard directory service that can replace AD, but windows machines can still connect to? Has anyone written an 'OpenDirectory -> pseudo-AD / NT Domains' gateway?

We have no problems with an OpenLDAP server in conjunction with pGina LdapAuth plugin for windows...

I've been on both sides here. I've done the OpenLDAP database of users, with OS X desktops an Samba fileservers, Sendmail / QPopper / IMAP mail setups for a few thousand users. I've also done the Win2k3 servers with AD and Exchange, and WinXP desktops, again for a few thousand users. The bottom line is that they both serve the same roles: user management, mail, fileserving.


You've got a great point, there. The MS way is tightly integrated, and that really shows off in the provisioning/de-provisioning functions. You'll never get that kind of tight integration in the Open Source world, but you can get close with "standards". Sadly, standards for leveraging LDAP for mail and file service lag way behind. For account provisioning, we have the experimental RFC 2307 for storing NIS information as objectClass posixAccount. There are only a couple of expired Internet-Drafts for mail. For file servers, there's basically nothing.

All this is not to say that standardization is not the way to go, it's just that there's still a ways to go. And the people who know how to make this sort of solution work -- people with lots of practical, large-scale, real-world experience -- are just not the people working on "standards."

:w

Jabber also supports SSL and is extensible (so can support things like group-conference room logging).

You'd be crazy not to re-use all the LDAP protocol work that OpenLDAP does for you. In addition, writing backends is not as hard as you infer.

In your case, you can probably use the Perl backend plugin, and base your custom thingy on:

openldap.org/cvsweb.cgi

Run the openldap server on the same machine that's running your database right now and you're done.

nicl . -create /users/yourusernamehere shell "/bin/tcsh"

or whatever shell you want to stick in between the quotes, or use the NetInfo Utility to go and tweak it in a GUI...

Maybe that's a typo. (I don't have my OSX laptop with me to double check at the moment). But how I did this very same thing, was the way described in this article. The command they describe in the article reads:

niutil -createprop . /users/joebob shell /bin/bash

That article I linked to above also has info on how to do it the GUI way with the netinfo utility. Trying to do it the standard Linux "chsh" way or or the "vipw" way gets you nowhere as OSX is yp based (yp is another name for NIS).

Although I hear they may be moving to openldap for future releases of the MacOS as part of their "Open Directory" initiative. OD looks like it may be a nice alternative to the Windoze version of the same thing. Of course, MS pretty much got their idea for AD from Novell's directory services. Can't them boys think up anythin' on they own?

Funny, when I started this post I think I was ontopic. What were we talking about again?

<cough>openldap</cough>

But seriously, there isn't anything directory-like you can't do with LDAP. It's not a perfect system, but it's pretty sweet.

Here are some open source projects that I've been involved with. Fugu is a graphical wrapper for SFTP & SCP on Mac OS X. I consider it successful because many universities (my peer group) recommend it to their users. Also, one of our success "feathers" is the number of localizations that people have contributed: Spanish, Japanese, German, and Dutch.

radmind is a combination filesystem integrity checker (tripwire) and manager in one package. Again, many (a couple hundred) universities use it. It's important to note that it's less important to me that other groups also use it. It's my peer group that interests me.

I'm also the original author of netatalk. I consider it a success for a couple of reasons. First, it's old. Second, I no longer work on it at all, but there's an active group that continues to make releases. Those are both success "feathers".

Finally, my group wrote the reference implementation of LDAP, and our software is the basis of openldap. The "feather" in this case is having been part of the group defining the LDAP standard, something that many vendors and many packages now use.

:w

The standards exist, but no one has written the server.
You can't really blame them since the Calendar Access Protocol (CAP) which is going to be the IMAP+SMTP of Calendaring, providing synchronous calendaring to clients is on it's 10th draft. Read this email if you have lost hope that the IETF would have calendaring anytime soon. Appearently draft 11 is coming soon and it will be the last one. So it looks like CAP will be finalized RSN. (Thank God, this thing was becoming like Duke Nukem Forever)

You could poke a stick at the OpenCap Server project and see if you get a response. But I haven't heard anything in months.

I don't know what's up with the Libical guys. The mail archive has been dead since December 16. Of course some of them are working on Free Association which is supposed to be a server and client. Since the mailing lists for libical seem dead I couldn't tell you what the status of CAP support currently is. My understanding was that they had been keeping up with the drafts, but since the 10th one was released about a month ago, I have no idea what the current status is.

Mozilla should be getting Calendaring in 1.4. IIRC, the calendaring uses libical. The College of Charleston computing dept has taken on enhancing the client (Go Cougars!). Hopefully they'll be putting CAP support in.

If anyone wants to know what it would take to write a calendar server and put an end to the Notes/Exchange duopoly in groupware, visit the Calendaring and Scheduling Working Group of the IETF. These are the guys that have brought you iCAL (RFC2445), iTIP (RFC2446), iMip (RFC2447), iCal Locating and LDAP (RFC2739) and the Guide to Internet Calendaring (RFC3283).

Read the iCalendar Guide then all the other documents at the site. Next go write the server. Then make sure Mozilla's Calendar client works with it, and email me so I can go replace exchange servers with it.

If you find a solution that does not use CAP, beat the authors with a ClueStick till they give in and write something that uses IETF protocols so we can interop with it.

Personally I'd really like to see the Cyrus IMAP server get a CAP piece put in. Combined with OpenLDAP and Mozilla as the client, it would be a Notes/Exchange killer.

While I'm sitting here making demands from the Open Source messaging community, why the hell doesn't Mozilla get SIEVE (RFC3028) support so we can have a standard for server-side email filtering rules, Cyrus supports it in the IMAP server. Oh, and I also want write support for LDAP address books in Mozilla.

To answer the original question, I think it's coming, slowly, but coming. Lord knows, I've only been waiting for 4 years or so.

As for your NIS question, I would be very tempted to use LDAP. NIS is horribly horrible whereas LDAP is much easier to understand, implement, support and interoperate.

Check out LDAPGuru and OpenLDAP.

As for the hardware, go for the biggest, baddest you can. Assuming you use RAID on your servers (make it hardware RAID) can you survive with only 72 GB of storage ?

Anyway, I'll have a think about your hardware some more.

cheers, Tim

Apple haven't broken LDAP by modifying it. They are using OpenLDAP, which is published under an open source licence.

All they have done is provide a bridge and NetInfo schema such that current NetInfo account information can be published via LDAP directly from the NetInfo database. They're not the bad guys here.

Apple haven't broken LDAP by modifying it. They are using OpenLDAP, which is published under an open source licence.

All they have done is provide a bridge and NetInfo schema such that current NetInfo account information can be published via LDAP directly from the NetInfo database. They're not the bad guys here.