Microsoft’s regularly release performance tuning guides for Windows Server, this guide for Windows Server 2016 organises performance and tuning guidance across three tuning categories:
This summary stems from a brief conversation within a peer circle. A parallax perspective on the issue of passwords.
Most IT organisations have an IT Security policy, which defines the required password parameters for an organisation. Active Directory provides a method to enforce the password parameters, from their complexity and length to the frequency that they must be changed.
Once a company’s password policy is understood and required parameters are known, internally bad practice can set in and this is not necessarily limited to the end users, IT can equally be at fault. For example the service desk may create all new user or service accounts with the same common password. Password1234$$ or Welcome2015!
So what has this got to do with hacking your own Active Directory?
Using one of the numerous Active Directory password cracking tools on the internet, you can analyse (crack the easy ones) the passwords stored in Active Directory and produce a list of the most common passwords.
These common passwords can then be cross referenced to their owners and with a little bit of mathematics, it is possible to deduce that perhaps with 10 passwords, 70 % of all systems can be accessed, not only is this a rather frightening metric, but this is reality and one attack vector for anyone with access to a domain controller.
This is not a simple problem to fix with the current architecture of Active Directory, but with small process changes and education around the use of common passwords the percentage of systems that could be accessed or compromised may be reduced.
The Microsoft MVP summit was held last week (3rd – 7th November) in Redmond, where I had the good fortune to spend the week with members of various Microsoft product teams that are responsible for what we commonly know as Active Directory. I can genuinely say that in technology terms I have not been this interested in the future of Windows since I did my first Windows Server 2000 course (MOC 1561) back in 1999.
The MVP Summit content is mostly under NDA and I have always respected the NDA and with this in mind all I will say is that over the next few months I will be reading and learning as much as I can on the following areas of Microsoft technology.
I would also recommend that you start to start to think about the concept of Active Directory being an identity provider and that in the future it will all be about managing identities and not solely about managing the technologies that deliver them.
Food for thought, think about what type of identities your business will support, business only or perhaps personal too? What is an identity? What is a personal identity? Who owns the identity? (I will follow up on this concept with another post).
What’s in a name?
Microsoft have announced a new conference “MUTE for Enterprises” which is a wordplay on their current working title of “Microsoft’s Unified Technology Event for Enterprises”.
MUTE is scheduled to take place the week of 4th May 2015 in Chicago and will be every single Microsoft conference rolled into one. Initially I thought fantastic, but now I have had time to analyse the concept I am not sure if it’s a good idea or not. I used to like the technical focus of the dedicated events and the generalisation on TechEd. Let’s hope it’s not another Vista or Windows 8, but only time will tell.
Further details can be found at.
As a side note:
May the 4th is Star Wars Day, will we get Stephen Elop as Darth Vader and Brad Anderson as Han Solo on stage?
Unlike previous versions of this vital information, this is not currently available as a word download, but only as web based information.
These can now be downloaded in PDF format from here.
Microsoft have stated for numerous years that anyone with Kerberos authentication issues often due to users being in multiple groups and commonly known as Token Bloat should increase the MaxTokenSize to 65535 bytes.
Whilst reading Understand and Troubleshoot Dynamic Access Control in Windows Server 2012 guide, I read that
“Previous versions of Windows had a default maximize token size of 12k. However, this value remained too low for many environments and required reconfiguring each computer in the enterprise. Windows Server 2012 and Windows 8 increase the default maximum token size to 48k. This new value is the maximum viable size for SSPI tokens in Windows and may require additional settings changes for applications to support. For example, HTTP settings are required for SSPI tokens over 12K.”
But this article How to use Group Policy to add the MaxTokenSize registry entry to multiple computers also stated the 48K maximum and with a similar reasoning.
“The maximum allowed value of MaxTokenSize is 65535 bytes. However, because of HTTP’s base64 encoding of authentication context tokens, we do not recommend that you set the maxTokenSize registry entry to a value larger than 48000 bytes. Starting with Windows Server 2012, the default value of the MaxTokenSize registry entry is 48000 bytes”.
This lead me to do a little further research as Microsoft stated in the article Active Directory Maximum Limits – Scalability that the “maximum recommended size for a Kerberos ticket is 65,535 bytes”
Getting nowhere fast, I had an email exchange with the Active Directory Documentation team, it was confirmed that this value should now be set to 48K
The Active Directory Maximum Limits – Scalability website should be updated soon (approx. 09/05/2013) to confirm this.
The question now to ask though is – I have set the MaxTokenSIze to 65535 bytes, should I now change it to 48000 bytes?
So I asked the question:-
“What happens to people who have set the key to 65535? Should they test and change it to 48000 now? Will Windows Server 2012 break? Will things fail as a result of having it set to the maximum?”
Kerberos itself doesn’t really understand the concept of a token size because what it transports is opaque to the protocol.
Applications, however, are different and can implement their own constraints such as buffer size. Applications ask SSPI (Kerberos) for the size of the authorization buffer of the authenticating user. If the size reported back is greater than the buffer allocated by the application, authentication fails. The size reported back is the actual size not the maximum size. Therefore, with MaxToken set to 65k and authorization data amounting to 12k; Windows will only report back 12k. MaxTokenSize simply limits the maximum value the SSPI can return to an application. Prior to Windows 8/2012 , most environments would set MaxTokenSize to the maximum because it was nearly impossible to determine a user’s true token size. Therefore, if you set it to the max, and still had an authentication problem it was not because of MaxTokenSize ( at which point engineers would instruct customers to return the setting to the prior value).
With MaxTokenSize defaulting to the max Authentication buffer size for IIS; there shouldn’t be a authentication problem resulting from token size. Http caps out at 48k. Making it higher won’t fix the authentication issue. So it there is no gain people nothing by increasing it.
While the setting in the documentation should mostly be harmless; we should suggest 48k as the ideal setting for MaxTokenSize and point to the Group Policy setting in Windows Server 2012/Windows 8 as the means which to modify it.
and now we know.
Microsoft have updated the must read Active Directory document on Active Directory Forest Recovery.
“The guide contains best-practice recommendations for recovering an Active Directory forest if forest-wide failure renders all domain controllers in the forest incapable of functioning normally. The steps, which you must customize for your particular environment, describe how to recover the entire Active Directory forest to a point in time before the critical malfunction. They also ensure that none of the restored domain controllers replicate from a domain controller with potentially dangerous data.
The steps in this guide apply to Active Directory forests where the domain controllers run Microsoft® Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003 operating systems.”
Please ignore the fact that the document is titled “Windows Server 2008: Planning for Active Directory Forest Recovery” it covers all supported versions of Windows Server that can run Active Directory.
April 2013 Update.
Download it here.