Hacker News Reader

Comment by filleokus | Hacker News Reader

> App2Container (A2C) currently supports the following application types:

> 1) ASP.NET (.NET 3.5+) web applications running in IIS 7.5+ on Windows. A2C packages these applications with Windows containers.

Do people actually run Windows containers successfully?

Right now I'm working with get ASP.NET apps into containers, by first getting them ported to ASP.NET Core and then into Linux containers. The decision to skip Windows all-together was made before I joined, but I'm a nix guy so I don't complain.

One of the hiccups I've encountered on Linux is the lack of support for Windows Authentication. It gives you AD backed SSO basically for free (as a developer) - you just need one line of config to turn it on and the magic of IIS solves it for you.

We moved to ADFS instead, which worked well. But I'm guessing there are many of these deeply integrated services that make Windows containers attractive.

View on HN

> Do people actually run Windows containers successfully?

Yes, it's been done. Cloud Foundry has done it for a while and Kubernetes can do it as well.

It's not easy. Earlier versions of Windows didn't expose APIs suitable for partitioning resources and information in the sense that we think of as containers, so a great deal of hackery was needed to sorta-kinda-but-not-really recreate the experience. Later versions were better, but still lots of hackery was required. In my understanding it's only the latest versions of Windows that make it possible to "containerise" on par with Linux.

Part of the difficulty has been that there's a very long lag between "we need Windows to do X", to "Windows version 4000 now achieves X", to discovering that actually it doesn't really do X, to "Windows 5000 now achieves Y", to "and customers have actually installed it and retired Windows 3000 and 4000". That loop can be more than a decade and it imposes enormous overheads onto anyone proposing to support Windows containerisation as a platform capability.

Meanwhile in Linux-land, stuff lands in the kernel much sooner and arrives in release-ready form much sooner. What I've seen (anecdotally) is that there is a sudden step change in Microsoft platforms from .NET to .NET Core. Folks want containers, badly, and Core gets them there with much less fuss.

I thought Windows was starting a Linux VM with HyperV to run the container?

The thing here is "Windows containers" -- ie, OS virtualisation of the NT kernel. Most software that uses classic .NET, COM, win32 etc APIs need to run on Windows. Stuff that runs on Linux typically gets run on Linux.

Unless I'm mistaken, you should be able to get working Windows Authentcation if you have Kerberos libs installed, a valid krb5.conf and a keytab or service account credentials.

It was suprisingly easy to get working.

What Windows containers offers are Group Managed Service Accounts which reduces the administrative overhead managing service accounts for Linux containers and makes them completely transparent to the container.

Yeah, we investigated that route, but on stateless containers it seemed really cumbersome?

I don't remember exactly why now, but isn't there some problem with the ephemeral nature of the container? Like that each instance of the container needs their own service account or something?

> What Windows containers offers are Group Managed Service Accounts which reduces the administrative overhead managing service accounts for Linux containers and makes them completely transparent to the container.

Aah, yeah, that seems nice.

> Yeah, we investigated that route, but on stateless containers it seemed really cumbersome?

I agree, it could be cumbersome without something to manage the secrets. I use OpenShift / k8s at work so injecting these secrets is trivial.

I think it gets more complex if you need to do kerberos constrained delegation. It's been a while since I looked into it and threw my hands up, but essentially I think it's the ephemeral nature of containers that is the problem, as machines need to be registered in AD and have delegation rights assigned.

Windows authentication doesn’t use Kerberos.

Windows authentication uses NTLM, if it’s backed by a directory such as an AD it’s then can be used by the server to authenticate or authorize the user.

The Kerberos support in Active Directory is somewhat there due to legacy reasons when there were a lot of directory products on the market that spoke Kerberos and it’s was added to support applications that did not shoot NTLM.

For the most part most Microsoft products don’t use it, and those which do don’t expose it to the users (SSO, tho there is now SSO with Windows principles too).

To put it more simply if you login to the server directly using a username and password (For a Windows Principle) it’s never Kerberos, for Kerberos authentication you need to go to a Kerberos server and get a TGT then use that TGT to get a service ticket for a specific resource which again is done against the Kerberos server directly that service ticket is then presented to the resource you are trying to access.

Windows authentication absolutely uses Kerberos, NTLM is more used as a fallback. Kerberos is way more secure than ntlmv2 and is the favored authentication method.

I work in the enterprise space, and mostly for Microsoft shops - yet I've never seen a Windows container in the wild!

A friend of mine said NTLM should be possible on Linux. Maybe check out https://docs.microsoft.com/en-us/aspnet/core/security/authen...

I've never tried to use kebreros with containers though, so ymmv

SSO on *nix is a non-starter and is a big (only?) argument to use a Windows box for Windows services. It used to also be a big argument for writing applications in .NET instead of, say, Java, but that got resolved with https://github.com/Waffle/waffle

Don't you need windows server CALs for every user of your service as soon as you have a Windows box?

no you can license by CPU core

You're both right, there is an incredible amount of licensing options that are insanely complex.

That's more of a problem to use Windows authentication capabilities for external public users. Usually it's used internally for employees, for whom the company has appropriate licenses and computers and stuff.

Reply on news.ycombinator.com