Got a call from our global service desk Friday evening (01/17/2020) about multiple users not being able to access websites. The call was escalated to me due to the volume of users affected. Users were receiving
HTTP Error 403
Initial test was to have one of the affected users try multiple browser for isolation. Websites were working on Firefox but failing on Internet Explorer and Chrome. I had the user enable “HTTP Friendly error” message through Internet Options
Result of change below
Here is the log from web server httperr log.
According to this Microsoft article, this error most of the time is due to large kerberos token which can happen if the user is a member of too many Active Directory groups. No changes have been made globally that will affect all users (As far as we know)
Also the article fix was to make a registry change on the web server. All windows integrated authentication request was failing for internal and external websites including our ADFS authentication. Making a registry change on all the servers is not an option even with GPO (We do not have access to servers hosting external websites).
Next step is to find out the size of the kerberos ticket being sent.
The following powershell will show the result
$token =
[System.Security.Principal.WindowsIdentity]::GetCurrent()
$token | ft Token
Error message from Domain Controller shows
A ticket to the service host/computername.domain.com is issued for account username@domain.com. The size of the encrypted part of this ticket is 12382 bytes, which is close or greater than the configured ticket size threshold (12000 bytes).
This doesn’t add up because my powershell command says the token is 4112 while domain controller is saying 12382.
The PC is not taking nested groups in other child domains into consideration, while the domain controller is able to do a full calculation due to it being a Global Catalog. The following powershell script gave me a full list of all groups the user is part of directly or indirectly.
$token = [System.Security.Principal.WindowsIdentity]::GetCurrent()
# Get current user context
$groupSIDs = $token.Groups # Get SIDs in current Kerberos token
foreach($sid in $groupSIDs) { # for each of those SIDs…
try { # try to..
Write-Host (($sid).Translate([System.Security.Principal.NTAccount])) #
translate the SID to an account name
}
catch { # if we can’t translate it…
Write-Warning (“Could not translate ” + $sid.Value + “. Reason:
” + $_.Exception.Message) # Output a warning and the corresponding
exception
}
}
It shows the user is a member of over 600 groups which one of the groups was nested inside 264 groups in another domain. The group that was being nested had all employees as a member. I removed the group, asked end-users to reboot and they were able to access all websites again.