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.

Been a while since I’ve even checked on this site…

Lots of changes for the work side of things.

We finally upgraded our Zimbra install – I’ve been thinking about writing up the process, but don’t know if it makes a difference now. We migrated hardware and upgraded to version 7 and since Zimbra is now at version 8, I’m not sure how relevant the information would be. I am hoping to get an upgrade to 8 done this summer though. Which will probably be pretty painless.

And we’re planning to migrate away from Apple’s Open Directory to Active Directory. I’m not sure how I feel about that… Given Apple’s obvious focus on everything “i“, I am pretty much done with anything related to their “server” line of software. But I haven’t heard many good things about M$ lately either. Maybe I’m traveling in the wrong circles. If someone out there can provide reassurance that AD is not the work of the devil, please do.

As before, I’ll try to record the process and progress for both of these projects on the off chance it provides useful information for someone else some day.

We’re still running Zimbra at work and it’s still providing us with what we need as a collaboration suite. Unfortunately, we’re running on Leopard Server and still stuck on version 5 due to Apple’s unwillingness to fix the bugs in their server software.

Which is why we’ll be migrating from the Xserve to an Ubuntu server*. I have a conference call with Zimbra’s Professional Services people to begin the planning of the migration. I put the call into them due to the fact that we’re migrating hardware and software at the same time, as well as upgrading the storage system that mail resides on. Looking forward to the challenge and keeping my fingers crossed that all goes well.

*A server that will not have an HP logo on it.

I finally got our authentication/home directories deployed. Running on Xserves.

The same Xserves that Apple discontinued 8 months ago.

<Sigh>

If there are any OS X Server gurus out there, I’m having issues with Tiger client Netinstall images and Leopard server.

They just don’t work!

The machines netboot just fine and look like they’re going to image properly but the installation ends after 3 seconds with a “Software successfully installed” message. The only thing that’s happened is the machine name has been changed.

If anyone can point me in the direction of a solution, give me a holler!

Thanks!

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)

This one is for any other sysadmins that happen to stumble across this blog…

Our school district has the worst data management possible. We have had active email accounts for people who haven’t worked for us in years.

It’s that bad. Actually it’s worse (although I don’t know if this counts as worse)…

We have no directory services in place – For each system or application we have that requires authentication, that system or app has had it’s authentication information maintained manually. It’s been a nightmare to say the least.

We’re finally implementing directory services (Apple’s Open Directory) and we’re planning on having it drive everything authentication-related. But we still have a problem with the data we get (or don’t get) from our HR department. A plan has been fashioned to use a PHP/MySQL customised system to give multiple people access to the data in our directory and update it as needed. I’d go into more detail, but I’ll be honest – this thing seems like it’s grown to monolithic proportions and I’m at a point where I A) don’t really know anything about it, B) don’t even think I understand it anymore, and C) don’t even have access to it.

So… my question is… is it wrong that I feel extremely hesitant (borderline refusal) to allow that much access (pretty much everyone in district – user password changes will theoretically be handled by this system) to the directory data?

Or am I just looking at it from a ‘Chicken Little’ point of view?

One of the projects I’m involved with at work is implementing a new email system. We’re going to be moving approximately 2100 users from Squirrelmail to the Zimbra Collaboration Suite. As part of the transition we’re not going to be moving user’s mail, instead choosing to go the fresh slate route. All of our users will still have access to their old mail for some time to get what they really need out of their mailboxes. We’re also going to be moving completely away from using mail clients, opting instead to have our users access their mail through the ZCS web UI and utilize all of it’s features. We didn’t make these choices lightly, but honestly our users have a habit of using their email for jokes, shopping, and more jokes – none of which I feel like moving. As for the mail client decision – anyone who’s ever migrated 3GB worth of email from one computer to another can probably see where we’re coming from.

In terms of the user experience, moving from Squirrelmail to Zimbra is akin to trading in a Ford Model T for a Dodge Viper. Zimbra has a beautiful AJAX UI that, while being easy on the eyes, is also extremely functional. Users essentially have all the functionality that they would expect from a locally installed client. One nice thing about Zimbra is that you’re not locked into using the AJAX interface – you can choose to use a standard HTML interface which is a stripped down version of the UI, but still a million times better than what we’re moving from.

One of the things I’m hoping to do with this blog is provide information on our Zimbra implementation that other admins may find useful. I’ve spent hours trying to find solutions to problems we’ve run into already (syncing Zimbra’s internal LDAP server with an external OD server and auto-provisioning new email accounts for instance) and if I can save another admin the hassle, I’ll be satisfied that I accomplished something.