Tiger binding problems to AD
 

Hello Everyone

Since 10.3 came out we have had no problems binding our Macintoshes to our staff AD domain. I have just tried it our first Tiger machine and can't get it to bind. It seems to go through all the stages OK (finding nearest DC and verifying credentials etc) but when it tries to bind, the dreaded spinning beachball of death appears. Pressing command, option, escape tells me that Directory Access is not responding.

About an hour later I bound a 10.3.9 machine to our domain without any problems.

Has anyone else found that the Tiger AD plug-in seems to be not as robust as the one used in Panther ? Not sure how to proceed on this except to install 10.3 on all new machines.

This is a major step backwards from Apple.

Thanks

Welll in most occasions Tigr is a great improvement when it comes to AD binding... One thing... Did you update the machine to Tiger or is it a brand new install ?
Also, in Tiger, you realy have to properly indicate the OU path... Otherwise, unless computers can create Computer objects in the AD OU you are pointing to it will get stuck. OTherwise, donèt forget to change the SMB to the proper worgroup in Directory Access and to set the proper DNS addresses in the netwrok pref pane.
Also, if the AD puggin freezes like that, maybe its frezzing the entire app, in whcih case, if you look in the COnsole for crash logs you may find something of use to help find what the issue is.

It was a clean install. When binding I did put in exactly the same details as when I bind a Panther machine, same domain, not to logon to multiple domains and tell it to use the same server as a preferred DC. However I have never had to indicate a proper OU path. What exactly is it ?

Lets say that within the AD tree you have a main category called Staff within which there is a folder for COs thats called Human Resources and then a sub folder called Directors within which the user's Computer Object resides. We'll also assume the computer name ( and Computer object name) is MyMac... The OU path will then be:

CN=MyMac,OU=Directors,OU=Human Resources,OU=Staff,DC=com,DC=domain,CD=ads (the DC stuff should be the same as the Forest or Domain you specified before clicking on Bind)

I suggest you create computer objects first in AD and then bind the mac instead of having the Mac create it. Also, you may try this while having Logon to Multiple Domains to help since you can uncheck this after the bind and before you set the authentiction tab.

This is horrendous. Our AD systems people won't allow us to create objects in the AD. Why on earth should we have to find out the OU path before we bind ? Panther did all this seemlessly just like our PCs do. As I said before, a big step backwards from Apple. BTW I did try binding with the multiple option ticked. I think we will be sticking with Panther for some time.

It realy depends on your point of view... I cannot create AD CO's or users either but I can deal with asking the AD admins... As for specifying the OU, I personnaly find it very pratical as it makes sure your connected to the right item... This is in great parts due to the possibility of adding the CO directly in AD while binding your Mac... befoire most users would leave this as the default, so it would create all the COs in the main folder of the main AD tree which is a real network admin nightmare. If you look at it, on PC you have to specify the OU path as wel... So its partly just to have Mac users on the same step as Windows users I guess.
Personaly I found Tiger to be better as it alows more control and very usefull options such as a proper mobile account config.

Knowing the OUs and CNs is still not necessary in Tiger. I find Tiger's implementation of AD to be much superior to that of Panther. It's still far from perfect, but it's certainly a step in the correct direction. I think there's other forces at work here. What do the logs say when you have troubles binding to AD?

To update this thread, with 10.4.2 I can now again bind machines to our AD.

However I have come across something strange regarding managed mobile accounts.

When I log (as a domain admin) I get all the usual folders in my home folder - library, desktop, documents, public, sites etc.

However when an ordinary user logs on, they only get two folders created in their home folder namely, desktop and library.

Anybody else found this and has anyone any explanation ?

BTY, with Panther, everybody got all their folders without any problems at all.

In my experience, when I have seen this, it's not a mobile account, it's a network account.

They all should be moble accounts. Directory access is configured to:-
Create moblie account at login
Force local home directory on startup disk
Use UNC path from Active Directory to derive network home lacation

All users get their "H" drive (as it is called on our PCs) which appears as a folder in the dock. A home directory (little house) is also made in the Users folder on the HD. What I don't get is why I, logging on through AD, get all the folders in my home folder and my H drive mounted, whereas other AD users only get the Desktop and Library folder in their local home. A documents folder is not created locally nor in the H drive folder.

I have also experienced moble accounts been locked as well for no apparent reason.

My view is still that Panther works far better with Active Directory than Tiger.

Step 5 freezing...
 

Well, I'm really at a loss here... I'm hoping somebody here may have a suggestion...

Xserve, 10.4.6 Server.. when trying to bind to AD.. the process freezes at step 5. Directory Services simply sits there.. indefinitely.. until I force-quit it and restart the server. I erased/reinstalled the OS.... same thing. I can bind to AD from that box using other computer names that I've bound to AD... just not THIS computer. I've followed step-by-step the afp548 guide... also used Mike Bombich's guid to AD/OD and it STILL freezes up on Step 5. I'm at a loss... and would appreciate ANY help!!!!!!!

Have you tried deleting the recreating the computer's OU?
Are there firewalls involved?
Have you tried sniffing the network traffic for clues?

I've gone in and deleted the computer in AD... then, during the Bind process, the computer is re-created in AD. Oddly enough, if I use this computer name on another box and try to bind, there is no problem. And I can bind the computer using a different computer account without an issue. Wouldn't that rule out a Firewall problem?

As a test, try (deleting &) creating the OU ahead of time in AD.

No.. as the firewall (assuming that an issue at all) is unlikly to be blocking a name but and IP address that is assigned to the box. And/or a specific port on that IP address.. the port where the Domain box is trying to negotiate with the box you're trying to bind.

Hi, thanks so much for your help! Well, I deleted/recreated the computer in AD. Then I tried to bind again.... before step 5 it asks "would you like to join the account that already exists" and I click "OK"... and then it just sits there on step 5 "Joining computer to Domain". I tried switching the IP address to another within the range assigned to servers here (and adjusted DNS to reflect this) and still, nothing... lockup on step 5. I spoke to the IT Head here and he said the Firewall was not blocking anything related to this computer name and IP address. I'm really at a loss. I know a couple of people early-on in this thread were reporting the same issus.

You said you could bind the same box using other OU names?

By that I mean, NameA on the xServe doesn't work, but NameB on the xServe does?

Does the box have a FQDN according to your DNS server? Does the AD domain server and your xServe use the same DNS server?

Yes, the box has a FQDN... and the AD Domain Server is also the DNS server.

Does it reverse lookup?

Yes, it does

And to clarify?

Sorry for the delay. Actually let me correct myself: It appears that I can bind by entering any UserName in AD.... during the bind, a computer with that name is created in AD. If I try to bind with anything other than a USER NAME it hangs on step 5.

Sorry, I'm not sure I understand.

During the bind proceedure, one MUST have a username that is part of the AD's container User OU. Typically that username must have permissions sufficient to bind ccomputers to AD.