network accounts are unavailable

You may have no alternative other than rebinding. It sounds to me like the password for the AD computer account expired.

thanks for the reply. according to this article, i don't think that's it:

http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

"Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time. Before we set the new password locally, we ensure we have a valid secure channel to the DC. If the client was never able to connect to the DC (where never is anything prior the time of the attempt – time to refresh the secure channel), then we will not change the password locally."

also, we're using the domain controller(s) for ntp.

I would never be accused of being an expert on AD binding, but I'm going to guess that somehow the Mac isn't talking with the DC, or something changed in your AD structure that's causing the problem, like the OU the Macs are bound to moved or changed in some way. I assume it could be a number of things, so you might want to talk to who controls your AD infrastructure to see if any changes were made that might be the culprit. Hopefully that is someone other than you, or it will be an odd conversation :)

You should also see if its happening on other Macs. I have seen an odd occurrence or two of a Mac suddenly losing its connection with AD and no troubleshooting would fix it other than unbinding and rebinding. Its happened rarely enough that we haven't really looked into the cause.

We experience "network accounts not available" mostly on our Macbook Pro's. In our case they experience a time drift because they never get shut down, the lid gets closed and they're shoved into a cart.

We use our own NTP server but the drift still occurred, we made a few changes and i think we're good now. In case you didn't know, if the time is off by just 5 minutes you will not be able to login to the DC.

Chuck

Check that your client machine clocks are synched with the AD controller.
If they are loosing time-sync, then they WILL drop off like this...

You should ideally use the same ntp.

That said, maybe there is some other cause ?
- But definitely check the clocks...

1) Clocks, as was stated.
2) If users aren't connecting for x time, then many AD setups move an object to an "inactive" OU. You'd have to ask your AD admin about that.

Those are the two most common I've seen in our environment.

all,

thanks for the replies. yes, we're using domain controllers as ntp, and no movement in the ou's. thanks.

I've got an extension attribute that can help with detecting Macs that aren't communicating properly with AD. If nothing else, it should give you an idea of how widespread the issue is:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/check_ad_binding

I've also got a post on how to remotely diagnose AD bind issues from the command line:

http://derflounder.wordpress.com/2012/03/29/diagnosing-ad-binding-problems-from-the-command-line/

When you get the error try logging in as an admin, and browse using dscl in terminal:

lisad$ dscl
Entering interactive mode... (type "help" for commands)
 > cd /Active Directory/
/Active Directory > ls
YOURDOMAIN
/Active Directory > cd YOURDOMAIN/
cd: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)
/Active Directory >

sudo killall opendirectoryd

Usually fixes rather than a rebind. Trying to figure out a way to prevent.. suggestions welcome if others have any...

Has anyone found a permanent solution to this issue? I am experiencing this issue with Macs having osx 10.8.4

Crank up the debug logging for opendirectoryd:

1) odutil set log debug 2) Do what you need to do to make it do some AD related thing (e.g. id)
3) odutil set log default

The log files are at /var/log/opendirectoryd.log. Take a look through there for anything suspicious.

We've run into problems when the clock on the workstation drifts. Check the clock on the DC its talking to.

Also make sure the timezone & the clock are consistent. We had a machine with an AD problem on the other side of the world that was set to our timezone instead of theirs, and they manually set their local time. Once the timezone & time was corrected, it was happy as can be.

I don't know if any of this is related, but we started seeing additional occurrences of Macs losing their bind to AD in our environment and finally decided to look into it further. While we don't have anything conclusive, we did notice on some of the Macs affected by this, running a dsconfigad -show would state the Mac was bound properly, but trying to navigate anywhere in AD, such as doing a simple lookup of its own computer account would fail, or any other lookup for that matter.

We hadn't noticed it before, but since 10.7 and up, there is a keychain item stored in the System keychain that retains the computer account password that the Mac and AD use to communicate. If that keychain is deleted or missing in some way, communication breaks. In some of the cases of our Macs falling off the domain, this was the issue. It only came to our attention b/c when troubleshooting it with one user, he confessed he had deleted "something" in Keychain Access, but couldn't remember what it was. In digging around I found that keychain item and linked it together., His Mac in fact no longer had the keychain entry. We've detected a number of other Macs also with that keychain entry missing that can't communicate with AD.
In all these cases we found that no commands we could throw at the Mac would get the communication working again short of an unbind and rebind. Luckily we've been able to automate the process of unbinding and rebinding, so it doesn't involving touching all these Macs. They're still talking to Casper just fine.

That keychain item in question is stored in the System keychain and is usually labeled something like /Active Directory/DOMAIN, at least in our case.

In short, using dsconfigad -show to determine if a Mac is truly connected to AD is inaccurate because its reading from a local file and not really checking if it can talk to AD. We also built an Extension Attribute that does a real check on AD communication and reports the state back so we can track these Macs down.

Anyway, that keychain item might be worth checking on for Macs having issues with AD communication.

@Mike. Would that be the Mac's ad password?

We set ours never change, I think the command is ```
dsconfigad -setpasswordinterval 0
```.

Fixes a similar issue for us.

@Ben, yes, that is the Mac's AD password and yes you could set it to never change using the -setpasswordinterval integer.
The issue however that we found is that in some cases, perhaps people issues or perhaps technical, that keychain entry gets removed and when that happens the communication between the Mac and AD is broken. Haven't found any command yet that fixes it other than rebinding. You can't really recreate that keychain file. I mean, you could I suppose, but you'd need to know the password that AD has stored for that Mac and use that as the keychain item password, so it would be a little tricky, and not even sure if it would resolve it anyway.

@Mike, yep I could see that causing an issue!

I had a case a couple years ago that was part user and part technical error, combined.

Users were unplugging our iMacs from the data port and plugging in their laptops. This caused the iMac to switch over to wireless. In addition, a range of IPs had been designated for my building that used to be on a different campus completely. This small range of IPs was never changed from that remote domain controller to the local DC pool. As soon as one of the iMacs grabbed one of those IPs, it was set to use the remote DC.

The problem was that the remote DC was unreachable due to ACLs. The machine was still bound correctly and everything, but it was as if it was sitting at home. There was nothing that could be done to switch it back over to the local DC pool short of unbinding and rebinding.

Might want to double check which DC the machine is actually talking to. In my case, I was using wireshark because we thought it was a network problem, but there is probably a better way to tell.

So it seems I am experiencing similar issues as some others on here, so I figured I would share what I have going on to see if anyone else has seen this issue and found a solution.

Currently have a Xserver running 10.8.4 as an OD master.
I have a 10.8.4 client that is bound to both AD and OD.

At the loginwindow, I get the yellow "jelly bean" stating "Some network accounts are available."

AD accounts log in just fine, which is good because we only use AD accounts to actually log in, but I use OD for MCX still. I mostly want this yellow dot and the warning to go away so that users in my computer labs do not think there is an issue with the machine.

SSHing into the machine and running the command ```
sudo killall opendirectoryd
``` "fixes" the issue and the yellow bean goes away within 10 seconds.

If I log in to the client with any AD account, and log out again, the yellow bean is gone as well.

This happens to all of our Macbooks.

Same!!!
So, I unbound, then re-bound via Terminal App and that resolved the issue!

And, same this only occurs on Macbooks.

I did notice that, although it stated that it was bound to Ad, none of the Authentication / Contacts within the 'search policy' were being populated with our Domain Info....