Active Directory broken in Lion?

These are my test results with 10.7.2 and the Centrify workaround (no third-party/centrify plugin installed):

Note: my Mac was already bound to AD (2K3 SP2 R2) so binding was not tested, only authentication/access:

1. Made all changes as per the workaround (steps 1-4)
   
2. Rebooted Mac 6 times:
   • Logon was very fast, everytime.
   • No message regarding 'network accounts unavailable' or 'some network accounts are unavailable' which was a consistent problem before.
   • 'User & Groups Preferences --> Login Options. Network Account server status was green every single time (checked immediately upon logon)

Issues found:

Upon setting 'MDNS_TIMEOUT' from '5' to '0' as per Step 3 on the workaround, my apple script which mounts AFP network volumes upon logon failed to work (could not locate server). The issue seems to be rooted in the fact that pinging .local hosts/domains after modifying the above timeout value is no longer possible (this is in fact stated in the workaround). Indeed, I could not ping my NAS and adding it to my /etc/hosts file resolved the problem. This is obviously not a practical solution if you have a large network. I reverted the value to '1' instead of '5' and that worked for me. It did not logon as fast as with the value set to 0 but I can live with that. Something to bear in mind...
Note: I could still browse/access my NAS/server via Finder with the value set to '0' so this must only affect situations where your process pings a host for whatever reason. In my case, the 'mount volume' command in my apple script must ping the host in the background before initiating the mount operation which would explain the issue. (This is obviously just a theory).

Thank you for popping in here and pointing us to this workaround NickWatt. You have certainly made my weekend and those of many others I'm sure.

EDIT TO MY ABOVE (didnt let me edit my original post, sorry)

A new search path showed up after this workaround (possibly due to the DNS server zone changes): /Active Directory/DOMAIN/domain.local. Click the + sign to add it. I moved it to the very top. The only AD search paths available before this workaround were /Active Directory/DOMAIN and /Active Directory/DOMAIN/All Domains

Just thought I'd mention it...

Hi

I didn't need to make any changes to the search paths to make this work. I left it as the default which was created when first joined to AD (/Active Directory/DOMAIN/All Domains) and it worked just fine.

I'll have the same problems with the HOSTS file as yourself. My staff & student network locations are spread across a number of servers. So I'll have to ensure the all server addresses are in the HOSTS file. If a location changes then the HOSTS file on all my machines will have to be changed. Does anyone know how I could push out a changed HOSTS file from the Lion Server?

The next problem I forsee is when Apple resolve the problem. Will we have to undo the workaround? What if they think they have fixed and push out an update which undoes the workaround but still doesn't work? I guess it is suck it and see time.

As this is the first Apple suite I have ever rolled out (only been using an Apple computer since April!) I'm quite disappointed in Apple not supplying the workaround. When I spoke to AppleCare they told it me it was a fault with our Active Directory and I would have to pay £465 to open a Select Incident. I would then get email and telephone support for this one problem, with no guarantee of a solution. I argued the case that the Snow Leopard machine which I bought in April integrated and work briliiantly, to no avail.

I'm now 4 weeks behind on this project which has been frustrating. The only saving grace is the iMacs are absolutely fantastic pieces of kit and it'll be brilliant to see the students enjoying them. So for now, at least it works.

If I was in your situation with so many clients and managing an actual enterprise I would not bother with this workaround and implement a 3rd party plugin like LikeWise. You may be creating an administrative nightmare for yourself. Look at it this way, to this day, you can experience authentication delays and hiccups with SnowLeopard which has been around for a long time already. Can you really expect Apple to fix these problems in Lion anytime soon?

To be fair the Active Directory plug-in in Lion is actually working. It is the networking side which has caused these issues hence why Centrify's plug-in also didn't work as expected, hence why they came up with this workaround. And to be honest, LikeWise actually didn't work at all on two of my machines.

The workaround stops IPv6. It then turns off the multi-casting which unfortunately causes other problems with .local domains hence the entries in the HOSTS file. So I'm not concerned with the AD integration part, I'm just hoping Apple will sort out the problem with name.local domains conflicting with their own .local methodology.

Nickwatt, what problems did you have with Likewise? I had to do some trouble-shooting and found that their tech support is VERY helpful, in fact, you may have received a tech's email address when you downloaded the plug-in.

Kent

Why are people still creating fake domains rather than subdomains when even Microsoft has advised against using .local TLDs since at least 2003?

http://technet.microsoft.com/en-us/library/cc738121%28WS.10%29.aspx

"Using single label names or unregistered suffixes, such as .local, is not recommended."

"It is best to use DNS names that are registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names, then the two infrastructures cannot interact with one another."

If people actually used "newyork.mycompany.net" rather than "mycorpnewyork.local", wouldn't this not be an issue?

.local is not fake domain. Microsoft has recommended using .local for most of its examples when creating AD domains for years. This only started being a problem when the Zero-Conf group created the Rendezvous specification which Apple makes use of. You could also argue that the Zero-Conf group could have used a different name space too.

It's unfortunate that Apple and Microsoft have have this name-space collision in the .local space. In a perfect world, Microsoft would get onto the Rendezvous bandwagon and the OS X clients could actually use Rendezvous for the .local Windows machines and everything would be fine. Of course we'd all probably get pretty old waiting for that.

nickwatt wrote:

To be fair the Active Directory plug-in in Lion is actually working. It is the networking side which has caused these issues hence why Centrify's plug-in also didn't work as expected...

to be fair, you are the one that has to deal with it at the end of the day. If you are ok with editing the host file for each and every Mac in your environment after implementing this workaround (which granted, does work) then that's up to you. I hope you manage to script the process somehow to alleviate such headache.

Thanks again for posting this workaround....

Would just using another fake domain like .lcl work? I've seen that done in books. .local works fine for 99% of businesses. But for my company with 40% and rising Mac usage, it doesn't work for an AD domain.

I don't really think either party is at fault--- Bonjour/Avahi are great for small networks where you don't need any management but want all of the machines to see each other without fuss. Once you surpass a certain size though, AD becomes necessary and you really don't need any of the features of Bonjour/Avahi. Personally I think the networking configuration in OS X is getting out of hand--- if there was some way to disable Bonjour that'd be great, but it is so entrenched in the system that you can't even trust your hosts file anymore!

I've come to the conclusion that there are two rules in choosing a domain: either make it a subdomain of a real domain that you own, or make it any fake domain thats suffix is not .local. I realize that .local is pervasive in the industry. Everyone is doing it. A lot of the documentation and books tell you to use it. But if I was dealing with any number of Macs that need to bind to an AD domain and was starting from scratch, I would certainly avoid it. What advantage is there to using .local, really?

For the purpose of overcoming the issue with OSX, you could use anything you want really as long as it isn't .local. How about .solo ? 😝

I can't beleive this is not fixed yet?

I apply the fixes in this discussion and it breaks other item.

I would hope this is fixed soon.

Anybody have any 3rd party apps that will manage ipads and connect to Active Directory?

Might as well chuck my name down on this issue as well...

I'm running a fresh network, consisting of a newly installed SBS 2011 server and 3 Windoze 7 workstations.

Trying to bind 10.7.2 to AD and getting the 'Network accounts are unnavailable' error.

The SBS install is a standard, out of the box install.

I've tried all the suggestions on numerous threads. Disabling IP6, changing search domains, changing search policies, binding / re-binding / un-binding, rebooting etc, etc.

Apple support seems to totally suck in relation to this issue. Been promised call-backs and not heard anything.

I'm a new Apple user and am really disappointed... I thought Apple were better than this.

As I've said before, I've been using the Likewise Open AD plug-in for several weeks with no problems and I've included it in my iMac roll-out. If Apple releases a fix I'll test it, but I can't imagine it will work any better than Likewise. Apple's plug-in has always caused problems, even when it worked correctly.

Kent

Folks, almost 1 month and counting since implementing the Centrify workaround and everything is alive and well with AD integration and Lion.

For those of you who might be skimming this thread, the posted workaround from Centrify works! (no 3rd party pluging required).

http://www.centrify.com/downloads/public/centrify-directcontrol-for-mac-local-do main-workaround.pdf

I've had no issues with AD whatsoever, I highly recommend you implement this fix in liue of waiting for an Apple miracle. When/if apple fixes this, you could always revert to the previous config files, assuming you back them up first.

Don't waste your time with anything else...