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
Test manifest
---
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
Rancher Server Setup
Information about the Cluster
User Information
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
ClusterIPorLoadBalancerservice 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
NodePortservice (i.e. directory connecting to the workload)To Reproduce
windows/terraform/azure_rke2_cluster/examples/gmsa.tfvarsexample to automatically Install the Rancher gMSA CCG Plugin feature onto the downstream clusternamespace,spec.template.securityContext.windowsOptions.gmsaCredentialSpecNameare properly configuredTest manifest
Result
Accessing the
LoadBalancerservice results in the UI appearing, and a login prompt appearing, but will never properly authenticate with ADExpected Result
Proper login when using the proper username and password
Additional context
This issue does not appear when using a
NodePortservice, 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