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

From Tree to Tea

I recently wrote some help comments for a PowerShell function and needed to show an example directory structure and because I have, ermm, issues, I wanted a way to do it exactly the same in all my help comments. So, the inevitable Google search began and I soon discovered tree.exe, which did the trick.

I am blogging about this because tree.exe comes with a nasty little issue that I want to remember (and you can benefit - how nice of me ;-)). Running the following produces a tree structure with garbage encoding:

PS:\>Tree $Path /F | Out-File C:\Temp\tree.txt

And adding the -Encoding parameter doesn't help. The only way I managed to make this useful is to pipe the tree output to the clipboard and paste it into notepad, like so:

PS:\>Tree $Path /F | Clip

Result!

This stackoverflow thread helps explain the issue nicely: http://stackoverflow.com/a/139302

SQL Service SIDs

This is a new one to me...

I set up an SMB Share on the Backup directory for a SQL Server 2016 instance (using DSC of course) and assigned the SQL Server AD account full access, only to find that I was getting an "Access Denied" exception when I tried backing up using the share but not when backing up using the local path. This made no sense because the AD account had full access to the folder and the share (or so I thought).

However, Microsoft has been doing stuff with security accounts and promoting Managed Service Accounts as a best practice so I figured "what the heck" and tried replacing the AD account with the SQL Server Service (i.e. NT Service\MSSQLSERVER) on the share...and what do you know, it worked.

Turns out that the SID for the AD account and the the SID for the SQL Server Service are not the same so even though the account does have access to both the folder and the share it only has access to the folder via the SQL Server Service. To sort this out you need to use the same thing for both, either the SQL Server Service or the AD Account but you can't mix the two.

IT huh, almost 20 years on and still learning the basics. Later dudes!