aws-lambda-dotnet
aws-lambda-dotnet copied to clipboard
Support NTLM Auth Inside Lambda Functions
Describe the feature
This request is the same as #735 which was closed due to staleness.
Add in the missing required libraries to make NTLM auth work in a .net core lambda.
Use Case
We are struggling to consume older soap-based services that rely on NTLM authentication. The workaround to create a custom image with the necessary dependencies and deploy that to our lambda increases build time and requires increased maintenance.
Proposed Solution
Install the gssntlmssp (sometimes called gss-ntlmssp) in the lambda runtime so it is available for use
Other Information
No response
Acknowledgements
- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
AWS .NET SDK and/or Package version used
Not relevant
Targeted .NET Platform
.Net 6 and above
Operating System and version
AmazonLinux
Needs review with the team.
Is there any update on this issue?
@ashishdhingra Is there any update on this issue
@ewindsor31 do you have an example of the workaround you mentioned in Use Case section? Is it just about installing gssntlmssp or is there anything else that needs to be done?
I tried installing gssntlmssp in docker lambda - got "No package gssntlmssp available" error.
FROM public.ecr.aws/lambda/dotnet:7
RUN yum install -y epel-release gssntlmssp
...
#6 0.858 Loaded plugins: ovl
#6 8.541 No package epel-release available.
#6 8.722 No package gssntlmssp available.
#6 8.769 Error: Nothing to do
you have to install epel-release from its source, the starting image doesn't have the package yet. Here is the dockerfile that I use as my runtime image.
FROM public.ecr.aws/lambda/dotnet:6
RUN yum makecache
RUN yum -y install http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
RUN yum -y install gssntlmssp
And here is the dockerfile for my lambdas. The RUNTIME_IMAGE argument is the image created by my comment above. You could combine these together, but I wanted to shorten my build pipeline and the url for epel-release would occasionally fail to download and cause the whole pipeline to fail.
ARG RUNTIME_IMAGE
FROM mcr.microsoft.com/dotnet/sdk:6.0 as build-image
ARG FUNCTION_DIR="/build"
ARG SAM_BUILD_MODE="run"
ENV PATH="/root/.dotnet/tools:${PATH}"
RUN apt-get update && apt-get -y install zip
RUN mkdir $FUNCTION_DIR
WORKDIR $FUNCTION_DIR
COPY <your projects contents> $FUNCTION_DIR/
RUN dotnet tool install -g Amazon.Lambda.Tools
# Build and Copy artifacts depending on build mode.
RUN mkdir -p build_artifacts
RUN dotnet lambda package --configuration Release;
RUN cp -r /build/bin/Release/net6.0/publish/* /build/build_artifacts;
FROM ${RUNTIME_IMAGE}
COPY --from=build-image /build/build_artifacts/ /var/task/
# Command can be overwritten by providing a different command in the template directly.
CMD [ Your function handler ]
Thank you, sir. This is super helpful.
@ewindsor31 did you happen to upgrade to .NET 8?
I tried, and you can no longer install gssntlmssp in public.ecr.aws/lambda/dotnet:8 as it's now based on Amazon Linux 2023^1 which no longer support EPEL^2.
Any ideas on how to make NTLM work in .NET 8 Lambda?
I have not upgraded to .NET 8 yet. I've tried experimenting in the last few days to see if I could get it to work, but so far I have not been successful. Let me know if you come up with a solution. I'll do the same.
I wasn't able to make it work. In my case, lambda downloads a single pdf report from AWS RDS SQL Server SSRS which supports only NTLM or Kerberos.
I entertained the idea of calling curl to do that, but curl that comes with Amazon Linux 2023 doesn't seem to support NTLM either (curl --version).
Another option was to configure Kerberos, but luckily, I was able to convince the stakeholders that SSRS report is not needed, so we just removed it completely.
@normj Do you know if this issue will get any attention? I understand if the NTLM support won't get pulled into the base image directly, but if you have any advice on how to get NTLM authentication to a wcf service working in a dotnet8 lambda it would be appreciated. Some form of alternative to the approach previously used with the gssntlmssp package that is no longer supported in the lambda runtime.
@ewindsor31 Do you mean besides deploying a function as a container image?
The Lambda team is very conservative about what native dependencies to install in the managed runtime for security and maintenance reasons. So I don't see the Lambda team adding gssntlmssp as a preinstalled library for managed runtime. Keep in mind I'm not on the Lambda runtimes team, just expressing what I hear when talking to them.
Is the ask for me to help figure out how to get a container based function with gssntlmssp installed?
We had the container image figured out for the dotnet 6 runtime but when they switched to the Amazon Linux 2023 image with dotnet 8 the approach doesn’t work anymore because it was dependent on the gssnmtlpssp package. Amazon Linux 2023 doesn’t support that package anymore apparently.
I understand if figuring this out isn’t your reponsibility, but it would be really helpful to figure out how to make this work in Amazon Linux 2023 with dotnet 8. I know NLTM is outdated but we can’t be the only people still having to support older systems that use it so I imagine it will be an issue for many people as they try to stay current.
I'm happy to try and find some time to help solve the container issues. I just wanted to level set that I have limited influence on what is installed in the managed runtime outside of the .NET bits.
That’s fair. I appreciate any help you can give