Merge pull request #8544 from MicrosoftDocs/main

Auto push to live 2025-03-24 02:00:02

Author: Deland-Han

support/azure/devops/git-clone-push-operation-failing-devops-repo.md

@@ -3,9 +3,9 @@ title: Git clone or Git push fails to an Azure DevOps repository
 description: This article discusses problems that might occur when you try to perform Git clone or Git push function to an Azure DevOps repository.
 author: HaiyingYu
 ms.author: haiyingyu
-ms.reviewer: kirt
+ms.reviewer: kirt, dmittal
 ms.topic: troubleshooting 
-ms.date: 05/19/2023
+ms.date: 03/24/2025
 ms.service: azure-devops
 ms.custom: sap:Repos
 ---
@@ -42,7 +42,7 @@ To learn more about Git environment variables, see [Git Internals - Environment
 
 If you're using a proxy server but the Git configuration isn't set to connect through the proxy server, you might see the 407 or 502 error messages. This issue also occurs when the connection can't establish through the proxy server, and you see the errors similar to "unable to access <`your github url`\>:" or "couldn't resolve host `github.com`".
 
-### Solution: Configure Git to use the proxy server
+### Recommendation: Configure Git to use the proxy server
 
 Run `git config --list` to get a list of all the Git configuration on the system, and check whether the proxy server is in use.
 
@@ -65,13 +65,13 @@ For more information on Git configuration, see [Git Config Documentation](https:
 
 If Git is using a local self-signed certificate, you might see the error "SSL certificate problem: unable to get local issuer certificate."
 
-### Solution 1: Disable the TLS/SSL verification
+### Recommendation 1: Disable the TLS/SSL verification
 
 If you've installed a local Team Foundation Server (TFS) and if you want to disable the TLS/SSL verification that Git performs, run the following command:
 
 `git config --global http.sslVerify false`
 
-### Solution 2: Configure the self-signed certificates in Git
+### Recommendation 2: Configure the self-signed certificates in Git
 
 If you want to continue the TLS/SSL verification that Git does, follow these steps to add the root certificate in the local Git:
 
@@ -122,20 +122,44 @@ If you want to continue the TLS/SSL verification that Git does, follow these ste
 
 If your account name or domain password has changed, or you're getting an authentication error, there could be authentication and credential cache issues.
 
-### Solution: Reset the Git credentials manager (GCM)
+### Recommendation: Reset the Git credentials manager (GCM)
 
 To resolve the authentication error or credentials cache issues, begin by following the [Troubleshooting checklist](#troubleshooting-checklist) to get the error information, and then follow these steps:
 
-1. Run the `git config --list` command, and then check if you're using Git Credentials Manager (GCM). If the `credential.helper` is set to manager, then GCM is in use.
-1. Reset the GCM by following these steps:
+1. Run the `git config --list` command, and then check if you're using Git Credentials Manager (GCM). If the `credential.helper` is set to manager, GCM is in use.
+1. Follow these steps to reset the GCM:
     1. Run the `git config --global --unset credential.helper` command to unset the GCM.
-    1. Run the `git config credential.helper manager` command to set the GCM back. Alternatively, follow these steps to delete the credentials cache first:
-        1. When unset, search for **Credentials Manager** in Windows search, select **Open**, and then remove any credential that is for a Git repo.
-        1. Go to _%localappdata%/GitCredentialManager_ path, and then delete the _tenant.cache_ file.
-        1. Set the GCM back by running the `git config credential.helper manager` command.
+    1. Run the `git config --global credential.helper manager` command to set the GCM back.
+    
+   Alternatively, you can follow these steps to remove cached credentials:
+   - On Windows, Git credentials are stored in the Windows Credential Manager. You can access it in the following ways:
+
+     - Using GUI (Windows Credential Manager):
+
+       1. Open Control Panel and select **User Accounts** > **Credential Manager**.
+       1. Select **Windows Credentials**.
+       1. Look for entries related to `git:https://dev.azure.com/<orgname>` or your Git provider and manage them. For github, it's like `git:https://github.com/`.
+       
+     - Using command line:
+
+       1. Run `cmdkey /list | findstr "git"` to list Git credentials.
+       1. Run `cmdkey /delete:https://dev.azure.com/<orgname>` to delete the credentials.
+       1. If you need to reset credentials and re-enter them, run `git credential reject https://dev.azure.com/<orgname>`.
+
+    - On MacOS:
+    
+      - `git credential reject https://dev.azure.com/<orgname>` 
+    
+        When you run this command, you're instructing Git to invalidate or remove the stored credentials for the specified URL. This means that the next time you try to access the repository at that URL, Git will prompt you to enter your credentials again. This is useful if you need to reset your credentials. 
+
+      - `git credential approve https://dev.azure.com/<orgname>` to approve the credentials.
+
+        This command is used to manually store and approve credentials for future use, which ensures that you won't be prompted for credentials each time.
+
 1. Perform the cloning operation to verify if the issue is resolved.
 
-**Note:** Depending on the version of Git for Windows, the `credential.helper` value would be different. See the following table for details:
+> [!NOTE]
+> Depending on the version of Git for Windows, the `credential.helper` value is different. See the following table for details:
 
 |Versions of Git for Windows|Git Credential Manager for Windows|Git Credential Manager Core|Git Credential Manager (Renamed from GCM Core)|
 |--|--|--|--|

support/developer/webapps/iis/www-authentication-authorization/http-bad-request-response-kerberos.md

@@ -1,20 +1,20 @@
 ---
-title: HTTP 400 error responses to HTTP requests
+title: HTTP 400 Error Responses to HTTP Requests
 description: Works around an HTTP 400 error that the HTTP request header is too long.
-ms.date: 01/10/2025
+ms.date: 03/24/2025
 ms.custom: sap:WWW Authentication and Authorization\Windows Authentication
 ms.reviewer: ivanpash, paulboc
 ---
 # HTTP 400 Bad Request (Request Header too long) responses to HTTP requests
 
-When an HTTP request that needs Kerberos authentication is sent to a website that's hosted on Internet Information Services (IIS) and is configured to use Kerberos authentication, the HTTP request header would be very long. This article helps you work around the HTTP 400 error that occurs when the HTTP request header is too long.
+When an HTTP request that contains a Kerberos authentication ticket is sent to a website that's hosted on Internet Information Services (IIS) and is configured to use Windows Integrated Authentication, the HTTP request header can have a considerable length that exceeds the maximum size of such headers accepted by the IIS server by default. This article helps you work around the HTTP 400 error that occurs when the HTTP request header is too long.
 
 _Original product version:_   Windows Server 2016  
 _Original KB number:_   2020943
 
 ## Symptoms
 
-An HTTP request that needs Kerberos authentication is sent from a browser to a website that's hosted on IIS. The website is configured to use Kerberos authentication. However, instead of receiving the expected webpage, you receive an error message that resembles the following one:
+When attempting to access a web application hosted on IIS that requires Windows Integrated Authentication to grant users access to its resources, the client (browser) will submit an HTTP request that includes an authentication header (header name: `Authorization`) that uses either NTLM or Kerberos as authentication protocols. In the scenario where a Kerberos authentication token is sent from a browser to a website that's hosted on IIS, instead of receiving the expected webpage, you receive an error message that resembles the following one:
 
 > HTTP 400 - Bad Request (Request header too long)
 
@@ -24,28 +24,30 @@ This response could be generated by any HTTP request that includes Windows Remot
 
 This issue may occur if the user is a member of many Active Directory user groups.
 
-The HTTP request to the server contains the Kerberos token in the `WWW-Authenticate` header. The header size increases together with the number of user groups. If the HTTP header or packet size increases past the limits that are configured on the server, the server may reject the request and send an error message as the response.
+The HTTP request to the server contains the Kerberos token in the `Authorize` header. The size of the Kerberos token contained within the HTTP header increases together with the number of user groups for the authenticating user. If the HTTP header or packet size increases past the limits that are configured on the server, the server may reject the request and send an error message as the response.
 
 ## Workaround 1: Decrease the number of Active Directory groups
 
 Decrease the number of Active Directory groups that the user is a member of.
 
 ## Workaround 2: Set MaxFieldLength and MaxRequestBytes registry entries
 
-Increase the settings for the `MaxFieldLength` and the `MaxRequestBytes` registry entries on the server so that the user's request headers don't exceed these values. To determine the appropriate settings, use the following calculations:
+Increase the settings for the `MaxFieldLength` and the `MaxRequestBytes` registry entries on the IIS server so that the user's request headers don't exceed these values. To determine the appropriate settings, use the following calculations:
 
 1. Calculate the size of the user's Kerberos token by using the formula described in [Problems with Kerberos authentication when a user belongs to many groups](../../../../windows-server/windows-security/kerberos-authentication-problems-if-user-belongs-to-groups.md).
 
 2. Set the value of `MaxFieldLength` and `MaxRequestBytes` on the server to 4/3 * T bytes, where T is the user's token size in bytes. HTTP encodes the Kerberos token by using base64 encoding.
 
    > [!NOTE]
-   > This replaces every three bytes in the token with four base64-encoded bytes. Changes that are made to the registry do not take effect until you restart the HTTP service. Additionally, you may have to restart any related services, such as IIS services.
+   > This replaces every three bytes in the token with four base64-encoded bytes. Changes that are made to the registry don't take effect until you restart the HTTP service. Additionally, you'll need to restart any related services, such as IIS services.
 
 Depending on your application environment, you might also work around this problem by configuring the website to use Windows NT LAN Manager (NTLM) instead of Kerberos. Some application environments require Kerberos authentication to be used for delegation. We consider Kerberos authentication to be more secure than NTLM. And we recommend that you don't disable Kerberos authentication before you consider the security and delegation ramifications.
 
 ## More information
 
-By default, there is no `MaxFieldLength` registry entry. This 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 aren't set to a sufficiently high value.
+By default, there's no `MaxFieldLength` registry entry. This 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 aren't set to a sufficiently high value.
+
+The size of `MaxFieldLength` and `MaxRequestBytes` shouldn't exceed the maximum allowed values for these fields that are defined in [Http.sys registry settings for Windows](../health-diagnostic-performance/httpsys-registry-windows.md). 
 
 For IIS versions shipped with Windows Server 2016 and later, the `MaxFieldLength` and `MaxRequestBytes` registry keys are located in the following subkey: