et lux in tenebris lucet

I’ve received a lot of comments on my MacOS X Login with 802.1x post, so it’s time for an update!

1. I have no idea what the real XML structure for loginwindow is. What I have is some trial and error, fragments from searches, and adding the items using ‘defaults write’. Some (most?) of it can be found in the XML files for AirPort, which are available in pure XML format.
2. Internet Connect is hardcore finicky about adding things itself. After writing the aforementioned post, I discovered that the reason it wasn’t adding to the login window as it’s supposed to is because of cert errors from keychain. My solution was to connect with 802.1x, delete all references to my certs (I made certs from my own CA on my RADIUS server) from keychain under the user, system, and anchors section, then run the add to login window under Internet Connect. However, this only worked once for me, and after that, it went back to being pissed off and broken.
3. I haven’t tried anything on 10.5.x yet because the fancy LDAP system I developed at $dayjob is broken under 10.5. Apple made enough changes to their LDAP that it’ll see all the data from LDAP, but it won’t auth at the login window. I haven’t even had time to look at it yet because I no longer have a Mac at home, and we’re going through a merger at $dayjob.

So, there you have it. 802.1x works – mostly – although I still have problems with it finding the AP fast enough if you try to turn on portable home directories (a topic for another post) because the Mac gives up way too fast on 802.1x and logs you in without networking and breaks any network permissions you may have set with groups and the like. Someday I plan on documenting everything I’ve done to create this unified LDAP single sign-on system I keep mentioning, as it was a nightmare to come up with a way Windows, MacOS and Linux can find a common ground in LDAP. Stay tuned!

So the other day at $dayjob, the CEO and tech manager at my $oldjob (which $dayjob had been using as an ISP) walked into our building and accused $dayjob of stealing/destroying their equipment because some T1’s went down. The equipment probably hasn’t moved in over 8 years, and it was still in the same damn place as before. It turns out a power cable was wiggled loose during some demolition work that morning. But seriously – the nerve it takes to walk into our house with an attitude and blindly accuse us of things we didn’t even do or even know about. It’s also not our problem that the other tenant of the first floor (who was also using said equipment) didn’t give $oldjob any notice they were leaving. And all this in front of three employees of $dayjob. I guess some things just never change. Good riddance.

My $dayjob bought a new Sprint Mogul (also known as the HTC Titan, or PPC-6800) to replace my personal Treo 700wx. The general verdict is that the performance of the device absolutely sucks compared to my Treo. Screen redraws and UI updates are so slow, the device may lock up or misinterpret input. Today, I came across this site:

http://www.htcclassaction.org/

While it’s nice to know I’m not alone, it’s sad that they (HTC) has released such a horribly performing product. Good thing I didn’t pay for this thing myself, or I would have returned it and gone back to my Treo by now.

At my $dayjob, I created a fancy unified login system with OpenLDAP and NFS mounts for all the computers. (General details of which I’ll put online when I have some spare time.) So I wanted to add another layer of fun: 802.1X network authentication. In my case, it’s only for wireless (using an HP 420 access point and FreeRADIUS), but this would work with a wired connection, too. The big problem was getting the login window to authorize with 802.1X so it could get all the directory information from LDAP and the NFS automounts for the user’s home directories. I was able to find some directions on how to do this from Apple (http://docs.info.apple.com/article.html?artnum=303471) but it failed to work for me.

Ultimately, after a long fight, with much anger towards Apple and the world for poor documentation, I was able to figure out what goes in /Library/Preferences/com.apple.loginwindow NetworkAuthConfigList:

 
   NetworkAuthConfigList = (
        {
            AuthData = {
                AcceptEAPTypes = (21, 25); 
                TLSVerifyServerCertificate = 1; 
                TTLSInnerAuthentication = MSCHAPv2; 
            }; 
            AuthType = "802.1x"; 
            "Network Port" = en1; 
            UserDefinedName = "My 802.1X Configuration"; 
            "Wireless Network" = "My Wireless AP"; 
        }
    ); 

In addition to this, you must have your TLS root certificate (I’m only using PEAP and TTLS for the EAP types, so no client certs, that’s also what the 21, 25 above mean) in the X509anchor and system keychains, trusted for EAP authentication. This is also very useful for mass deployments, since you can script this in using the “defaults write” command. But in my case, the command line is less annoying that pretty buttons that never tell you what went wrong.

You probably still need to set up an 802.1X profile in Internet Connect (and obviously changing the names for UserDefinedName, “Wireless Network”, and “Network Port” for your network to match) – I haven’t tried this yet without creating a profile in Internet Connect, but it fees like all the required data is already there. Anyway, I’m sharing this in case anyone else out there is trying to do network auth like I am and hopefully save you the trouble I had getting this far.

One final note: I have only tried this on 10.4.11, since 10.5 completely broke LDAP authentication in even the simplest test case, and is banned from $dayjob until that can be fixed.

Debian’s init script for Dovecot doesn’t cover the dovecot-auth only case (i.e. “protocols = none”). I’m starting to use dovecot-auth to handle auth requests from Postfix (it does do better than SASL in for my needs), and since I like keeping things consistent with system startup and shutdown, I changed the init script. Also submitted as bug 460823 for the dovecot-common package.

http://ninjamonkey.us/files/dovecot-auth-init.patch

(clicky to enlarge)

http://www.startribune.com/535/story/1579720.html

It seems that Hormel (makers of a fine luncheon meat) lost a trademark battle with a company using “Spam” in their name. Hormel has always been good humored about the use of spam vs. Spam vs. SPAM, including the Monty Python skit, and it’s sad to see stupid companies (like spamarrest, which is also holding an asinine patent on challenge-response, especially because C-R systems are part of the junk mail problem) trying to take advantage of Hormel’s obvious trademark claim.

From a Photoshop contest on Fark:

Credit goes to farker itsdan.