AD Binding Issues 10.7.X

1.) When binding to a domain controller where a legacy controller also exists (example.com and exampleNT), Directory Utility binds itself to both domains. Leopard and Snow Leopard handle this correctly without binding to the legacy.

2.) When binding to a domain controller where a legacy controllers also exists, the Search Policy is incorrectly populated. For example, you'll attempt to bind to example.com, and Directory Utility will bind to Example.com and ExampleNT. Then the search policy will only be populated with "ExampleNT/All Domains". If you click "+" to add other resources, it will show "ExampleNT" and "Example.com". Add both of those, exit Directory Utility and go back to Search Policy. Click "+" and now "Example.com/All Domains" will appear. It should have been in the list originally. Now you have to reorder the policy to be: Example.com; Example.com/All Domains; ExampleNT; ExampleNT/All Domains. Until you've put the Search Policy in this order it is not possible to login with network accounts. And no matter how we arrange / edit / set the binding policies, that irritating login light will never be green. Only yellow: some networks accounts are unavailable. So not only is Directory Utility binding incorrectly, it is incorrectly setting the Search Policies.

3.) In Directory Utility, if you do not check "Require Confirmation before creating a mobile account" and then bind, the box will magically become checked. However, if you check and then uncheck it, the setting will not magically become checked.

4.) Let's say we're using a machine naming scheme in the format of AA-XXXXXX, where AA is a department abbreviation and XXXXXX is an asset tag. Prior to binding in System Preferences, we set the machine's name to AA-222222. When you open Directory Utility, it will autopopulate the ComputerID with the ID of another machine that is already bound. So instead of going with AA-222222, it will pick AA-111111. Not only that, but some characters are converted to others. AA-XXXXXX will be automatically converted to AA_XXXXXX.

5.) When you click on bind, Directory Utility often immediately states your credentials to bind to AD are not correct. However, this is a false positive. Our setup locks AD admin accounts with any invalid attempt (ie - one failed login = locked out). But when this authentication failure occurs in Directory Utility, no lock out occurs. We've watched traffic and Directory Utility isn't actually attempting to authenticate. There is no authentication request. When this happens, all settings you've customized are reverted. So once again you have to check and uncheck the Require Confirmation selection, enter the correct machine name, etc. Now hit the bind button, and Directory Utility properly attempts and succeeds in authenticating. Binding completes.

6.) When you unbind, often Directory Utility will simply pretend it is done, but the unbind button is still a possibility. Clikc Unbind, enter your credentials again, and this time it will actually unbind.

I've put in several bug reports regarding these matters (along with videos of the issues, full logs, etc). All issues were confirmed as existing. Then they closed the tickets saying 10.7.3 would address the issues, but all of the issues still exist for us. Apple opened a service request with us, but acknowledged the issues exist, and then closed it out.

Has anyone else experienced similiar issues with a legacy controller on the network? Seeing as Leopard and Snow Leopard worked perfectly and the server configuration hasn't changed, since 10.5.X and 10.6.X gave no issues, the rewrite of directory services for 10.7.X seems to be filled with bugs.