Bug 1913834

I have been thinking about this a little bit, but I am stuck at this point: Can you help me understand what the exact request is, here?

The package gssntlmssp already exists in RHEL 8. Users can install and use it themselves.

So that's not what the bug is about, is it? Is it that users can't find the package? Or is it that installing this package in a container context is too difficult? Is it that even installing the package doesn't fix the underlying NTLM authentication issue?

I did some testing and the package is not a part of the UBI 8 repositories or the .NET 5.0 container images. Is that the trouble the users seem to be having?

Without more details on what the expected outcome is, I am afraid there's nothing to fix here: the package gssntlmssp is already available (though not an explicit dependency of .NET Core).

I am closing this bug but please feel free to re-open if there are any issues that still need fixing.

Hello RedHat,

Can this bug be re-opened as I have this issue as identified by Omair:

I did some testing and the package is not a part of the UBI 8 repositories or the .NET 5.0 container images. Is that the trouble the users seem to be having?

So using the UBI8 container image and installing .Net Core and PowerShell 7, GSSNTLMSSP is a pre-requisite and included in the Microsoft public PowerShell 7 containers but not possible to install in the UBI8 container unless the containers host is RHEL8 and subscribed to RHN as GSSNTLMSSP is not in 1 of the 3 open UBI repositories:


ubi-8-appstream                                                                           Red Hat Universal Base Image 8 (RPMs) - AppStream
ubi-8-baseos                                                                              Red Hat Universal Base Image 8 (RPMs) - BaseOS
ubi-8-codeready-builder                                                                   Red Hat Universal Base Image 8 (RPMs) - CodeReady Builder

Or can you provide details to install GSSNTLMSSP when the container host is not a RHEL system when using the UBI8 base image.

Regards,
JW

> So using the UBI8 container image and installing .Net Core and PowerShell 7, GSSNTLMSSP is a pre-requisite and included in the Microsoft public PowerShell 7 containers

Can you tell me how to test this out? I would like to verify this on my end.



I see a couple of options here:

- We add gssntlmssp to the default .NET containers to make this scenario (powershell, but also active directory) work out of the box.

  If we are adding/shipping this, we need to find a way to test it. I don't have one. Does anyone know how to test that this package fixes the dependency and/or makes Active Directory work with .NET?

- We don't add gssntlmssp to our containers, but ask RHEL to add it to the UBI 8 repositories so users can install it on their own.

  This lets users install it, but it's not available in a .NET container by default. Is this a good compromise?

- We can declare that gssntlmssp package requires a Red Hat subscription and this feature wont work without it.

  Not ideal, but it's basically where we are right now.

Hello Omair,

Many thanks for the quick pick up.  I can't answer all your questions but after further research I'll give you a PowerShell / PowerCLI developers view (which is what I am).

Background:  My requirement is mainly PowerCLI scripting against VMware Cloud Director stack for automation, however as the PowerShell expert, I also contribute PowerShell best practice and PowerShell windows scripting such as DNS and AD automation.  Ever since PowerShell was made cross-platform I have experimented with PowerCLI on Linux and for the past approx 18 months, we have been running the Microsoft published PowerShell containers based on Alpine.  As stated PowerCLI is my main requirement and the easiest container with flexibility to update the most important component (PowerCLI) has been to take the MS PowerShell Alpine container and add PowerCLI via Install-Module within the container.  This has worked well and at the time of implementing this we were a mixed CentOS / Ubuntu and others Linux setup.  Creating and publishing the container on OpenShift was manual but has worked very well.

Transition:  We are now moving towards a RedHat centric setup and some of our containers are now based on the RedHat UBI images.  Therefore, as I need to update our current containers and have better internal tooling, I hoped and expected to be able to use the Microsoft PowerShell docker file on top of the RedHat UBI8 base image to create a RHEL centric equivalent container.

Development:  I first tried this on my dev laptop which is RHEL 8.3 developer licensed and registered to RHN.  At the time , not understanding the intricacies of Subscription manager and containers this just worked.  I now know this is because the host OS has access to the full RedHat repositories and hence gssntlmssp installed from the rhel8-app-stream repo.  However when trying to build the container within our Jenkins pipeline, the build failed missing gssntlmssp.  Although not relevant, I believe the Jenkins nodes are RHEL 7 and registered to a RedHat satellite server and not RHN.  

I could see that the container had access to the 3 core ubi8 repositories and this is with other testing was when I found that Microsoft include gssntlmssp in the PowerShell official containers but gssntlmssp is not one of the packages offered in the restricted but public ubi repositories.

Research:  Googling lead me to this bugzilla and hence my posting but I also researched gssntlmssp and the official .Net containers and the RedHat .Net UBI8 based container.  Could I download an RPM from the gss-ntlmssp GitHub project or even build it as part of the docker build etc?  Within the .Net GitHub repo who also publish Docker certified .Net containers, there are a couple of issues relating to and asking for ntlm to be included in the dependencies image for the .Net containers.  However the conclusion of the maintainers is that ntlm is not a dependency for .Net core (other authentication protocols could be used) and the containers should follow the dependencies for the published package.  This I agree with, a pure .Net application written for .Net core may well not require NTLM.  I am not so convinced on the stance that the container should follow package dependencies, as official containers should make using the application easier and just work where possible.  However I am not a .Net core maintainer and understand there thinking.  However another reason for not making gss-ntlmssp a requirement was the lack of a publicly package for all platforms.  Particularly an RPM which does seem to be scarce.

So to get to your 3 points:
3:  I agree this is where we are at.  And although not ideal I now know that if I use a RHEL registered host then I could build the container using the Microsoft tweaked Dockerfile.  I'm not sure where any doco would be published that I would have found to understand this limitation.  Amongst the various docs on UBI base images / repo lists the information to deduce this is there.  I doubt this is a special case of missing packages of the UBI repos but RedHat has decided not to make this package available and to some degree we have to accept that.

1:  Yes this would give me a UBI base container I could install PowerShell 7 then PowerCLI into it but given what I now know about the upstream .Net core containers, I don't feel I can push for this as it would deviate RedHat's implementation for .Net core from the main projects interpretation.  I also don't know how you would test as I now believe for my requirement, I probably don't need NTLM.  And if I did I could just use a Windows host for the Windows specific scripts.  A compromise but one I need to think about.

One possible solution along the lines of improving the containers as per 1., would be for RedHat to provide a PowerShell UBI container into which as per the Microsoft published containers gssntlmssp would be included.  Again when does RedHat stop with providing UBI application specific containers so this is one for internal discussions.  I do feel PowerShell in a container is a really powerful tool and we use it in several different automation and development scenarios using VSCode including automation on top of OpenShift.  As long as the container was kept current to the stable version of PowerShell I would certainly use a RedHat provided PowerShell container instead of building our own.

2:  This is the solution for me.  I don't understand what could be in the RedHat build of gssntlmssp that would be RedHat proprietary and therefore on what criteria a packages is include / excluded from the publicly available UBI repos. If it was in the ubi-8-appstream repo then tweaking / using the MS dockerfile would have just worked and I would have achieved a PowerShell container inline with the Microsoft container but based on RHEL.

I now believe that the gssntlmssp requirement is significantly greater for PowerShell (Invoke-WebRequest is more likely to need it for example) than it is for a pure .Net C# application. Whilst (without going into detail publicly) I can't fully automate using either the MS Alpine PowerShell container or a UBI8 based container, I have decided to continue to use the certified MS container and manually upload it to our Docker registry as a base image into which I can automate the install of PowerCLI. A smaller step than planned but still a step forward to full automation.  Project deadlines mean I don't have a great deal of time to investigate my reliance on gssntlmssp, what works in PowerShell / PowerCLI and what doesn't.  I hope I am wrong but I also don't see gssntlmssp being published in the UBI repos in days or even weeks.
I will revisit this and if either we have fully moved onto RHEL8 or gssntlmssp has been published in the UBI repos then I will migrate this automation to be RedHat based.

Thank you for reading, I hope I have helped consolidate the problem and I believe gssntlmssp missing from the UBI repos is the issue even though you didn't get any feedback from Rick.

Regards,
JW

.NET Core 2.1 has been End-of-Life'd.

The .NET program EOL'ed .NET Core on August 21, 2021:
https://access.redhat.com/support/policy/updates/net-core

The .NET Core 2.1 "AppStream" was also EOL'ed in RHEL 8:
https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle

As such, we have delivered the last set of planned fixes via z-stream in RHEL 8.4. There are no additional fixes/enhancements/builds planned for RHEL 8.5.

Since this bug isn't really about .NET Core 2.1 itself, I am re-targeting it to .NET Core 3.1.

It's been a few years, and as you can guess from the lack of movement on this bug, we haven't been able to resolve this.

gssntlmssp's package dependency tree is fairly extensive. Some of those dependencies are a part of the UBI package set already. Some dependencies are never going to be a part of the UBI package set, for various business reasons and goals of the UBI program. Because of that, unfortunately, we can't move gssntlmssp to the UBI package repositories any time soon.

We are stuck with a situation where the gssntlmssp package requires a Red Hat subscription and wont work without it.

Sorry for the bad news, folks.