Cannot bind to Active Directory

We're in the same situation. 4 2012R2 DCs that work with 10.9.5 but 10.10.1 prompt "Network Accounts Unavailable" when trying to login even after it's been confirmed on the AD side as joined to the domain. This is definitely a Yosemite bug.

I've put in a ticket at http://bugreport.apple.com/ and suggest everyone having this experience do the same so the Apple engineers are aware of the issue via their preferred channels.

Bug Case # 19449017

I update recently my mac os server to 10.0.0.2, i have problems to re-bind to my 2008r2 domain i finally bind it using the CMD interface dsconfigad with these options

-domain mydomain.com

-u Adprvilegeduser

-p password

-packetencrypt require

-packetsign require

- preferred myadserver.mydomian.com

i have to run this after run the unbind command(sudo dsconfigad -u privilegedADuser -p passwod) and restart the computer. after restart the mac still say "net users no aviable" but in the directories utility i can see the user of the domain and the users can login on the services(printers) of the mac server. i finally test to login with net user and they do the login.

I configure my ad server to log LDAP information events you can see here how do it.

salutes

Don't know if this has already been mentioned, but...

Our situation:

Could not bind our brand spanking new iMacs to Active Directory. Macs running 10.10.2, DC running Win 2008 Server R2. Checked all settings in OS X Directory Utility, making sure our AD domain was present in both the DNS search domain & WINS workgroup fields. Still no joy - repeated "Unknown Error" pop-up at every attempt to bind.

Our solution:

1.) In AD, create computer object in desired OU, named identical to "Computer Name" in "Sharing" pane of OS X System Preferences.

2.) Bind to AD via OS X Directory Utility. (Make sure you point to same OU used previous step.)

3.) At "Join Existing Account?" prompt, accept.

Done.

Our affected iMacs now appear to be successfully bound to AD. Subsequent login from network (non-local) user account was successful. User account showed up correctly as a managed network user in "Users and Groups" pane of OS X System Preferences, and had appropriate access/privileges to both local resources and shared network resources.

I don't know if this is the "right" way to fix this issue, or not, so if you choose to try this, you do so at your own risk. However, it seems to have worked for us (and was much simpler/far less labor intensive than another user's suggestion of downgrading to 10.9 or 10.8, binding to AD, then upgrading back to 10.10). If it doesn't work for you, you should be able to simply delete the computer objects from AD that you created in step 1, and be no worse off than when you first read this.

Hope this helps someone else out of the same jam.

was having the same issues but then i added my servers ip address to the DNS list and it cured my binding problem. for some reason my servers ip address was listed.

I was having the same issue. I had the FQDN in the DNS search option and everything, even added multiple servers as additional search areas. The way that I got this to work was to add the IP address of the primary AD server as the first DNS entry. Our AD servers aren't setup in DHCP as the primary and secondary DNS servers. We use a different device for those. After adding the AD IP as the primary DNS entry, I was able to join the domain without any issues.

This has helped my issue. We use OSX and Win for our DNS (OSX for LAN and Win for WAN). Changing the Primary DNS to the Win server has changed the error message; I now get a new one. But at least the AD server is being contacted.

All you have to do is open Network Preferences and click Advanced then DNS. Enter the domain, IE domain.local under search domains. Directory Utility will now BIND instantly.

This worked instantly for me. Easiest solution by far.

I found that after OSX Server/Yosemite was installed the GUI had frustrating disabilities. In the end trial and error I found that manually removing the old computer record from the ADC, and leaving the domain with dsconfigad, put the machine in stable condition to use the dsconfigad effectively with the following very important "MUST DO".

The most important thing to make it work again was using the "-enableSSO" for "OSX Server". i.e. dsconfigad -enableSSO ..............

The command line utilities are very finicky and suffer from some global caching sometimes. Perhaps a purge, or some other action can alleviate this. So you may experience it not working at first. Leave the computer come back later and do it again.