Search this site





OpenLDAP authenticating against saslauthd

I've been doing research on the internets trying to get OpenLDAP to allow simple binds that can authenticate against Kerberos. Turns out the default SASL support is to only handle GSSAPI when talking to Kerberos V servers. This means you can only authenticate if you have a kerberos tgt.

Problem with SASL/GSSAPI is that address book clients aren't going to support much beyond simple authentication over SSL. Thusly, we need a way to use a simple bind over SSL and still authenticate against Kerberos.

The LDAP Server's slapd.conf has the following to translate between gssapi auth DNs and real user object DNs:

authz-policy from
authz-regexp "^uid=([^,]+),cn=gssapi,cn=auth" "uid=$1,ou=Users,dc=csh,dc=rit,dc=edu"
This allows GSSAPI authentication:
nightfall(~) % ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error:  Miscellaneous failure (see text) (open(/tmp/krb5cc_1001): No such file or directory)

nightfall(~) !1! % kinit psionic
[email protected]'s Password: 
kinit: NOTICE: ticket renewable lifetime is 0
nightfall(~) % ldapwhoami
SASL/GSSAPI authentication started
SASL username: [email protected]
SASL installing layers
Result: Success (0)
I have a TGT and can authenticate to LDAP over SASL (my ldap.conf defaults to sasl+ssl). However, when you try to do a simple bind:
nightfall(~) % ldapwhoami -x -D 'uid=psionic,ou=users,dc=csh,dc=rit,dc=edu' -W 
Enter LDAP Password: 
ldap_bind: Invalid credentials
On the slapd side, you'll see errors like:
==> bdb_bind: dn: uid=psionic,ou=users,dc=csh,dc=rit,dc=edu
SASL Canonicalize [conn=0]: authcid="[email protected]"
SASL Canonicalize [conn=0]: authcid="[email protected]"
SASL [conn=0] Failure: Could not open db
SASL [conn=0] Failure: Could not open db
Googling around will tell you that lots of people put the following in their "slapd.conf" files:
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
Now, you'll recognize that this format of "token: value" doesn't match the normal slapd.conf. There's a reason for this: This isn't OpenLDAP's slapd.conf file. It's the config file for SASL! From what I gather, saslauthd is working similarly to the way PAM works, in that it sees a service trying to use it and uses that particular service's config file. I believe saslauthd comes with a standard Sendmail.conf for example usage.

It took me several hours to find this fact out. My slapd SERVER config file is located here:

While the SASL "slapd.conf" authentication config file is located here:

If you can't find the right place, look for 'Sendmail.conf' somewhere near where you installed sasl or saslauthd.

Anyway, once we've added this magic config file and told it to use saslauthd, the SASL library LDAP's slapd is using will now attempt communication with saslauthd over the /var/run/saslauthd/mux socket. I ran saslauthd like this:

/usr/local/sbin/saslauthd -a kerberos5 -d
The directory, /var/run/saslauthd was owned by 'cyrus' and I changed the group ownership to 'ldap' so that the slapd server (running as 'ldap') could access the socket. This is a necessary step, else you will get Permission Denied errors permissions disallow you from accessing the socket or its directory.

Now, once we have saslauthd running, the sasl library slapd.conf, and the moons aligned, we can perform a simple bind:

nightfall(~) % ldapwhoami -x -D 'uid=psionic,ou=users,dc=csh,dc=rit,dc=edu' -W 
Enter LDAP Password: 
Result: Success (0)
saslauthd, in debug mode, will say something meaningful such as:
saslauthd[28910] :do_auth         : auth success: [user=psionic] [service=ldap] [realm=CSH.RIT.EDU] [mech=kerberos5]
saslauthd[28910] :do_request      : response: OK
Whew! My LDAP Authentication journey is complete. I'll post my configs later once I have a full directory system implemented here. For now, I am elated that gssapi and simple binds both work for eventually authenticating against our Kerberos server.

jQuery on XML Documents

Ever since BarCampNYC, I've been geeking out working with jQuery, a project by my good friend John Resig. It's a JavaScript library that takes ideas from Prototype and Behavior and some good smarts to make writing fancy JavaScript pieces so easy I ask myself "Why wasn't this available before?" I won't bother going into the details of how the library works, but it's based around querying documents. It supports CSS1, CSS2 and CSS3 selectors (and some simple XPath) to query documents for fun and profit.

In the car ride back from BarCampNYC, I asked Resig if he knew whether or not jQuery would work for querying on xml document objects. "Well, I'm not sure" was the response. I took the time today to test that theory. Becuase jQuery does not rely on document.getElementById() to look for elements the way Prototype does. Bypassing that limitation, you can successfully query XML documents and even subdocuments of HTML or XML. This is fantastic.

Today's magic was a demo I wrote to pull my rss feed via XMLHttpRequest (AJAX) and very simply pull the data I wanted to use out of the XML document object returned.

The gist of the magic of jQuery revolves around the $() function. This function is generations ahead of what the Prototype $() function provides.

The magic is here, in the XMLHttpRequest onreadystatechange function

// For each 'item' element in the RSS document, alert() out the title.
var entries = $("item",xml.responseXML).each(
   function() {
      var title = $(this).find("title").text();
      alert("Title: " + title);
The actual demo is quite impressive, I think. I can query through a complex XML document in only a few lines of code. Select the data you want, use it, go about your life. So simple!

View the RSS-to-HTML jQuery Demo


I've been working on various touchscreen-related projects off-and-on and I've always wanted to use Firefox (Gecko, really) as the primary interface. HTML and JavaScript are quick and easy to hack together to provide a simple interface for touching and tapping goodness. However, the only touchscreen-based system I have access to has a 133mHz processor on it and Firefox takes about 15 minutes to start up.

I knew about the GRE (Gecko Runtime Environment) but I've never bothered learning about Mozilla's Embedded API to write my own application. Someone at Mozilla decided to do just that and more. I found this project today, called XULRunner.

XULRunner is a fantastic application that provides Gecko, XUL, JavaScript, et al; all without a fancy browser wrapping it. This is, in my opinion, perfect for embedded applications that may need/want web-browsing capability.

Applications for XULRunner are devilishly easy to write if you know XUL or have a server to serve webpages. A XULRunner tutorial mentions having to set a "home page" for your XULRunner application, it uses this:

I didn't want to write a full XUL application. I wanted to use my existing HTML/JavaScript-based web kiosk pages. So, what do I use?
Start XULRunner, and a window pops up with my webpage in it. Fantastic!

I haven't had a chance to test XULRunner on the touchscreen system yet, but seeing as how it lacks much of the code that makes firefox slightly bulky I'm hoping it will startup and run much faster. We'll see soon!

If you're looking to write a web-based application that uses XUL or even simply HTML+JavaScript, give XULRunner a look.

Adventures in Kernel-land

Having found myself with a lack of energy for working on my current projects, I decided to start a new one. This one aims to be a flexible input-device framework for FreeBSD.

I know next to nothing about the kernel and it's implementation, but fiddling around so far I've done somewhat well-ish. The first thing I'm going to do is make a new psm driver that can be loaded as a kernel module instead of having to be built into the kernel. My first target is going to be a driver that supports generic PS/2 mouse devices.

Once that's working, I'm hoping I'll be well versed enough in kernel development to actually start working on a framework for input devices (keyboards, joysticks, and mice). I'd prefer that things like special mouse drivers for things like Synaptics touchpads are off in their own little sub drivers. I also want sysctl tunables for options that are reasonable to have changed.

Right now, I'm not sure how I'm going to implement this framework, becuase I simply don't know enough about the kernel to know how to do it properly. More on this as things develop. This should be a fun project for me seeing as how I've never really dealt with hardware before, nor have I ever written anything on the kernel level.

qemu, an open source emulator

I'm always skeptical of open source software doing it's job correctly, and but sometimes I'm surprised by them. I recently installed a platform emulator called qemu. It can emulate x86, SPARC, PPC, and a few others supposedly. I recently installed windows using it, and it runs surprisingly well. It's fast enough to let me play starcraft, for instance ;)

I've previously used vmware 3 in freebsd with much success but not after lots of irritating kludges to get it to work properly. Qemu was a joy to get working, just two commands and you can be off and running.

nightfall$ qemu-img create windaz 5G
nightfall$ qemu -cdrom /dev/acd0t0 -boot d windaz
'-boot d' tells it to boot off the D: drive, which is the cdrom. I was now ready to install windows to my 5 gig "drive"

For the x86 platform, it has a kernel module for linux and freebsd you can use to accelerate emulation by getting rid of a few layers of translation (Why translate for x86 when you're ON x86?). FreeBSD's port of it allowed me to build the kqemu kernel module, and off I went installing Windows XP. The install went flawlessly - and it blew my mind that everything worked out of the box. By default, it uses it's own "user net" internal nat/firewall nonsense that I didn't bother futzing with. It can use Linux's tun or FreeBSD's tap interfaces to get a real ip assuming you setup bridging and whatnot properly.

To get TAP running for qemu under freebsd, you're going to have to have tap in your kernel, or kldload if_tap. Once done, you'll probably want to setup bridging or setup local nat and dhcp. At any rate, I used bridging. You'll need BRIDGE in your kernel or kldload bridge. To turn bridging on use

# sysctl
# sysctl,tap0
If you get an error with either of those commands, you don't have bridge loaded or in the kernel. Anyway, em0 and tap0 are the two interfaces you are bridging. em0 is my wired interface to the world.

You definately don't want to put your new install of windows on the net before getting SP2 and some antivirus software, so don't use the tap stuff until after that. If you don't specify the -n option to qemu, it will use user-net (assuming you haven't created a /etc/qemu-ifup script).


Since my laptop likes to have sound issues that I can't fix due to hdd issues, I decided that my Ultra1 would be my new speshul mp3 player. Since my desktop is still at home I don't have any mp3s myself, so I just mount a friend's directory using smbfs under FreeBSD - Solaris 9 doesn't have this feature in it's base and requires 3rd party shenanigans to do it.
Samba's smbmount is linux-specific, so that was out of the question. I found a project called Sharity which allows not only the root-user to mount samba shares, but users aswell. They had a Sol9/sparc package already available to me so I downloaded and installed that. It uses a daemon (run as root) to manage mounted file shares and such. What is neat and mention-worthy is a default mount of /CIFS which is browseable and works the same way the "my network neighborhood" thing does in Windows. You can also set an external program to prompt for passwords, for instance if you try to cd to a password-protected machine/share it will pop up a password dialog in a gui of your choice. Neat.
cifsmount -u [user] //machine/share /mountpoint
Passwords are saved by default so once you enter the password for a share it never asks you for it again.

As far as speed goes, it seems as fast as smbfs under FreeBSD or faster (I can't tell at this time: 2mbps/366mHz laptop vs 10mbit/143mHz ultra1). But as far as finding a viable solution for mounting CIFS shares under non-linux (and non-freebsd), Sharity is what you want. I'm sure it has more cool tools that I can play with, but I haven't really explored anything yet.

mserv, it's neat.

In my quest to stop using xmms (it requires that whole.. mouse thing) I ran across a mp3 jukebox server called mserv [].
It's pretty cool and can support just about anything I want it to since it uses external programs to play them. It uses a server protocol similar to that of Joe's Moonshot Jukebox. I don't have any oggs so his jukebox is mostly useless to me.
I quickly hacked together a script (well, it functions as several tools) to let me play songs more easily. It's called mq and you can see it here if you want. With it you can do things like: mpick Cake | mq to enqueue all tracks matching "Cake"
Put it in ~/bin/ and have it propogate its tools with symlinks by doing mq -setup. Look at the code to figure out what does what, it's fairly straight forward.

xapply rocks me

I have a lot of mail boxes that need sorting from the various lists I subscribe too, and sorting by hand or on "viewing" is annoying, so I got bored and made use of xapply and the 6 processors on fury.csh to sort all of my mailboes.

find ./ -type d | xapply -f -P6 'echo "Sorting %1" && mhthread -fast -lock %1 && echo "Done sorting %1"' -

The cwd was ~/mail/ and directories under here are all mailboxes. So, xapply uses 6 parallel processes to call mhthread on each mailbox that was found.