Doesn't work with OpenSSL 3 on Alpine 3.18 #97
Comments
|
Can you please provide actual logs with the build you made? |
|
FWIW, we build gssntlmssp in Fedora against OpenSSL 3.0 with no problems, and .NET is also using that afaik, so I need info specific to your build. |
|
There are no logs from the app side, it is just an error: We are upgrading from .NET6 to .NET8, faced that issue in our Alpine image. The way we are doing it is building gss-ntlmssp library separately and putting the library with the config into our image. With Alpine 3.17 it worked but stopped with Alpine 3.18. Here is how I put the library file and a config into our image. Library is picked from the stage in Dockerfile which I described earlier: Here is a config file content: Here is a full log from docker build command:
#0 building with "default" instance using docker driver
#1 [internal] load .dockerignore #2 [internal] load build definition from Dockerfile #3 [internal] load metadata for mcr.microsoft.com/dotnet/sdk:8.0-alpine3.18 #4 [1/9] FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine3.18@sha256:3f93439f47fea888d94e6e228d0d0de841f4122ef46f8bfd04f8bd78cbce7ddb #5 [2/9] RUN apk add --no-cache git curl #6 [3/9] RUN apk add --no-cache make m4 autoconf automake gcc g++ krb5-dev openssl-dev gettext-dev #7 [4/9] RUN apk add --no-cache libtool libxml2 libxslt libunistring-dev zlib-dev samba-dev #8 [5/9] RUN git clone https://github.com/gssapi/gss-ntlmssp #9 [6/9] WORKDIR gss-ntlmssp #10 [7/9] RUN autoreconf -f -i #11 [8/9] RUN ./configure --without-manpages --disable-nls #12 [9/9] RUN make install |
|
I've found the solution. For those who are facing the same, for me this helped. My application was silent, only 401 error was thrown, but when I tried Invoke-RestMethod cmdlet inside pwsh that is preinstalled in .NET 8 Docker SDK image, I received this error: After I installed P.S. @simo5 thank you for quick response! |
|
Hi @simo5 I'm reopening it again since I faced the problem that authentication is fixed, but it stops working after some number of requests to the server. With a help of strace utility I managed to trace the chain a bit. I checked with Powershell as well, the same behavior:
Here is a Dockerfile for building gss-ntlmssp library for Alpine 3.18: Here are build logs of gss-ntlmssp library for Alpine 3.18:
docker build -t ntlm --progress plain --no-cache .
#0 building with "default" instance using docker driver
#1 [internal] load build definition from Dockerfile #2 [internal] load metadata for docker.io/library/alpine:3.18 #3 [internal] load .dockerignore #4 [1/9] FROM docker.io/library/alpine:3.18@sha256:11e21d7b981a59554b3f822c49f6e9f57b6068bb74f49c4cd5cc4c663c7e5160 #5 [2/9] RUN apk add --no-cache git curl #6 [3/9] RUN apk add --no-cache make m4 autoconf automake gcc g++ krb5-dev openssl-dev gettext-dev #7 [4/9] RUN apk add --no-cache libtool libxml2 libxslt libunistring-dev zlib-dev samba-dev pkgconf #8 [5/9] RUN git clone https://github.com/gssapi/gss-ntlmssp #9 [6/9] WORKDIR gss-ntlmssp #10 [7/9] RUN autoreconf -f -i #11 [8/9] RUN ./configure --without-manpages --disable-nls #12 [9/9] RUN make install #13 exporting to image Can you please help me with that? |
|
Build logs are completely useless to debug a runtime issue. At the very least you would need to raise log levels and provide the HTTP server logs to see if there is any indication of what goes wrong. What is the peer? If this is server code where are credentials stored? Is this using winbindd integration or are you providing a password file? If this is client code, how are you providing credentials? |
This is a client that is on .NET8 trying to reach Windows Server 2016.
I did it, there are no logs in IIS WebServer on the destination, there are logs only appearing that the authentication failed with no reason for the user who is using NTLM authentication, so auth process is not reaching the application I guess. Interesting fact, that successful authentication is indicated by one user (LiveUser) and failed by another (Administrator): Failed log event by Administrator:
The test Powershell script I provided you, is just using default cmdlet to store credentials, then NTLM\Windows authentication used, I guess.
The destination server is standalone one, not binded to the domain. P.S. I don't know if it will help, but auth requests are failing after 58 consecutive requests. |
|
0xC0000064 User logon with misspelled or bad user account Perhaps you should use Administrator instead of Administrateur ? |
|
I beg a pardon, failed auth log isn't related to this. This one was about someone trying to login using wrong username, indeed. What is stranger, I noticed that there are no failed login attempts recorded on the destination server made by the application. |
|
Hi @simo5 Here is what debug logs looks like. 55 and 56 requests are ok, starting from 57 is stops working and throws 401. Another thing is that when I restart PowerShell session or restart an application then it starts working again until 57th request. Looks like some pool of connections becoming full or something...: |
|
Hi @simo5 Steps to get it running on Alpine 3.18:
|
|
This is already fixed in 1.1.0 with automatic loading of the legacy provider, I am not aware of any issues automatically loading the legacy provider. |
|
As you can see, for us the old method of loading legacy provider works, but the new one is not, so something definitely doesn't work correctly. Thanks for your replies so far. |
|
If you can run the code in a debugger and find out what breaks loading the legacy provider I can then make a fix for it. But I do not have a system setup to build or run .NET stuff so until I have a way to reproduce the issue outside of your particular environment I am of little utility. |
|
Hi @simo5, we are facing the exact same issue - auth fails after 58 tries when the legacy provider is loaded via the library. If I also load the legacy provider in advance by updating the openssl config file, it fails after 57 tries, which might suggest it's loaded for every run and hits some kind of limit?
If you run the container following the provided instructions, it prompts you for a URL, a username and a password and tries to call the URL 100 times and breaks the loop and exits with an error in case it fails. |
|
Hi @laszlojau, thanks for your message. |
|
@laszlojau @yevheniilavrenchuk can one of you tell me if #99 make this work on alpine without explicitly loading the legacy provider via config file? I am confused by the "57" times thing, I am not aware of any limit to the number of times you load/unload a provider on a brand new context. In any case the PR should load the legacy only once on a long lived context, and should address whatever underlying OprenSSL problem may have caused it. |
|
Thank you @simo5, I tried it and it seems to work perfectly. Ran it 500 times and it worked every time. No errors in the debug logs either. |
|
Thanks for confirming, merged the fix, release soon. |
|
Thank you so much, @simo5. It is working for us as well, confirmed! |
Hi. I faced the problem that if I'll build the package for Alpine 3.18, it won't work. Here is a Dockerfile I'm using for that:
The build is working, but when I'm using gssntlmssp.so library, I'm receiving 403 errors during authentication requests. Previously and on our older images it was working perfectly fine with the same authentication endpoint.
I've got to know that when OpenSSL 3 became default package in Alpine 3.18, then it stopped working. Reference:
https://stackoverflow.com/questions/76185769/gssapi-operation-failed-with-error-an-unsupported-mechanism-was-requested-for
https://bugs.launchpad.net/ubuntu/+source/gss-ntlmssp/+bug/1995915
Maybe someone has a solution for that?
Thanks in advance!
The text was updated successfully, but these errors were encountered: