You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
I am using a non-Windows machine with Kerberos protection, where the Service Principal Name (SPN) is case-sensitive. The SPN in my case is HTTP/myserver. However, Kerberos.NET's SspiSecurityContext.InitializeSecurityContext method converts the SPN to lowercase (http/myserver), causing authentication to fail because the server cannot verify the token with the altered SPN.
This behavior breaks compatibility with non-Windows Kerberos implementations, as many UNIX-based systems enforce case sensitivity for SPNs.
Steps to Reproduce:
Set up a Kerberos-protected non-Windows machine with an SPN HTTP/myserver.
Use Kerberos.NET SSPI to authenticate using the SPN HTTP/myserver.
Observe that the SPN is converted to http/myserver, resulting in authentication failure on the server.
Expected Behavior:
The SPN string provided to the SspiSecurityContext.InitializeSecurityContext method should remain in its original case to ensure compatibility with case-sensitive non-Windows servers.
Actual Behavior:
The SPN string is converted to lowercase (http/myserver), leading to token verification failure on the non-Windows server.
SPNs are case-insensitive on Windows systems but case-sensitive on many non-Windows systems.
Refer to Microsoft documentation for more information:
"Service Principal Names (SPNs) are not case sensitive when used by Microsoft Windows-based computers. However, many UNIX-based systems are case-sensitive and require the proper case to function properly."
A potential fix would be to avoid altering the case of the SPN string in SspiSecurityContext .InitializeSecurityContext.
The text was updated successfully, but these errors were encountered:
Description:
I am using a non-Windows machine with Kerberos protection, where the Service Principal Name (SPN) is case-sensitive. The SPN in my case is HTTP/myserver. However, Kerberos.NET's
SspiSecurityContext.InitializeSecurityContext
method converts the SPN to lowercase (http/myserver), causing authentication to fail because the server cannot verify the token with the altered SPN.This behavior breaks compatibility with non-Windows Kerberos implementations, as many UNIX-based systems enforce case sensitivity for SPNs.
Steps to Reproduce:
Set up a Kerberos-protected non-Windows machine with an SPN HTTP/myserver.
Use Kerberos.NET SSPI to authenticate using the SPN HTTP/myserver.
Observe that the SPN is converted to http/myserver, resulting in authentication failure on the server.
Expected Behavior:
The SPN string provided to the
SspiSecurityContext.InitializeSecurityContext
method should remain in its original case to ensure compatibility with case-sensitive non-Windows servers.Actual Behavior:
The SPN string is converted to lowercase (http/myserver), leading to token verification failure on the non-Windows server.
Environment:
Kerberos.NET version: [e.g., 4.6.70]
.NET version: [e.g., .NET 8.0]
Operating System: [e.g., Windows 10, Ubuntu 20.04]
Additional Information:
SPNs are case-insensitive on Windows systems but case-sensitive on many non-Windows systems.
Refer to Microsoft documentation for more information:
"Service Principal Names (SPNs) are not case sensitive when used by Microsoft Windows-based computers. However, many UNIX-based systems are case-sensitive and require the proper case to function properly."
A potential fix would be to avoid altering the case of the SPN string in
SspiSecurityContext .InitializeSecurityContext
.The text was updated successfully, but these errors were encountered: