Archive

Posts Tagged ‘Active Directory’

Snow Leopard Client And Active Directory

June 18th, 2013 Comments off

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:

aderror

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.