Active Directory

Top 6 (Independent) Microsoft Active Directory Integration Experts to Follow

Blatant self-promotion, but I wanted to share a blog post from OneLogin that gives their list of top Active Directory experts (including me) and our top tips on “What you should never do when working with Active Directory“.

Top 6 (Independent) Microsoft Active Directory Integration Experts to Follow

Experts

Does anyone else have any other “No No’s” they would like to share?

MaxTokenSize – Change of recommendation from Microsoft.

 

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”

image

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?”

The response:-

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.

http://blogs.technet.com/b/askds/archive/2012/09/12/maxtokensize-and-windows-8-and-windows-server-2012.aspx

and now we know.

Active Directory

Active Directory Forest Recovery – Whitepaper updated.

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.

Best Practices for Securing Active Directory

 

Microsoft have released a new document which contains best practice recommendations to assist organisations in enhancing the security of their Active Directory installations.

Microsoft state that “In implementing these recommendations, organisations will be able to identify and prioritise security activities, protect key segments of their organisation’s computing infrastructure and create controls that significantly decrease the likelihood of successful attacks against critical components of the IT environment“.

This document discusses the most common attacks against Active Directory and countermeasures to reduce the attack surface, and recommendations for recovery in the event of complete compromise.

Download

Mergers and Divestitures: Spoof a domain to implement a DFS Namespace.

 

I have just returned from the MVP summit in Redmond, where I spent the best part of a week with the Active Directory Product Group and other Directory Services MVP’s.  In conversation with a fellow Directory Services MVP Mike Kline, I mentioned a way that I had spoofed a domain to ensure a DFS namespace continued to seamlessly function after a company we had acquired was integrated into our environment.  Mike thought it would be a good insight for me to share.

Scenario:

We are company XYZ Ltd. and we have an Active Directory forest called xyz.com.

We buy ABC Ltd. who are part of a larger company and they have servers in a domain called continent.abc.com, which is a child domain in a global forest.

Ignoring logistics around user accounts and file permissioning (which was also resolved), when company became our entity, we acquired their file servers (but no Domain Controllers)but we had to enable them to be able to access their existing data in the same DFS namespace as a majority of the files all had embedded links and shortcuts.

Resolution:

The way I achieved this was by using a standalone DFS Server and DNS.

In our domain xyz.com I built a domain joined windows server called the same as the domain name that was used for DFS-N resolution in the acquired company. In this case continent(.xyz.com).

In our domain (xyz.com) I then created a DNS zone called abc.com and then created a CNAME pointing to continent.xyz.com within the abc.com zone, this way I ended up with a server addressable as continent.abc.com. On continent.xyz.com I installed DFS as a standalone implementation and configured all the targets, after which I was left with a server emulating the acquired companies old domain and DFS Namespace.

It goes without saying that this was a temporary solution, as the standalone server was a single point of failure, but it got us over the initial hurdle of seamless data access in a hurry.

rc_lrg

Active Directory 5th Edition

Over the past view months I have been quietly working on the revised edition of the O’Reilly Active Directory Bible.

I am pleased to say Brian has finished the book and it is now available.

image

For further information checkout Brian’s Blog at http://briandesmond.com/blog/active-directory-5th-edition/

Performance Tuning Guidelines for Windows Server 2012

This guide follows on from the excellent Windows Server 2008 and 2008 R2 Performance Tuning Guidelines and describes important tuning parameters and settings that you can adjust to improve the performance and energy efficiency of the Windows Server 2012 operating system. It describes each setting and its potential effect to help you make an informed decision about its relevance to your system, workload, and performance goals.

The guide is for information technology (IT) professionals and system administrators who need to tune the performance of a server that is running Windows Server 2012.

Included in this white paper:

  • Choosing and Tuning Server Hardware
  • Performance Tuning for the Networking Subsystem
  • Performance Tools for Network Workloads
  • Performance Tuning for the Storage Subsystem
  • Performance Tuning for Web Servers
  • Performance Tuning for File Servers
  • Performance Tuning for a File Server Workload (FSCT)
  • Performance Counters for SMB 3.0
  • Performance Tuning for File Server Workload (SPECsfs2008)
  • Performance Tuning for Active Directory Servers
  • Performance Tuning for Remote Desktop Session Host (Formerly Terminal Server)
  • Performance Tuning for Remote Desktop Virtualization Host
  • Performance Tuning for Remote Desktop Gateway
  • Performance Tuning Remote Desktop Services Workload for Knowledge Workers
  • Performance Tuning for Virtualization Servers
  • Performance Tuning for SAP Sales and Distribution
  • Performance Tuning for OLTP Workloads

Performance Tuning Guidelines for Windows Server 2012