locked
IIS Basic Authentication - Local User Fails Authorisation, Domain User works RRS feed

  • Question

  • User-1898733732 posted

    I have a web application setup in IIS on Windows Server 2012 R2 and now moving this to Windows Server 2016 running on IaaS in AWS.

    This app has Basic Authentication setup and allows access for Domain Users as well as a single Local User setup on the server. This setup is working on the current system.

    After setting up the 2016 environment the application running in IIS will not authenticate the Local User setup on the new machine. The local user fails whether using the username by itself or using Machine Name\Username. The password is correct as I have copied and pasted from the same source for both creating the user and accessing the app. I have also reset the password to make sure it is correct.

    Domain users are successfully authenticated. I have added the Basic Authentication role for the server, Disabled Anonymous Authentication in IIS and enabled Basic Authentication. I have also made sure that the .Net Authorisation Rules are set to allow Allow.

    I tried setting the machine name as the Default Domain for Basic Authentication, but this does not help either.

    The request using the Local User is reaching IIS and not being stopped by a proxy as I can see the attempt in the IIS logs and it includes the correct username for the request. The status logged by IIS for the request is: 401 1 1385

    Is anyone able to provide ideas where I can look for what would be causing the Local User not to be able to authenticate while Domain User can?

    Wednesday, February 12, 2020 6:45 AM

All replies

  • User753101303 posted

    Hi,

    Not really and AFAIK using a local account is a bit unusual. You are entering the user as <machinename>\<username> or just <username> ?

    401.1 seems to point to invalid credentials (BTW the user is allowed to open a local session ?)

    Wednesday, February 12, 2020 10:18 AM
  • User-1898733732 posted

    Thanks for taking the time to reply.

    It is a bit unusual, but it is what we are stuck with at the moment.

    I have tried accessing with both <machinename>\<username> and just <username> with the same error for both.


    If by local session you mean can the Local User RDP to the server, then no remote access for Local Users is disabled by Group Policy.

    I have looked through the group policy settings to see if there was one which prevented access from outside the server other than RDP and nothing stands out.

    Thursday, February 13, 2020 1:12 AM
  • User288213138 posted

    Hi nharman,

    I have a web application setup in IIS on Windows Server 2012 R2 and now moving this to Windows Server 2016 running on IaaS in AWS.

    This app has Basic Authentication setup and allows access for Domain Users as well as a single Local User setup on the server. This setup is working on the current system.

    After setting up the 2016 environment the application running in IIS will not authenticate the Local User setup on the new machine. The local user fails whether using the username by itself or using Machine Name\Username. The password is correct as I have copied and pasted from the same source for both creating the user and accessing the app. I have also reset the password to make sure it is correct.

    Domain users are successfully authenticated. I have added the Basic Authentication role for the server, Disabled Anonymous Authentication in IIS and enabled Basic Authentication. I have also made sure that the .Net Authorisation Rules are set to allow Allow.

    I tried setting the machine name as the Default Domain for Basic Authentication, but this does not help either.

    The request using the Local User is reaching IIS and not being stopped by a proxy as I can see the attempt in the IIS logs and it includes the correct username for the request. The status logged by IIS for the request is: 401 1 1385

    Is anyone able to provide ideas where I can look for what would be causing the Local User not to be able to authenticate while Domain User can?

    According to your description, I need more information to analyze your problem.

    Can you post your IIS web.config setting? and what is the content of your Basic Authentication setting?

    Best regards,

    Sam

    Thursday, February 13, 2020 9:13 AM
  • User753101303 posted

    I was thinking about a policy that can prevent some users to even log locally on a machine. But it likely doesn't make sense for a local account. BTW this account is part of the "Users" group ?

    I would start anyway by looking at the "Security" event log. I would expect to find messages there for this authentication failure which hopefully could help to better understand thje problem...

    Thursday, February 13, 2020 9:22 AM
  • User-1898733732 posted

    Can you post your IIS web.config setting? and what is the content of your Basic Authentication setting?

    Best regards,

    Sam

    Thanks for taking time.

    Basic Authentication is Enabled in IIS all other Authentication types for the site are Disabled. The Basic Authentication has no Default domain or Realm set.

    The web config is as follows, I have removed items such as connection strings, app settings:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <configSections>
        <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
        <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
        <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
        <section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
        <sectionGroup name="common">
          <section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
        </sectionGroup>
        <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
      </configSections>
      <appSettings>
        
      </appSettings>
      <system.web>
        <compilation debug="true" targetFramework="4.5">
        </compilation>
        <httpRuntime targetFramework="4.5" />
      </system.web>
      <system.serviceModel>
        <services>
          
        </services>
        <behaviors>
          <serviceBehaviors>
            <behavior>
              <!-- To avoid disclosing metadata information, set the values below to false before deployment -->
              <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
              <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
              <serviceDebug includeExceptionDetailInFaults="true" />
            </behavior>
          </serviceBehaviors>
        </behaviors>
        <protocolMapping>
    
        </protocolMapping>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
        <bindings>
          <basicHttpBinding>
            <binding name="InboundWebServices" allowCookies="true" maxReceivedMessageSize="20000000" maxBufferSize="20000000" maxBufferPoolSize="20000000">
              <readerQuotas maxDepth="32" maxArrayLength="200000000" maxStringContentLength="200000000" />
              <security mode="TransportCredentialOnly">
                <transport clientCredentialType="Basic" />
              </security>
            </binding>
          </basicHttpBinding>
          <customBinding>
    
          </customBinding>
        </bindings>
        <client>
          
        </client>
      </system.serviceModel>
      <system.webServer>
        <!--
            To browse web app root directory during debugging, set the value below to true.
            Set to false before deployment to avoid disclosing web app folder information.
          -->
        <directoryBrowse enabled="true" />
      </system.webServer>
      <entityFramework>
        <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
          <parameters>
            <parameter value="v12.0" />
          </parameters>
        </defaultConnectionFactory>
        <providers>
          <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
          <provider invariantName="Oracle.ManagedDataAccess.Client" type="Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices, Oracle.ManagedDataAccess.EntityFramework, Version=6.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
        </providers>
      </entityFramework>
      <system.data>
        <DbProviderFactories>
          <remove invariant="Oracle.ManagedDataAccess.Client" />
          <add name="ODP.NET, Managed Driver" invariant="Oracle.ManagedDataAccess.Client" description="Oracle Data Provider for .NET, Managed Driver" type="Oracle.ManagedDataAccess.Client.OracleClientFactory, Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
          <remove invariant="System.Data.SqlClient" />
          <add name="SqlClient Data Provider" invariant="System.Data.SqlClient" description=".Net Framework Data Provider for SqlServer" type="System.Data.SqlClient.SqlClientFactory, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        </DbProviderFactories>
      </system.data>
      <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <dependentAssembly>
            <publisherPolicy apply="no" />
            <assemblyIdentity name="Oracle.ManagedDataAccess" publicKeyToken="89b483f429c47342" culture="neutral" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="Common.Logging.Core" publicKeyToken="af08829b84f0328e" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-3.3.1.0" newVersion="3.3.1.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="Common.Logging" publicKeyToken="af08829b84f0328e" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-3.3.1.0" newVersion="3.3.1.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" />
          </dependentAssembly>
          <dependentAssembly>
            <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
          </dependentAssembly>
        </assemblyBinding>
      </runtime>
      <oracle.manageddataaccess.client>
        <version number="*">
          <dataSources>
    
          </dataSources>
        </version>
      </oracle.manageddataaccess.client>
      <connectionStrings>
    
      </connectionStrings>
      <common>
        <logging>
          <factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4Net1210">
            <arg key="configType" value="INLINE" />
          </factoryAdapter>
        </logging>
      </common>
      <log4net>
        <appender name="FileAppender" type="log4net.Appender.RollingFileAppender">
          <file value="D:\WSLog\UnifierIntegration-" />
          <rollingStyle value="Date" />
          <datePattern value="yyyy-MM-dd.lo\g" />
          <staticLogFileName value="false" />
          <appendToFile value="true" />
          <layout type="log4net.Layout.PatternLayout">
            <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
          </layout>
        </appender>
        <root>
          <level value="DEBUG" />
          <appender-ref ref="FileAppender" />
        </root>
        <logger name="entity.framework.context">
          <level value="INFO" />
        </logger>
      </log4net>
    </configuration>

    Friday, February 14, 2020 12:55 AM
  • User-1898733732 posted

    BTW this account is part of the "Users" group ?

    The account is part of the Users group. I have also tried adding the user to the application folder directly and giving it full control which has not helped.

    I have also created a separate web site in IIS and given it one single HTML file and enabled Basic Authentication on that site and it the Local User cannot authenticate on that site either.

    So I have found any entry in the Security event log (Note for others: Use the Find function to search for the user name of the local user as the event may quickly move on from being at the top). Based on the message the Local User hasn't been granted the requested logon type The detail was as follows:

    An account failed to log on.

    Subject:
    Security ID: IIS APPPOOL\.NET v4.5
    Account Name: .NET v4.5
    Account Domain: IIS APPPOOL
    Logon ID: 0x21AFE

    Logon Type: 8

    Account For Which Logon Failed:
    Security ID: NULL SID
    Account Name: Local User
    Account Domain: Computer Name

    Failure Information:
    Failure Reason: The user has not been granted the requested logon type at this machine.
    Status: 0xC000015B
    Sub Status: 0x0

    Process Information:
    Caller Process ID: 0xa20
    Caller Process Name: C:\Windows\System32\inetsrv\w3wp.exe

    Network Information:
    Workstation Name: Computer Name
    Source Network Address: xxx.xxx.xxx.xxx
    Source Port: xxxxx

    Detailed Authentication Information:
    Logon Process: Advapi
    Authentication Package: Negotiate
    Transited Services: -
    Package Name (NTLM only): -
    Key Length: 0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

    Friday, February 14, 2020 2:19 AM
  • User-1898733732 posted

    So based on the Security log entry I've been searching around, but I can't find anything which states what needs to be changed to grant the requested logon type.

    Looking in group policy again I'm thinking it is most likely either:

    Windows Settings -> Security Settings -> Local Polices -> User Rights Assignment -> Access this computer from the network

    or

    Windows Settings -> Security Settings -> Local Polices -> User Rights Assignment -> Allow log on locally

    and I'm leaning to the first one. I'll see whether I can get the group policy changed for this server and see if it helps.

    Friday, February 14, 2020 2:24 AM
  • User753101303 posted

    According to http://techgenix.com/logon-types/ logon type 8 is NetworkCleartext. Your site doesn't use https ? More likely "basic authentication" over http is now blocked by default.

    Edit : I was thinking abouit "log on locally" but I'm really not sure it's related. I don't find for now how to enable this logon type but hopefully you are using http and the real fix might be to use https instead.

    Friday, February 14, 2020 8:59 AM
  • User-1898733732 posted

    Your site doesn't use https ? More likely "basic authentication" over http is now blocked by default.

    Correct the site doesn't currently use https, this is something i'm hoping to get to change in the future.

    I don't believe that https will help as it currently works fine as long as I access using a user from the domain rather than a local user.

     I am trying to get the ok to use a service account so we can use a domain user instead.

        

    I unfortunately won't be able to get the "Access this computer from the network" policy setting changed in the new environment to see if this fixes the issue.

    If I can I'll change it in the old environment before decommissioning to see if removing the Users group causes the issue to occur.

    Monday, February 17, 2020 6:58 AM
  • User753101303 posted

    Might be a new feature or something done previously for domain accounts which would explain why you have a difference..

    Using https is preferered as else anyone spying the network could grab the password. i!f you want still to allow that maybe a Windows admin forum would be better. I would browse through security policies though for now I can't find something that matches in the doc at https://docs.microsoft.com/en-us/windows-server/security/windows-authentication/group-policy-settings-used-in-windows-authentication

    Monday, February 17, 2020 8:24 AM