1

My goal is to run a Windows Docker container that can authenticate via Kerberos to access Windows resources. To do this, I mirrored a setup that works great for Linux containers. I created a Docker image based on winamd64/python that installs the most recent Kerberos MSI for Windows. It runs kinit on a keytab for my user* and successfully generates a ticket in the cache file I specify. Snippet below:

RUN cmd /c "type nul > /path/to/krbcache"
RUN cmd /c "setx KRB5_CONFIG C:\path\to\krb5.conf"
RUN cmd /c "setx KRB5CCNAME C:\path\to\krbcache"

WORKDIR /path/to/
RUN cmd /c "kinit -k -t myuser_keytab myuser@REALM"

When I exec into this container, I see a ticket in the krbcache file, and everything seems great. But, when I run klist, I see the below error:

A specified logon session does not exist. It may already have been terminated.

Furthermore, when I exec into a running container and run kinit, that succeeds. But, if I open a second shell and exec into the same running container, klist reports a different LogonId and has no knowledge of the session.

Exec1@ContainerA>klist

Current LogonId is 0:0x21fdb825

Cached Tickets: (0)

Exec2@ContainerA>klist

Current LogonId is 0:0x2210bba0
...

A specified logon session does not exist. It may already have been terminated.

A few questions:

  • Why do the LogonIds show as different for each exec cmd.exe in the same container?

  • Why is the keytab successfully used to generate a ticket in the ticket cache, yet klist never displays the cached ticket? This post indicated the same problem in the standard Windows non-container world, but the difference is the ticket still authenticated properly for that User, and in this case my ticket does not seem to be used at all.

*The intention is not to put the keytab in my Docker Image in the long run. I am just doing this for testing purposes on my dev box.

Howard_Roark
  • 4,088
  • 1
  • 14
  • 24
  • You appear to be mixing implementations. The first half is MIT (?) Kerberos, the second half is Windows built-in Kerberos. They don't usually interact with one another. – Steve Apr 01 '20 at 15:48
  • The kinit binary is MIT Kerberos for Windows. It is configured to interact with a Realm that uses Windows built-in Kerberos. I thought this might work because it works very well for my Linux containers. They use the kinit binary from MIT Kerberos for Linux to interact with the same Realm that uses Windows built-in Kerberos. – Howard_Roark Apr 02 '20 at 03:14
  • There are specific ways to make containers talk to domains: https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/gmsa-configure-app – Steve Apr 02 '20 at 15:21
  • I spent yesterday implementing that, and it does work. The downside is the adjustments that will need to be made on the container orchestration platform side of things to handle joining the security group part in an immutable way https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts. The nice thing about the keytab idea is the app can just initialize the keytab and get a ticket, and that's that--no platform/system changes needed. – Howard_Roark Apr 02 '20 at 16:41

0 Answers0