What's that saying about assumptions?

I wonder if there is a word that invokes more feelings of frustration for an IT dude than kerberos?

This shouldn't be the case because there is a great number of useful resources out there to help you understand and troubleshoot the issues that occur in kerberos land. However, none of these troubleshooting guides remind you of one very important thing, be patient!

This is because kerberos is a security protocol that deals with distributed objects and services that involve synchronization and expiration and unless your name is Mark Russinovich and you have every Windows related command at your disposal, you are sometimes just going to have to wait a bit for certain things to synchronize or expire.

Don't assume that adding an SPN will immediately cause kerberos authentication to start working and read the documentation (that last bit was for me).

Yesterday I was working on a custom DSC resource for adding SPNs and my code ended up generating a couple of really weird looking SPNs which not only failed to enable kerberos authentication but also disabled my ability to establish a PowerShell CIM session with the machine in question. I removed the dubious SPNs but still could not start a CIM session. I was ready to trash the machine and rebuild it because I assumed it was toast but a still quiet voice reminded me that I would not learn anything by doing so. I thought "tomorrow is another day" and left it.

When I tried again today everything was back to normal and I realised what had happened: the domain controllers had synchronized, the old kerberos tickets had expired and my machine was back to normal. I added the correct SPNs, waited a few minutes and all was good in the land of kerberos :-)

This helped:


and this was the documentation I referred to:
https://msdn.microsoft.com/library/cc281253.aspx

Later dudes