I/O

In the midst of our migration to Active Directory, we’ve run into a snag…

To set the stage – We were forced to stand up a “temporary” AD Domain (running on Server 2008 R2) for a copier project with the understanding that our “real” AD Domain would take over duties for the temp. No biggie. After the fact, we’ve had a consultant on-site working with us to help plan out our migration. While testing Mac client binding with the Server 2008 domain, we ran into issues binding Snow Leopard clients to the domain. Trying to bind through the GUI gave us this lovely 5102 error:

Google was no real help with the error itself and any fixes we did find, did nothing to help us resolve the issue. Mindful of the fact that we would be running AD under Server 2012, our consultant suggested we try joining the domain he had set up in a VM on his laptop which was running Server 2012.

We go through the steps and Voila! Successful bind to 2012. Okay, no worries. Or so we thought.

We setup our new domain, running on Server 2012. There have been no major policy changes except to relax the password policy (due to our crappy existing passwords, which will be changed). Tried binding a Snow Leopard client and we’re back to the 5102 error. Try binding the same client back to the VM on our consultant’s laptop and it still works flawlessly.

We’re stumped. Sure, we could bring our OS up to speed on over 1,000 clients… If we had the time to do that, which we don’t.

So, here’s my cry for help. If anyone has run into this issue and found a fix, let me know. This one is making our consultant scratch his head and he’s pretty damn smart.

Obviously, if we do get it worked out or if someone has ideas, I’ll be posting them here to share with the next guy who runs into this problem.

(UPDATE 3/25/14 a.k.a. “Way After The Fact”)

The problem wound up being our content filter which sits between our clients and our DC. It had been patched to address a UDP attack vulnerability and stopped our 10.6 clients from correctly communicating with the DC. Our filter provider resolved the issue for us.

I decided awhile ago to switch I/O from Movable Type to WordPress after doing the same on another site of mine. The other site was a clean install with no content carried over and took about 30 minutes from WP download to being content with the results. Making the switch here took a little longer since I wanted to carry over my content (not much here, but I still wanted it to make the transition). I also had redirections to worry about since my “Zimbra External Directory Sync” article gets a lot of traffic and I know from experience that 404 errors suck when you’re searching for something.

The Why

When I first decided to start I/O I used MT, mostly because I was familiar with it and liked the comfort level. Then I made the mistake of starting with MT4. Up until then, I had used versions 2 and 3. For some reason I thought 4 would carry on with what MT had achieved in previous versions. What I got was an entirely new interface and a lot of headaches. I tried to like it, but eventually gave up on it which is why the previous post here is from August of 2009. I recently moved another site to WordPress, fell in love with it, and decided to do the same here as soon as I could.

The How

Otherwise known as “The Easy”. Downloading and installing WordPress takes all of 5 minutes – WP isn’t exagerating when they call it the “Famous 5-minute install”. Set your database connection info, run the installer, and you’re done. So easy, even a caveman could do it. Before I started this process, I exported what little there was in my MT install using the built in exporter. It churned out a text file which I used with the Movable Type/TypePad importer WP plugin. *POOF* – seconds later, here’s the content. Again, very easy. Granted, there wasn’t a lot here to import… I’m sure a larger content site would take longer but the ease of use here is great.

Finally it was time to handle the redirection aspect of this endeavor. MT’s permalink structure is different from WP’s – even after I changed the WP permalinks to match what MT had been using, I still had an issue. MT used hyphens to handle spaces in post titles and WP uses underscores. Not wanting to go down the road of hacking WP files for one high traffic article, I started looking into using mod_rewrite. Here’s where my eyes glazed over and I lost a couple of hours in reading and trial and error. Yes, hours – I like learning about methods I’ve never used before and mod_rewrite fits the bill. Unfortunately my ability to harness the power of the mod_rewrite voodoo left me with redirects that weren’t working. Thankfully, one thing I’ve learned about WP is, there are plugins for damn near everything. Enter the “Quick Page/Post Redirect Plugin“, which was the first plugin I looked at. This plugin had my redirect up and running in seconds.

The End

The transition is complete, users coming here via links to the external sync article should get to where they’re going, and when I finally click “Publish” on this article, it won’t take minutes to actually publish. I will miss MT a little. It’s what I started with years ago. But WP looks like it’s going to suit my needs a lot better for the immediate future. The only other thing I have to work on is the theme – not sure if I like the current one, but that’s something that can wait for another day.

Just a quick note:

We rolled out Zimbra back in October to our 2,000+ users with some last minute account insanity. Aside from quickly adding over one hundred last minute accounts, the roll out was a success. We’ve had a few issues since then, but nothing major and all issues were addressed by Zimbra’s support team within a reasonable amount of time.

So far it seems to be a hit with most of our staff and I’m extremely happy with our decision. If you’re looking for an email system, I definitely recommend checking them out.

One of the first problems I had to resolve after installing Zimbra, was how to keep Zimbra’s internal LDAP directory in sync with our Open Directory server. This problem was compounded by the fact that out of the box, all Zimbra mail boxes have to be provisioned by hand. Granted, there are command line tools and scripts that can be used to batch provision accounts but who wants to manually put together scripts to do the bulk provisioning? Authentication and GAL lookups from an external source are working beautifully so far and to me, Zimbra’s lack of an auto-provisioning from an external directory feature is almost insane.

Currently there is an RFE in Zimbra’s bug tracker for such a feature, but that doesn’t help those of us who could use a solution now.

After a great deal of searching through the forums and bug tracker, I literally stumbled across Bug 14772 – include zmexternaldirsync in build. It’s a discussion about including a Perl script called zmexternaldirsync in the Zimbra builds. From what I can tell, the team was getting it ready to include it in a build and then decided against it. I grabbed the script and documentation and fiddled around with it and got it working.

And now I’m posting it here to (hopefully) make someone else’s life a little easier.

    WARNING: This script is provided as-is. The author of this blog is not responsible for any potential damage it may do to your install. The author of this blog is also not responsible for supporting this script. Be aware that any future Zimbra updates could break this script. I doubt it’s supported by the Zimbra team since it isn’t included in any of the available builds (AFAIK). Use it at your own risk!

With that said… I’ve been using it since earlier this year. So far it’s auto-provisioned new mail accounts for every new user I’ve added to our directory server. It’s made my job a lot easier than I thought it was going to be. It’s survived two software updates and an OS/hardware migration. It’s everything that should’ve been included with Zimbra to help system administrators maintain user accounts.

When I first set it up, I was running Zimbra on an Xserve running Tiger server (10.4.11). I had to install the Perl modules referenced in the spartan documentation. I also had to modify the script itself – I’ll be honest, it’s been so long I can’t remember what I had to change and I was bad about keeping notes… I think it was a case change in three lines of the script. I’ve included my modified script in the zip file to save you the time and trouble. I’ve set the script up to pull the cn from our directory and set that value to Zimbra LDAP’s displayName value… I’ve found it handy to have full names in the account listing screens. I just finished migrating to a newer Xserve running Leopard server (10.5.4) and haven’t run into any problems with the script so far. If I do, I’ll post them here.

zmexternalsync.zip (67 KB)