NTLM issues in .NET 10 Ubuntu noble Docker image

[elkoiko]

Describe the bug

Using 10.0.1-noble and manually installing gss-ntlmssp library does not seem to allow NTLM authentication when using the EWS Exchange Web Service in a .NET 10 Web API project.

The same code works properly in Debian based Docker image with .NET 8 (aspnet:8.0.20-bookworm-slim).

In aspnet:10.0.1-noble image, I would receive a 401 error message even though I'm using the right credentials:

Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. The remote server returned an error: (401) Unauthorized.
        ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
          at System.Net.HttpWebRequest.GetResponse()            
          at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.GetResponse()           
          at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)                
          --- End of inner exception stack trace ---      
          at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)        
          at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)           
          at Microsoft.Exchange.WebServices.Data.SimpleServiceRequestBase.InternalExecute()              
          at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()            
          at Microsoft.Exchange.WebServices.Data.ExchangeService.InternalCreateItems(IEnumerable`1 items, FolderId parentFolderId, Nullable`1 messageDisposition, Nullable`1 sendInvitationsMode, ServiceErrorHandling errorHandling)        
          at Microsoft.Exchange.WebServices.Data.ExchangeService.CreateItem(Item item, FolderId parentFolderId, Nullable`1 messageDisposition, Nullable`1 sendInvitationsMode)       
          at Microsoft.Exchange.WebServices.Data.Item.InternalCreate(FolderId parentFolderId, Nullable`1 messageDisposition, Nullable`1 sendInvitationsMode)       
          at Microsoft.Exchange.WebServices.Data.EmailMessage.InternalSend(FolderId parentFolderId, MessageDisposition messageDisposition)
                                          at Microsoft.Exchange.WebServices.Data.EmailMessage.SendAndSaveCopy()

By experience, I know that receiving a 401 error in this context is because there is an issue with gss-ntlm. I had the same error message when I did not install the right dependencies in the .NET 8 Debian image previously. But this fix is not enough for .NET 10 Ubuntu images.

Even after following this issue #5303 mentioning the workaround that consists of configuring OpenSSL to enable legacy usage it does not work.

Which .NET image(s) are you using?

mcr.microsoft.com/dotnet/sdk:10.0.101-noble

Steps to reproduce

Dockerfile that does not work: (.NET 10 Ubuntu)

FROM mcr.microsoft.com/dotnet/aspnet:10.0.1-noble AS base

# Install curl with NTLM/GSSAPI support and related libs (EWS related)
USER root
RUN apt-get update
RUN apt-get install -y curl
RUN apt-get install -y ca-certificates
RUN apt-get install -y gss-ntlmssp
RUN apt-get install -y krb5-user
RUN apt-get install -y libkrb5-3

# Install NTLM/GSSAPI support for Ubuntu Noble
RUN apt-get install libgssapi-krb5-2

###
### OpenSSL 3.0 fix by providing an override openssl.cnf file:
### This fixes the GSS / NTLM issues when using Exchange Web Services (EWS)
###
RUN echo "Copying openssl.cnf to /etc/ssl/openssl.cnf"
COPY ["MailMCPServer.WebServer/openssl.cnf", "openssl.cnf"]
RUN cp openssl.cnf /etc/ssl/openssl.cnf

RUN rm -rf /var/lib/apt/lists/* # clear apt lists to save space

USER $APP_UID
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:10.0.101-noble AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["nuget.config", "."]
COPY ["MailMCPServer.WebServer/MailMCPServer.WebServer.csproj", "MailMCPServer.WebServer/"]
RUN dotnet restore "./MailMCPServer.WebServer/MailMCPServer.WebServer.csproj"
COPY . .
WORKDIR "/src/MailMCPServer.WebServer"
RUN dotnet build "./MailMCPServer.WebServer.csproj" -c $BUILD_CONFIGURATION -o /app/build

# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
ARG BUILD_CONFIGURATION=Release
ARG APP_VERSION=1.0.0
RUN dotnet publish "./MailMCPServer.WebServer.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false -p:Version=$APP_VERSION

# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MailMCPServer.WebServer.dll"]

Content of openssl.cnf:

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

Note: if you replace the image tags in the previous non working Dockerfile by aspnet:8.0.20-bookworm-slim and sdk:8.0.414-bookworm-slim then sending emails will work without any issue.

Other information

Resources:

• NTLM issues in some images #5303
• GSS failures in System.Net.Http.Functional.Tests on Ubuntu 22.04 runtime#67353

Output of docker version

Client:
 Version:           28.5.1
 API version:       1.51
 Go version:        go1.24.8
 Git commit:        e180ab8
 Built:             Wed Oct  8 12:19:16 2025
 OS/Arch:           windows/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.50.0 (209931)
 Engine:
  Version:          28.5.1
  API version:      1.51 (minimum version 1.24)
  Go version:       go1.24.8
  Git commit:       f8215cc
  Built:            Wed Oct  8 12:17:24 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info

Client:
 Version:    28.5.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.9.11
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.29.1-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.40.3-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.45
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.2.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.26.0
    Path:     C:\Users\tcouacau\.docker\cli-plugins\docker-mcp.exe
  model: Docker Model Runner (Docker Inc.)
    Version:  v0.1.46
    Path:     C:\Program Files\Docker\cli-plugins\docker-model.exe
  offload: Docker Offload (Docker Inc.)
    Version:  v0.5.10
    Path:     C:\Program Files\Docker\cli-plugins\docker-offload.exe
  sandbox: Docker Sandbox (Docker Inc.)
    Version:  v0.5.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sandbox.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.18.3
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 27
 Server Version: 28.5.1
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.87.2-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 6
 Total Memory: 15.62GiB
 Name: docker-desktop
 ID: 55cc0ad0-da65-408a-832c-101586a1374c
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

[lbussell]

Thanks for filing this issue. The discussion in #5303 makes it sound like this should be fixed in noble. @elkoiko I'm curious, does the same issue happen using the aspnet:8.0-noble image?

Can someone from @dotnet/ncl take a look? /cc @wfurt.
Maybe related: dotnet/runtime#111639

[wfurt]

Noble seems to still be on old package and I think it would still crash e.g. we do not have it in CI. This looks different as it simply fails to authenticate. Did you try to use the managed version instead @elkoiko ? dotnet/dotnet-api-docs#12091 That one does not depend on gss-ntlmssp and it is something we can directly control.