Category: Security
HTTP 400 IIS Token Bloat
An old “friend” keeps keeps showing up in different environments. So since my old Blog is gone, I will add this again.
But this time I’ll just copy the info from Microsoft’s website.
Thank you Microsoft: https://support.microsoft.com/en-us/help/2020943/-http-400—bad-request-request-header-too-long-error-in-internet-info
HTTP 400 – Bad Request (Request Header too long)” error in Internet Information Services (IIS)
Symptoms
A domain user attempts to browse to a website hosted on Internet Information Services (IIS) 6.0 or higher by using Internet Explorer 6.0 or later. The website is configured to use Kerberos authentication. Instead of receiving the expected web page, the user is presented with an error message similar to the following:
HTTP 400 – Bad Request (Request header too long)
Cause
This issue may occur when the user is a member of many Active Directory user groups. When a user is a member of a large number of active directory groups the Kerberos authentication token for the user increases in size. The HTTP request that the user sends to the IIS server contains the Kerberos token in the WWW-Authenticate header, and the header size increases as the number of groups goes up. If the HTTP header or packet size increases past the limits configured in IIS, IIS may reject the request and send this error as the response.
Resolution
To work around this problem, choose one of the following options:
A) Decrease the number of Active Directory groups that the user is a member of.
OR
B) Modify the MaxFieldLength and the MaxRequestBytes registry settings on the IIS server so the user’s request headers are not considered too long. To determine the appropriate settings for the MaxFieldLength and the MaxRequestBytes registry entries, use the following calculations:
-
- Calculate the size of the user’s Kerberos token using the formula described in the following article:
New resolution for problems with Kerberos authentication when users belong to many groups
http://support.microsoft.com/kb/327825 - Configure the MaxFieldLength and the MaxRequestBytes registry keys on the IIS server with a value of 4/3 * T, where T is the user’s token size, in bytes. HTTP encodes the Kerberos token using base64 encoding and therefore replaces every 3 bytes in the token with 4 base64 encoded bytes. Changes that are made to the registry will not take effect until you restart the HTTP service. Additionally, you may have to restart any related IIS services.
- Calculate the size of the user’s Kerberos token using the formula described in the following article:
NOTE: Depending on your application environment, you could also consider configuring the web site to use NTLM instead of Kerberos to work around this problem. Some application environments require Kerberos to be used for delegation purposes, and Kerberos is more secure than NTLM, so it is recommended that you do not disable Kerberos before considering the security and delegation ramifications of doing so.
More Information
By default, the MaxFieldLength registry entry is not present. This registry entry specifies the maximum size limit of each HTTP request header. The MaxRequestBytes registry entry specifies the upper limit for the total size of the Request line and the headers. Typically, this registry entry is configured together with the MaxRequestBytes registry entry. If the MaxRequestBytes value is lower than the MaxFieldLength value, the MaxFieldLength value is adjusted. In large Active Directory environments, users may experience logon failures if the values for both these entries are not set to a sufficiently high value.
For Internet Information Services (IIS) 6.0 and later, the MaxFieldLength and MaxRequestBytes registry keys are located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters. Configure them as shown in the following table:
Name | Value Type | Value Data |
MaxFieldLength | DWORD | (4/3 * T bytes) + 200 |
MaxRequestBytes | DWORD | (4/3 * T bytes) + 200 |
Alternatively you may set the registry keys to their maximum values shown below. The Administrator should consider all potential security ramifications if he makes any changes to the registry settings:
Name | Value Type | Value Data |
MaxFieldLength | DWORD | 65534 |
MaxRequestBytes | DWORD | 16777216 |
IMPORTANT: Changing these registry keys can be considered extremely dangerous. These keys allow larger HTTP packets to be sent to IIS, which in turn may cause Http.sys to use more memory and may increase vulnerability to malicious attacks.
NOTE: If MaxFieldLength is configured to its maximum value of 64KB, then the MaxTokenSize registry value should be set to 3/4 * 64 = 48KB. For more information on the MaxTokenSize setting, please see the Microsoft knowledge base article KB327825 listed below.
Change the name of your new Azure subscription
This is not a straight forward thing, even do you would think so.
1. Open browser, enter the following: https://account.windowsazure.com/Subscriptions
- Sign inn with your Azure Subscription Owner ID
- Press the Subscription you want to change the name of
- On the right hand side, “Edit Subscription details”
- Enter the new name bellow “ SUBSCRIPTION NAME”
Name is now changed, but you need to give access to the subscription, so that you can use it in your environment.
2. Still in the account.windowsazure.com/subscriptions view
- Press the Portal icon upper right
- Find the subscriptions icon on the left side menu
- Press the subscription you want to give access to
- Press the MSN icon, so you can choose Users
- Press Add
- Choose the access level you want to delegate, and find the user.
Now you can utilize the new subscription in your Azure portal
Connect to Azure/Office365 based on encrypted txt file
$encrypted = Get-Content “D:\Scripts\Azure_Encrypted_Password.txt” | ConvertTo-SecureString
Select Azure Subscription to work with
When you have a larger organisation, you will have several Azure Subscriptions to work against. So here is how you switch.
1. Open Powershell
2. Type in: Add-AzureRmAccount
(in pop-up enter admin id and password)
3. It will list up the subscription you are connected to when you have authenticated
4. Type in: Get-AzureRmSubscription
(will list out all your subscriptions)
5. Find the Subscription you want to connect to
6. Type in: Select-AzureRmSubscription -SubscriptionId “ENTER THE SUBSCRIPTION ID”
You can choose SubscriptionName too, but I prefere SubscriptionID
Can’t Create Resources in Resource Group
I created a resource group and gave my colleague the contributor access to the resources group.
Then he was going to deploy Logic App, but got an error that he does not have access and is not authorized. So he tried to deploy a VM, same issue.
I deployed Logic App for him (not problem).
The error he gets looks like this:
Resource creation fails with the error which looks like below- Registering the resource providers has failed. Additional details from the underlying API that might be helpful: ‘AuthorizationFailed’ – The client xxx@xxx.com’ with object id ‘af648edh-5336-sf55-ff2f-14873afdc259’ does not have authorization to perform action ‘Microsoft.Compute/register/action’ over scope ‘/subscriptions/245455vgd4-34gg-afe4-975f-3345gdgs34s’. (Code: AuthorizationFailed)
Hmmmm….. What’s going on here?
With the contributor access to a resource group, you can create a resource e.g. a VM or Logic App. What went wrong here if we look at the error message and focus on ‘Microsoft.Compute/register/action’ over scope ‘/subscriptions/245455vgd4-34gg-afe4-975f-3345gdgs34s’. is that he is not authorized to create a resource, it is the authorization error to register a resource provider. So how do we solve it?
Well after a bit of Googling if found a solution that worked for me,
- Log into Azure with an identity which has a subscription level access to register a resource provider e.g. admin/owner.
- Using PowerShell (PoSh) register the resource providers you need at the subscription level. You can also see which providers are available and registered already.
Open Powershell and enter the following:
– Login-AzureRmAccount
#List out all Subscriptions you have access to
– Get-AzureRmSubscription
– $subscriptionId= “<Subscription Id>”
– Select-AzureRmSubscription -SubscriptionId $subscriptionId
– Get-AzureRmResourceProvider -ListAvailable | Register-AzureRmResourceProvider -Force
Get Users based on LastLogOnTimeStamp x number of days
December 16, 2019
Active Directory, Powershell, Security, Tips and Trix, Windows
No Comments
vincent
active directoryadpowershellsecuritytooluser