any One have experienced the below alert in your systems.
received a alert on one of on-prem DC's and no clue about it
The Security Account Manager failed a KDC request in an unexpected way. The error is in the data field. The account name was MMM123123 and lookup type 0x800.
@Rajeshkumar-1412, Can you tell me at what instance this error comes up. I am trying to see if I can a quick answer for you.
Also would like to state that this forum is only for queries related to Azure AD and not the on-prem Active Directory. Will get you the details of the Forum for On-Prem Active Directory, so that you can post it there if it needs deeper investigation.
Hello Rajeshkumar-1412 ,
As per my experience troubleshooting Active directory domain controllers, In most of the scenarios where we get SAM failures on a DC , The solution is to reset the secure channel of this DC. As this server is a domain controller, you would need to reset the secure channel of this server with respect to the domain controller with PDC role because PDC is the server which has the most recent password for domain objects. You can use netdom command for the same. Please follow the steps for the same.
Open the services console using services.msc command.
Stop the Kerberos Key Distribution center service on the box and set it to the disabled state.
Then we will purge all the existing cached kerb tickets using the command klist purge . This is done to make sure that the cached tickets are not used for any request by this DC.
Netdom /resetpwd /server:< IP address of the PDC (preferably) or any good DC whose secure channel is intact and not broken> /userd:\Administrator /passwordd:
The above command just updates the password of the computer account on the DC ip specified on the /s section. And Kerberos service tickets are always encrypted by the password of machine or user accounts depending on who is accessing. In this case the Domain controller account was being used.
We reset the secure channel generally with respect to the PDC (DC with the PDC emulator role.) as this is the server that holds most recent passwords for all security principles(users, machines) in active directory. If rebooting the server is not possible then we can use the kerbtray.exe(GUI) or klist.exe(CLI) utilities to purge the old cached Kerberos tickets.
After the whole process we restart the KDC service and set it to automatic once again. Only if reboot of server is not possible.
If reboot is possible then It is suggested to point it to the PDC for primary DNS server .
And then restart the server with KDC still disabled. Once the machine is up and running. Start the KDC service and set it to automatic.
This will let the KDC to cache tickets again and this machine
Point the server again to itself for DNS if everything seems normal and the server is servicing clients.
In order to check the same you can run dcdiag /v:localhost > dcdiag.txt on the server using Domain admin credentials and the output in text file can give you more insights . If the default checks pass with any error then the server should be working perfectly.
Hope the above helps. In case the information provided helped , please do mark it as answer so that its helpful to others searching for similar solutions in the community. Also we have a directory service forum where you can find many experts for any directory service related issues. We would suggest to use that in future if you have active directory related issues as the probability of an answer in shorter time would be higher.
Thank you.
QnA currently only supports the products listed in right-hand pane (more to be added). Your post is off topic here. Better to reach out to subject matter experts in dedicated forums over here.
https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserverDS
(please don't forget to mark helpful replies as answer)
15 People are following this question.
