Is it possible to create another user with the same permissions as containeruser

[winkingturtle-vmw]

We follow the recommended approach for creating new users in our Dockerfile. When we create and link a gMSA with newly created containers, we are observing that running processes as our custom user fails to authenticate with SQL Server, but when the same process is ran as containeruser or NT Authority\NetworkService it's able to authenticate with SQL Server. We unfortunately cannot find any Dockerfile references showing how containeruser and containeradminstrator accounts are created so that we duplicate the same process. We had a few questions hoping someone else knows the answer:

• Can we create new local users that have the same permission as containeruser ?
• Our understanding is that there is a User manager virtual active directory and those users are part of that domain. How do we connect with that virtual AD and do we need to add our local user to that AD for this to work?
• If it's not possible to create a user with the same permissions, can we rename containeruser to our custom user? We tried using wmic useraccount but containeruser was not found.
• What type of permission can we give our custom user to do this one operation?

cc: @ebroberson

[ntrappe-msft]

Quick question, is gMSA trying to authenticate with an external SQL server or a SQL server instance in each container?

[ebroberson]

It's an external SQL server.

[winkingturtle-vmw]

Thank you @ntrappe-msft for taking a look at this issue for us. We would love to enable this feature for our users and your help is greatly appreciated.

[ntrappe-msft]

Are you seeing any specific errors or logs when gMSA tries to authenticate with the server? We'd expect gMSA (managed by AD) and built-in profiles like containerUser to have different credentials. Ideally, a log or error message might indicate that if that's the issue.

[winkingturtle-vmw]

Thanks @ntrappe-msft and @fady-azmy-msft for your response. We fetched the following event logs and don't see any errors.

Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Compute-Admin | format-list
Get-WinEvent -LogName Microsoft-Windows-Containers-CCG/Admin | format-list

On the SQL Server side we see the login attempt and failure:

SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed 
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Do you suggest looking at any other logs?

We are fairly confident that our CCG plugin is configured propperly since the same custom-user (vcap) can authenticate against AD when using a different endpoint for User->App Authentication. This issue is only happening in the case of App->SQL Server authentication.

Here is our reproduction steps:

HWC: https://github.com/cloudfoundry/hwc App: https://github.com/cloudfoundry/winc-release/tree/develop/src/WindowsAuth SQL Server URL: https://github.com/cloudfoundry/winc-release/blob/develop/src/WindowsAuth/Web.config#L8 Curl command: curl.exe http://localhost:8080/sql Image: cloudfoundry/windows2016fs:latest (this is actually a 2019 Server core image)

docker run -it -v <MOUNT_DIR>:C:/service --user "vcap" --security-opt "credentialspec=file://gmsa.json"  cloudfoundry/windows2016fs:latest powershell
mkdir C:\users\vcap\app
cp -recurse -force C:\service\app\* C:\users\vcap\app\
cd C:\users\vcap\app
$env:PORT=8080; C:\service\hwc.exe

Running above command with containeruser works as expected.

[ebroberson]

Hello @ntrappe-msft @fady-azmy-msft, and updates on this issue?

[ntrappe-msft]

The gMSA team is still doing their investigation. We're trying to figure out which container user profile is associated with the gMSA identity. I wouldn't recommend trying to adjust the privileges of your custom profile nor trying to give it the same permissions of a built-in profile (e.g. containerUser). After creating a profile and linking it to a gMSA, it should be able to authenticate so something else is probably causing a problem.

I'll let you know what we find and we may ask for logs to diagnose the root cause. Thanks again for your patience.

[winkingturtle-vmw]

Thank you all for your effort in trying to figure out what is different between the containeruser and any other user. We are looking for a way to bring this feature for our users so that they can connect their apps to a SQL Server.

[winkingturtle-vmw]

@ntrappe-msft is there any new development on this issue ?

[winkingturtle-vmw]

@ntrappe-msft can we provide more information to help with this issue? We really would like to enable this feature for our IWA users and this issue is blocking us from moving forward.

[winkingturtle-vmw]

@ntrappe-msft Thanks again for your efforts in trying to fix this issue. I am pinging this issue to keep it open

[ntrappe-msft]

Thank you for the continued pings. Our support team is having a meeting today and I'm hoping we'll receive a workaround or fix we can share externally.

[winkingturtle-vmw]

@ntrappe-msft our users are looking forward to having this feature enabled. Is there any updates we can share with them?

[ntrappe-msft]

Hi. Sorry this is taking a while. I'm going to ping the team responsible.

[emalm]

Hi, @ntrappe-msft, are there any updates on this issue? This difference in behavior for this distinguished containeruser account and other user accounts on the system is continuing to block development of these authentication features. Even any forward progress in understanding the underlying issues would be helpful to know about. Thanks!

[avin3sh]

Do we have an update here ? There are more questions like why does Configure your app to use a gMSA ask you to specify USER "NT AUTHORITY\NETWORK SERVICE" -- and how is it different than USER ContainerUser -- the behavior seems similar, gMSA authentication still works in either of the cases, then why this recommendation ?

And, then, the original questions raised here, how do you actually go about mapping additional gMSA identities -- the doc says it is possible but is silent on how to achieve this

Containers can also be configured with additional gMSAs, in case you want to run a service or application in the container as a different identity from the container computer account.

[winkingturtle-vmw]

@riyapatel-ms Checking to see if the team has had a chance to look at this issue and help with a workaround?

[geofffranks]

@ntrappe-msft @riyapatel-ms @fady-azmy-msft any updates or ETA?

[winkingturtle-vmw]

@riyapatel-ms @ntrappe-msft We are coming up on our anniversary for this ticket. Would you like us to keep pinging this issue or is there a better way for us to communicate?

Additionally, it looks like there has been multiple gMSA github issue open that are not getting any feedback. Would you say there is no active development happening in this area or is this a misunderstanding?

[vrapolinario]

Coming late and although I read the thread, I wanted to ask a few questions/clarify a few things:

• The ContainerUser reference you made is to which account is used to run the container OS. Think of it as an interactive logon.
• The NetworkService account is the context to which your application needs to be executed so the gMSA process kicks in.

Please note these are different things. You could potentially create another user account to replace the ContainerUser, give it whatever privileges INSIDE THE CONTAINER you need and then in your dockerfile specify that user account for running the container. Then when you configure the application inside the container, you set the service to run as NetworkService.

Think of it this way: If you had a Windows Server VM with IIS, you would configure the w3svc service to run as NetworkService, but you can log into that VM using your credentials.

Is this what you are trying to accomplish? Sorry if I misunderstood the question. I do want to point out that development for gMSA is not paused. We have been updating the documentation, fixing bugs, etc. Unfortunately, given the nature of Windows, many cases will take longer than people are used to when working on open-source projects. Please rest assured that gMSA is important and a central piece of Windows containers.

[winkingturtle-vmw]

Thanks @vrapolinario for your response. In our container solution, we run processes as users instead of services and that's why we are running into this issue.

In summary, we've noticed that if the process that runs our HWC process is running as containeruser everything works as expected and we are able to talk to SQL Server, but if the same process is ran as any other users (in our case vcap is just a user), it will fail to authenticate with SQL Server. The mystery here is that this technology stack works for gMSA when containers authenticate against an Active Directory, but it only fails in the case app->SQL workflow.

Since we have to run processes as users, we have one of two options:

1. Figure out what registry to set or how to create another unprivileged user, just like containeruser, so that we can continue to use this workflow
2. We think that ccg is the only binary in between containers and SQL Serve. If there is anything we could fix in ccg to allow any normal user to do this operation.

I hope the context I provided helps clarify the original issue.

[ebroberson]

@ntrappe-msft @riyapatel-ms I noticed that this issue got the ADO label added. What does that mean for the status of this issue?

[ntrappe-msft]

@ebroberson Hi, the ADO label just means that we're tracking the Issue internally or have an internal discussion on the topic. We're waiting on updates from that internal discussion now.

[ebroberson]

@ntrappe-msft Any updates on that internal discussion?

[ntrappe-msft]

I'm still waiting on a response.

[microsoft-github-policy-service[bot]]

This issue has been open for 30 days with no updates. @riyapatel-ms, please provide an update or close this issue.

[ebroberson]

@ntrappe-msft Any updates on the status of this issue?