能否同时为ASP.NET WebForms站点配置Windows与Azure AD认证？

首先明确：ASP.NET WebForms站点完全可以同时启用Windows认证和Azure AD认证，但你的现有配置存在几个核心冲突，导致了无限重定向和404.15错误，具体问题和修复步骤如下：

一、现有配置的核心问题 #

1. 传统Forms认证与OWIN Cookie认证的冲突
   你在web.config里配置了<authentication mode="Forms">，同时在OWIN Startup.cs里启用了CookieAuthentication——这两套认证系统（传统ASP.NET管道的Forms认证和OWIN中间件的Cookie认证）会互相干扰：

   • 当useAzureAd=true时，OWIN会尝试用自己的Cookie管理会话，但传统Forms认证仍在抢占认证管道，导致系统不断重定向到sso.aspx，形成无限循环。
   • 循环过程中会反复追加ReturnUrl等参数，最终导致查询字符串过长，触发IIS的请求筛选限制（404.15错误）。

2. 自动重定向逻辑的冲突
   你把OWIN的LoginPath设为/sso.aspx，同时又在sso.aspx里打算触发Azure AD认证，这会导致：当OWIN检测到未认证请求时重定向到sso.aspx，而sso.aspx又触发Azure AD认证，认证完成后回调回来，若后续逻辑处理不当，又会触发重定向，形成循环。

二、具体修复步骤 #

1. 调整web.config中的认证配置 #

• 移除或修改传统Forms认证配置，改为禁用传统认证模式：

  <!-- 替换原来的<authentication mode="Forms"> -->
  <authentication mode="None" />
  

  原因：我们将完全依赖OWIN中间件来管理认证会话，传统Forms认证与OWIN不兼容，必须禁用。

• 保留sso.aspx的授权配置（允许匿名和所有用户访问），确保用户能进入这个页面触发认证逻辑：

  <location path="sso.aspx">
    <system.web>
      <authorization>
        <allow users="?,*" />
      </authorization>
    </system.web>
  </location>
  

• 解决404.15查询字符串过长问题，在web.config的<system.webServer>节点下添加请求筛选配置：

  <system.webServer>
    <security>
      <requestFiltering>
        <!-- 增大查询字符串长度限制，默认是2048，这里设为8192足够应对Azure AD回调参数 -->
        <requestLimits maxQueryString="8192" />
      </requestFiltering>
    </security>
  </system.webServer>
  

2. 优化OWIN Startup.cs配置 #

统一认证类型命名，避免自定义名称导致的不一致：

public void Configuration(IAppBuilder app) {
  if (useAzureAd) {
    // 使用默认的Cookie认证类型，避免自定义名称的潜在冲突
    var defaultAuthType = CookieAuthenticationDefaults.AuthenticationType;
    app.SetDefaultSignInAsAuthenticationType(defaultAuthType);
    
    app.UseCookieAuthentication(new CookieAuthenticationOptions() {
      AuthenticationType = defaultAuthType,
      // 这里不需要设置LoginPath，因为我们会在sso.aspx手动处理跳转
      // LoginPath = new PathString("/sso.aspx"),
      CookieSecure = CookieSecureOption.SameAsRequest
    });
    
    app.UseOpenIdConnectAuthentication(
      new OpenIdConnectAuthenticationOptions {
        ClientId = clientId,
        Authority = authority,
        RedirectUri = redirectUri,
        PostLogoutRedirectUri = redirectUri,
        Scope = OpenIdConnectScope.OpenIdProfile,
        ResponseType = OpenIdConnectResponseType.IdToken,
        TokenValidationParameters = new TokenValidationParameters() { ValidateIssuer = false },
        Notifications = new OpenIdConnectAuthenticationNotifications { 
          AuthenticationFailed = OnAuthenticationFailed,
          // 认证成功后处理用户逻辑，比如查询数据库
          SecurityTokenValidated = context => {
              // 从Azure AD声明中获取用户信息，查询数据库
              string aadUser = context.AuthenticationTicket.Identity.Name;
              // 这里可以添加自定义声明或验证逻辑
              return Task.CompletedTask;
          }
        }
      });
  }
}

关键修改：移除LoginPath配置，因为我们将在sso.aspx手动控制认证流程，不再依赖OWIN的自动重定向。

3. 重构sso.aspx的后台逻辑 #

在sso.aspx中手动处理Windows认证和Azure AD认证的分支，避免循环：

protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        // 先尝试获取Windows认证的用户信息
        string windowsUser = Request.ServerVariables["LOGON_USER"];
        
        if (!string.IsNullOrEmpty(windowsUser))
        {
            // 1. 验证Windows用户（AD验证+数据库查询）
            if (ValidateWindowsUser(windowsUser))
            {
                // 创建OWIN认证票据，完成登录
                var claims = new List<Claim>
                {
                    new Claim(ClaimTypes.Name, windowsUser),
                    // 添加其他业务所需的声明
                };
                
                var authType = CookieAuthenticationDefaults.AuthenticationType;
                var identity = new ClaimsIdentity(claims, authType);
                HttpContext.GetOwinContext().Authentication.SignIn(identity);
                
                // 重定向到原请求页面或首页
                RedirectToReturnUrl();
                return;
            }
        }
        
        // 2. Windows认证失败或无Windows用户，触发Azure AD认证
        TriggerAzureAdLogin();
    }
}

private bool ValidateWindowsUser(string windowsUser)
{
    // 这里实现你的AD用户验证和数据库查询逻辑
    // 示例：检查AD是否存在该用户，且数据库中有对应记录
    return true; // 替换为实际验证结果
}

private void TriggerAzureAdLogin()
{
    // 设置重定向目标（原请求页面或首页）
    var returnUrl = Request.QueryString["ReturnUrl"] ?? "~/";
    var properties = new AuthenticationProperties { RedirectUri = returnUrl };
    
    // 触发Azure AD登录挑战
    HttpContext.GetOwinContext().Authentication.Challenge(
        properties, 
        OpenIdConnectAuthenticationDefaults.AuthenticationType);
}

private void RedirectToReturnUrl()
{
    string returnUrl = Request.QueryString["ReturnUrl"];
    if (!string.IsNullOrEmpty(returnUrl) && Url.IsLocalUrl(returnUrl))
    {
        Response.Redirect(returnUrl);
    }
    else
    {
        Response.Redirect("~/");
    }
}

4. IIS配置确认 #

• 确保站点启用Windows认证，禁用Forms认证（因为我们不再使用传统Forms）。
• 确认sso.aspx的Windows认证是启用的（在IIS中该页面的特性设置里开启），这样才能获取到LOGON_USER变量。

三、关键注意事项 #

• 传统ASP.NET认证管道（Forms/Windows）和OWIN中间件是两套独立的系统，混合使用时必须禁用传统认证模式（mode="None"），统一用OWIN管理会话。
• 所有认证后的跳转逻辑都要通过OWIN的Authentication.SignIn和Challenge方法处理，避免依赖传统的FormsAuthentication.RedirectFromLoginPage等方法。

内容的提问来源于stack exchange，提问作者Андрей Анатольевич