I did not delve into the entire situation in detail. I found the cause of the problems and a possible solution that I used. So I will mention this information here and provide some links for more detailed information.
Privilege Attribute Certificate (PAC)
An important piece of information at the beginning is that Microsoft extended the authentication protocol Kerberos with authorization data. These are contained in the Privilege Attribute Certificate (PAC) Data Structure [MS-PAC], which is a standard Kerberos Protocol Extensions [MS-KILE]. Client Kerberos tickets then contain group membership data (a list of groups the user is a member of), security metadata, policy information, etc.
The description is available in MS articles [MS-PAC] and [MS-KILE].
Problem with SSO on the web server
A user contacted me, saying that Single Sign-On (SSO) suddenly stopped working for some web applications. These applications were running on Apache Tomcat or Apache HTTP Server. When the user tried to log in, they received a blank page. This was because error messages were disabled on the server. When error display was enabled, the following error appeared:
Bad Request Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit. Authorization: Negotiate
Why the error occurred
When Kerberos authentication is set up for access on the web server, the server sends these details to the client in the http header (HTTP/1.1 401 Authorization Required, WWW-Authenticate: Negotiate, etc.). The client obtains the necessary data and sends it back to the server in the header. The data contains a Kerberos ticket, which includes user information, and thanks to [MS-PAC], also a list of all groups the user is a member of. The Kerberos ticket is encrypted and sent in the header, for example, Authorization: Negotiate YIIJvwYGKwYBBQUCoIIJszCCCa (the string of characters is very long in practice).
On application servers, a certain maximum value is set by default for how large the http request header can be. If the client sends more data (my user was a member of about 60 groups), the server does not process the data and displays the above error.
Solution to the problem
In the application server configuration, we can change the default value for the header size. On Apache HTTP Server, the default value is 8190 B. We can set a different value in the server configuration or virtual host, typically the httpd.conf file, using the following directive.
LimitRequestFieldSize 16380
On Apache Tomcat, the default value is 8192 B. We can change it by configuring the HTTP Connector, i.e., the Connector element, using the maxHttpHeaderSize attribute. Example configuration:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxHttpHeaderSize="16380" />
On Internet Information Services (IIS), HTTP requests are handled by the http.sys driver, and the default value is 16384. We can change it using the registry, creating DWORD parameters MaxFieldLength and MaxRequestBytes in the path HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\HTTP\\Parameters, setting the desired value, for example, 48000. Then, it is necessary to restart the HTTP Service and IIS Admin Service.
Problem with logging in on Windows 7
The issues with logging into web applications were resolved as described above. Several months passed, and the same user contacted me again, saying they could not access network drives. On their station, I found that they were logging into a cached profile. My account logged in without problems, and we tried their account on another computer, which also worked (it later turned out this was due to Windows 8). I concluded that the problem was with the profile and wanted to create a new one. Interestingly, after deleting the original profile, the login occurred, but the new profile was not created from the network (but from the local default), policies were not applied, and nothing else.
I went through the event logs and found the cause. In the system log, there was an entry (only a Warning, I would have expected an Error) from the source Security-Kerberos with Event ID 6. It says that the Kerberos Token is too large and does not fit into the Token Buffer (which has a size of 12000 B), which is probably caused by the user being a member of too many groups. There is even advice to reduce the number of groups or change the buffer size.
Log Name: System Source: Microsoft-Windows-Security-Kerberos Date: 7.1.2014 17:27:14 Event ID: 6 Task Category: None Level: Warning Keywords: Classic User: N/A Computer: POCITAC.firma.local Description: The kerberos SSPI package generated an output token of size 12054 bytes, which was too large to fit in the token buffer of size 12000 bytes, provided by process id 4. The output SSPI token being too large is probably the result of the user uzivatel@FIRMA.LOCAL being a member of a large number of groups. It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize.
Troubleshooting
The cause of the problem is the same as in the first case, too large Kerberos ticket, because the user is a member of too many groups (in this case about 100). The OS has a slightly larger default size (about 12kB) than application servers (about 8kB).
In the information for Windows 7, it is recommended to minimize the number of groups the user is a member of. Apparently, MS later changed its mind, as there are now many situations where we need to include users in many groups for authorization. So the limit of 12kB, which was in Windows 7 and earlier, was raised to 48kB in Windows 8. The whole situation is nicely described in the article MaxTokenSize and Windows 8 and Windows Server 2012.
So I tried adding an entry of type REG_DWORD with the name MaxTokenSize and value 48000 to the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters on the station. The station then needs to be restarted.
However, immediately after the restart, the login problem persisted. The logged event changed, but its message that the application does not support the set buffer size seemed strange to me (the application is Windows).
Log Name: System Source: Microsoft-Windows-Security-Kerberos Date: 10.1.2014 11:09:08 Event ID: 15 Task Category: None Level: Warning Keywords: Classic User: N/A Computer: POCITAC.firma.local Description: The kerberos SSPI package generated an output token of size 13283 bytes, which was too large to fit in the token buffer of size 12000 bytes, provided by process id 4. The application needs to be fixed to supply a token buffer of size at least 48000 bytes.
After further studying information, such as the description How to use Group Policy to add the MaxTokenSize registry entry to multiple computers, I decided to set this value using Group Policy for the entire company. After applying the policy and restarting, everything started working and no error was logged.
List of users and number of groups
In connection with the described problem, it may be useful to obtain a list of AD users along with the number of groups they are members of. Of course, the number of groups is not entirely decisive, it depends on the length of the names and other factors. This is probably best done using PowerShell.
Get-ADUser -Filter * -SearchBase "OU=Firma,DC=Firma,DC=local" -ResultPageSize 10 | ForEach-Object {
$groupc = (Get-ADPrincipalGroupMembership $_.SamAccountName | Measure-Object).Count
Write-Host $_.SamAccountName $groupc
}
The SearchBase parameter can be used optionally if we want to take users only from a certain container. I added the ResultPageSize parameter because I was getting the following error after displaying a certain number of records when listing more users.
Get-ADUser : The server has returned the following error: invalid enumeration context. At line:1 char:1 + Get-ADUser -Filter * -SearchBase "OU=Firma,DC=Firma,DC=local" | ForEach-Ob ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Get-ADUser], ADException + FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADUser
There are no comments yet.