Azure App Service with windows container http logs are missing the cs-username

Question

I have an asp.net 5 web application on .NET Framework 4.8 running as an azure app service with a windows server 2019 container image. I setup a diagnostic setting to send the 'AppServiceHTTPLogs' to an event hub and when inspecting the logs, I noticed that the CsUsername property is missing for authenticated requests.

Running the same container image locally or even as an Azure Container Instance and inspecting the IIS logs on the container I can see the username so it's something to do with how and where the https logs are captured when running as an app service where the logs don't pick up on the authenticated principal's identity name.

Has anybody else run into this? Do I need to expose the principal as a response header for the logging to pick it up?

UPDATE: 02/24/2022

In addition to asking here I had also started a case with azure support inquiring about why the web server logs from an azure app service on a windows app service plan running a windows container is missing the cs-username information whereas consoling the running container of the app service and inspecting the w3c log in C:\inetpub\logs\LogFiles\W3SVC1 shows the cs-username value.

They finally got back and said:

At this moment I'm afraid that this feature is not supported for the architecture that you have set, the only way to get the details for the CsUsername is to deploy a Linux App Service and then target an Azure Storage account as the data endpoint.

That doesn't help me at all since I can't run a .NET Framework 4.8 ASP.NET MVC 5 application container in a Linux app service plan. Generally, through this ordeal of deploying windows containers to run as an azure app service with an Azure DevOps pipeline to running the container as an azure app service, I've found microsoft's support for running windows based containers to be very challenging and without much ongoing support. They try to push the linux hosting environment which unfortunately is an option only if your architecture is based on the .NET core framework.

Answer 1

Has anybody else run into this? Do I need to expose the principal as a response header for the logging to pick it up?

This issue could be resolved in 2 different ways below are the resolution steps

A] Change applicationHost.config directly

Edit the applicationHost.config file for the Advanced Logging feature using the following steps:

• Open the C:\Windows\System32\inetsrv\config\applicationHost.config file in a text editor.
• Locate the advancedLogging section.
• In advancedLogging, locate the <field id='UserName'...> entry.

<field id="UserName" sourceName="UserName" sourceType="
 RequestHeader " logHeaderName="cs-username" category="Default" loggingDataType="TypeLPCSTR" />

• Modify the sourceType field to be BuiltIn, as follows:

<field id="UserName" sourceName="UserName" sourceType="
 BuiltIn " logHeaderName="cs-username" category="Default" loggingDataType="TypeLPCSTR" />

B] Change applicationHost.config by Appcmd.exe

You can use the appcmd.exe tool to make the configuration changes .

Run this command :

appcmd.exe set config -section:system.webServer/advancedLogging/server
/fields.[id='UserName'].sourceType:"BuiltIn" /commit:apphost

For complete information you can go through the below mentioned links

No cs-username data in Advanced Logging - Internet Information Services | Microsoft Docs

cs-username not populated in IIS logs · Issue #6741 · dotnet/aspnetcore · GitHub