Running ACS5.2, Windows XP Pro, Window Server 2003 and Cisco Anyconnect Client. When the machine name password changes between the PC and the AD server the ACS will error out with "24485 Machine authentication against Active Directory has failed because of wrong password"
TAC has been working with us on this and sees the error in the logs but does not have an answer on with to do to solve this. It has the same problem with Wireless Zero.
Once the PC is rebooted the error goes away for 30 days. We are in a hospital setting so this is a not just a minor problem
Did you find a solution for this?
I'm dealing with the same issue and surpisingly enough the TAC guys has never seen this issue before....
Sorry to hear you have this problem too.... but glad to see that we are not the only one having this problem. TAC wants us to contact Microsoft... insisting that this is a Windows issue. We are looking to do that today.
Our case number is 620073983. We have lots of logs and details in the case. If you have an open TAC case you may want to refer them to this. Maybe they can put their heads together and solve this.
Well if your machine password changes, that changes in AD and not on the machine until the machine is rebooted.
So unless there is a way that the machine knows the password changes and then authenticates using the new password, I don't see how that would work. Your best bet is to use a management tool to schedule a reboot of these machines. I have a client that does in a hospital just because of this situation and because the machine never get shutdown unless the battery power shuts the machine down.
Sent from my iPhone
We thought of doing scheduled reboots... but may of the wireless devices are used to do bedside medicatioin administratioin with could take place anytime of the day.
Wouldn't be true that even with a scheduled reboot let's say midnight that if the password is scheduled to change at 1:00AM then as soon as the wireless device reauthenticates the ACS will break again and require another reboot to occur???
Thanks for your response,
My clients do this like at 2am. I would think that after a reboot the machine would release the cached credentials. So the think is, if you force a password change at 1am, you would need to schedule a reboot soon after. I would believe that would work since what you have been doing is a single reboot to fix the issue. Maybe Microsoft has a better way of doing this, but I don't know.
Sent from my iPhone
The only problem with the thought of a scheduled reboot, is the machine is the one that initiates the machine password change with AD. By default this setting is every 30 days after joining the domain. You cannot tell it to change at 1:00 everyday and then reboot.
The problem lies in after the machine has said to AD, here is my new password, the machine tries to reauthenticate at the wireless systems time and for whatever reason, the PC and AD disagree on the password.
So the machine initiate the password change, so the machine should refresh it cache with the new password and AD should have it. ACS will send whatever credentials the machine sends. It's either the machine is still sending the old password or AD hasn't yet updated. I would like to hear what Microsoft says about this.
Sent from my iPhone
Tom, our case ref is 619898011 if it helps.
It's kinda strange that TAC sends you to MS support.
I don't understand the process behind the computer password change in AD, especially when the computer password is set under AD to never expire ...
Now hopefully in a month or two when the TAC engineer will reach the bottom of the list of the output/config/debug/dumps he can ask, we'll start working on this.
Thibault and Scott,
We are setting up a Microsoft Phone Support Case for next Wednesday. We are hopeful to get this resolved. I will keep you up to date on what we find.
Here is Microsoft's first response. We have not tested this yet... but it does seem to describe the problems and there are 2 work arounds.
So it looks like this is the offical Microsoft answer:
I had a discussion with an escalation resource on this case and updated him on what we found so far, From what I understand this is a known issue when the client is using PEAP with computer authentication only and the workarounds to this problem are the 2 solutions lined up in that article that I sent you.