First published on TechNet on Aug 31, 2014
Jim Kelly here [edited by Richard P. Sasser], I've talked to a few customers and engineers lately, asking about character and entry limitations with the ServicePrincipalName Attribute.
It is a common practice to use the same security principal to run multiple instances of an application, such as SQL. In order for Kerberos to work properly in this scenario, the security principal needs to have service principal names for each named instance of the application. For example, let’s say I have an application named FOO, and a security principal of type user, FOOSVCACCT. If FOO runs on server1.hostname.ex and server2.hostname.ex, the service principal names for FOOSVCACCT look like:
Foo/server1.hostname.ex
Foo/server2.hostname.ex
In large environments, where there are potentially thousands of deployed applications or SQL instances, each with a unique ServicePrincipalName (SPN), you could run into potential limitations with the size of the attribute if you attempt to use the same security principal across too many instances.
The next question is, “When should I use different security principals for different instances of the same application?” Unfortunately, the answer to that is “It depends”. Using the same principal increases the surface area, which means greater penetration in a compromise, and a higher tendency not to rotate the password of the service account due to the impact. Using a different principal everywhere increases the management overhead significantly, UNLESS your application supports Group Managed Service Accounts . So ultimately this falls down to a business decision within the organization.
Why do I care about Service Principal Names?
From a security perspective, applications without properly registered Service Principal Names may fall back to NTLM. Now, we know that you’ve disallowed NTLMv1 on your network, RIGHT , so that shouldn’t be an issue, but on the off chance that some third party application or service requires that you continue to support NTLMv1 or some server passes it through, a downgrade can be potentially serious.
Applications or Services requiring the NTLMv1 authentication protocol should be reviewed immediately. NTLMv1 hashes are extremely weak and cause a serious concern for security. I’ve seen statistics which indicate an NTLMv1 hash can be cracked in seven seconds. If you allow NTLMv1, you are not secure. Disabling NTLMv1 in your environment is typically a non-trivial task and beyond the scope of this blog [ RICK - I'll talk some about this in another, later post]. Settings are documented HERE . Cryptographic details HERE .
From the performance perspective, NTLM can be an inefficient protocol especially if applications build and tear down sessions frequently. Every session will require the NTLM trust referral path to be walked, which can create serious delays, vs Kerberos, which merely hands the Server the same TGS it used 30 minutes ago.
Ok, so what are the exact limits to help me make a business decision
With Windows Server 2003, Microsoft implemented a new technology for large multivalued attributes, called Linked Value Replication , which allowed things like User Group Membership to exceed the previous limit of 5,000 members in a single group in Windows 2000. As stated in the Active Directory Maximum Limits document below, through the use of LVR , the number of members in a group has been reported from a customer production environment to exceed 4 million members , and Microsoft’s internal scalability testing reached over 500 million members in a single group. I mention this because the ServicePrincipalName is a multivalued attribute, however it is not a Linked Value attribute, which means it will have limits on the amount of entries it can contain.
The ServicePrincipalName attribute is a multi-valued, non-linked, text string based attribute. In order to find this limit, we need to examine the data store itself.
From: http://technet.microsoft.com/en-us/library/cc772829.aspx
Maximum Database Record Size
The maximum size of a database record is 8110 bytes, based on an 8-kilobyte (KB) page size. Because of variable overhead requirements and the variable number of attributes that an object might have, it is impossible to provide a precise limit for the maximum number of multivalues that an object can store in its attributes. For all practical purposes, the size of objects is not significant in Active Directory if you use the recommended guidelines described in "Static Data" later in this chapter.
The only value that can actually be computed is the maximum number of values in a nonlinked, multivalued attribute when the object has only one attribute (which is impossible). In Windows 2000 Active Directory, this number is computed at 1575 values. From this value, taking various overhead estimates into account and generalizing about the other values that the object might store, the practical limit for number of multivalues stored by an object is estimated at 800 nonlinked values per object across all attributes.
Note
Attributes that represent links do not count in this value. For example, the members linked, multivalued attribute of a group object can store many thousands of values because the values are links only.
The practical limit of 800 nonlinked values per object is increased in Windows Server 2003 and later. When the forest has a functional level of Windows Server 2003 or higher, for a theoretical record that has only one attribute with the minimum of overhead, the maximum number of multivalues possible in one record is computed at 3937. Using similar estimates for overhead, a practical limit for nonlinked multivalues in one record is approximately 1200. These numbers are provided only to point out that the maximum size of an object is somewhat larger in Windows Server 2003 and later.
What’s important here is the reference to 1,200 entries. There is a restriction or limitation on the total amount of entries that a Multivalued, Non-Linked attribute in Active Directory can contain. Note that the limit is a ‘practical limit’. The size of each individual entry may make the actual limit something less than 1200.
In Summary:
Whether you create your own User Account to use as application or service accounts, or if you use the new Group Managed Service Account in Windows Server 2012 R2 Active Directory, The ServicePrincipalName attribute has a set of requirements and limitations:
1. Each ServicePrincipalName must be unique in the Active Directory FOREST .
2. No individual entry can be longer than 256 characters.
3. The practical limit for the total number of entries cannot exceed 1,200.
Musings by two previous Microsoft Certified Masters for Directory Services:
Jim Kelly (PFE ARCHITECT)
Rick Sasser 'Sho'nuff'