Rancher Server Setup

• Rancher version: tested on 2.7
• Installation option (Docker install/Helm Chart):
  • If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): Any
• Proxy/Cert Details:

Information about the Cluster

• Kubernetes version: RKE2, initially tested on 1.25.12
• Cluster Type (Local/Downstream): Downstream
  • If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider):

User Information

• What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)
  • If custom, define the set of permissions: n/a

Describe the bug
While creating test workloads for the Rancher gMSA CCG Plugin experimental feature based off of existing Microsoft documentation for the AKS CCG solution, I found that IIS integrated windows authentication did not work with service types other than NodePort.

IIS (Internet Information Services) is a Windows application that is used as a base layer for web services running on Windows servers. It offers integrated authentication with Active Directory allowing users to use a single set of credentials to login to any IIS application connected to an Active Directory Domain.

It was found during testing that logging into an IIS application exposed by a ClusterIP or LoadBalancer service type would result in the integrated authentication login process failing to communicate with the Active Directory domain controller. This is likely due to NTLM headers being stripped from the request. This issue resulted in the login process exiting before the user provided any credentials.

This issue does not reproduce when using a NodePort service (i.e. directory connecting to the workload)

To Reproduce

• Create an RKE2 windows cluster
• Create an Active Directory environment (using automation found within the Windows repo
  • using the windows/terraform/azure_rke2_cluster/examples/gmsa.tfvars example to automatically Install the Rancher gMSA CCG Plugin feature onto the downstream cluster
• create an IIS workload by applying the following manifest. Ensure that properties such as the namespace, spec.template.securityContext.windowsOptions.gmsaCredentialSpecName are properly configured

---
kind: ConfigMap
apiVersion: v1
metadata:
  labels:
   app: gmsa-demo
  name: gmsa-demo
  namespace: default
data:
  run.ps1: |
   $ErrorActionPreference = "Stop"

   Write-Output "Configuring IIS with authentication."

   # Add required Windows features, since they are not installed by default.
   Install-WindowsFeature "Web-Windows-Auth", "Web-Asp-Net45"

   # Create simple ASP.NET page.
   New-Item -Force -ItemType Directory -Path 'C:\inetpub\wwwroot\app'
   Set-Content -Path 'C:\inetpub\wwwroot\app\default.aspx' -Value 'Authenticated as <B><%=User.Identity.Name%></B>, Type of Authentication: <B><%=User.Identity.AuthenticationType%></B>'

   # Configure IIS with authentication.
   Import-Module IISAdministration
   Start-IISCommitDelay
   (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/windowsAuthentication').Attributes['enabled'].value = $true
   (Get-IISConfigSection -SectionPath 'system.webServer/security/authentication/anonymousAuthentication').Attributes['enabled'].value = $false
   (Get-IISServerManager).Sites[0].Applications[0].VirtualDirectories[0].PhysicalPath = 'C:\inetpub\wwwroot\app'
   Stop-IISCommitDelay

   Write-Output "IIS with authentication is ready."

   C:\ServiceMonitor.exe w3svc
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: gmsa-demo
  name: gmsa-demo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gmsa-demo
  template:
    metadata:
      labels:
        app: gmsa-demo
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: aks-gmsa-spec
      containers:
      - name: iis
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: IfNotPresent
        command:
         - powershell
        args:
          - -File
          - /gmsa-demo/run.ps1
        volumeMounts:
          - name: gmsa-demo
            mountPath: /gmsa-demo
      volumes:
      - configMap:
          defaultMode: 420
          name: gmsa-demo
        name: gmsa-demo
      nodeSelector:
        kubernetes.io/os: windows
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: gmsa-demo
  name: gmsa-demo
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: gmsa-demo
  type: LoadBalancer

Result
Accessing the LoadBalancer service results in the UI appearing, and a login prompt appearing, but will never properly authenticate with AD

Expected Result
Proper login when using the proper username and password

Additional context
This issue does not appear when using a NodePort service, so it seems some properties of the login request are being stripped when routed through Rancher.

There may be workarounds or configurations which allow this process to work as expected, and if so the product of this issue should be documentation