Azure Web应用身份验证及调用内网Windows身份验证Web服务方案咨询

当然可以实现！你已经搭好混合VPN打通了Azure和本地的网络，接下来核心就是搞定「Azure AD身份 → Windows身份」的转换，让Web API能安全地访问本地的SOAP服务。下面是一步步的具体配置：

1. 先确认网络连通性（基础中的基础） #

首先得确保Azure上的Web API确实能通过VPN访问到本地的SOAP服务：

• 登录Azure Portal，找到你的Web App，进入「网络」→「VNet集成」，确认已经关联到混合VPN所在的虚拟网络
• 可以用Web App的Kudu工具（「高级工具」里打开），用curl或者PowerShell的Invoke-WebRequest测试访问SOAP服务的URL，先确保能拿到响应（如果有不需要认证的测试接口最好，先排除网络问题）

2. 从Azure AD请求中获取用户身份信息 #

因为你的Web API已经开了Azure AD认证，每个请求都会带Azure AD的身份信息，你需要从这里拿到能映射到本地Windows账号的标识：

• 在.NET代码里，通过HttpContext.User就能获取当前用户的Claims，比如upn（用户主体名称）或者email——如果你的Azure AD和本地AD是用AD Connect同步的，这个UPN通常和本地Windows账号的UPN完全一致，直接就能对应上
• 如果没有做AD同步，那你得自己维护一个映射表（比如存数据库），把Azure AD用户ID对应到本地的Windows账号

3. 配置Windows认证的请求发起（两种常用方式） #

方式一：用专用服务账号（推荐，简单可靠） #

这种方式是创建一个专门的本地Windows服务账号，给它访问SOAP服务的权限，然后让Web API用这个账号去发起请求：

• 先在本地AD里创建一个服务账号，比如svc-azure-soap，给它分配SOAP服务的访问权限
• 在Azure Portal的Web App「配置」→「应用程序设置」里，添加两个环境变量：LOCAL_WIN_USER（填服务账号的用户名，比如domain\svc-azure-soap）和LOCAL_WIN_PASS（填密码）——密码别直接明文填，用Azure Key Vault存储，然后通过应用设置引用密钥更安全
• 在你的SOAP客户端代码里，用这个服务账号的信息创建NetworkCredential，赋值给SOAP客户端的凭据：

  var soapClient = new YourSoapServiceClient();
  var winCred = new NetworkCredential(
      Environment.GetEnvironmentVariable("LOCAL_WIN_USER"),
      Environment.GetEnvironmentVariable("LOCAL_WIN_PASS")
  );
  soapClient.ClientCredentials.Windows.ClientCredential = winCred;
  
  // 发起SOAP请求
  var response = await soapClient.YourTargetMethodAsync();
  

方式二：模拟当前用户身份（适合需要用户级权限控制的场景） #

如果必须用当前访问Web API的Azure AD用户对应的本地Windows账号去访问SOAP服务，就得做身份模拟，但这个配置会复杂一些：

• 前提是Azure AD用户和本地Windows账号的UPN一致（通过AD Connect同步）
• 需要配置Kerberos约束委派：让Web App的Azure AD服务主体能委派到本地SOAP服务的SPN（服务主体名称）
• 代码里可以通过用户的UPN获取Windows身份令牌，然后模拟身份发起请求：

  using System.Security.Principal;
  using System.Runtime.InteropServices;
  
  // 导入Windows的LogonUser API
  [DllImport("advapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
  private static extern bool LogonUser(string lpszUsername, string lpszDomain, string lpszPassword,
      int dwLogonType, int dwLogonProvider, out IntPtr phToken);
  
  // 获取当前用户的UPN
  var userUpn = HttpContext.User.FindFirst(System.Security.Claims.ClaimTypes.Upn)?.Value;
  if (string.IsNullOrEmpty(userUpn))
  {
      throw new UnauthorizedAccessException("无法获取用户的UPN信息");
  }
  
  // 拆分UPN为域名和用户名
  var upnParts = userUpn.Split('@');
  var username = upnParts[0];
  var domain = upnParts[1];
  
  // 这里需要注意：如果用Kerberos委派，不需要密码，直接用用户的身份令牌；如果用NTLM，可能需要密码，但Azure AD不会返回用户密码，所以优先用Kerberos
  IntPtr userToken;
  if (LogonUser(username, domain, null, 9, 0, out userToken)) // 9代表LOGON32_LOGON_NEW_CREDENTIALS
  {
      using (var identity = new WindowsIdentity(userToken))
      using (var impersonationContext = identity.Impersonate())
      {
          // 在模拟上下文里发起SOAP请求
          var soapClient = new YourSoapServiceClient();
          soapClient.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation;
          var response = await soapClient.YourTargetMethodAsync();
      }
  }
  

  划重点：模拟用户的方式对Kerberos配置要求高，容易出问题，除非业务必须，否则优先用方式一的服务账号模式。

4. 配置本地SOAP服务的权限 #

• 在本地IIS里，确保SOAP服务的站点已经启用「Windows认证」，并且禁用其他不需要的认证方式（比如匿名认证）
• 给你用的服务账号/用户账号分配SOAP服务的访问权限，比如在IIS的「授权规则」里添加允许该账号访问

5. 测试和排错 #

• 先在本地开发环境模拟：用Visual Studio跑Web API，配置好Azure AD认证，调用本地SOAP服务，确保能成功
• 部署到Azure后，用Postman或者Swagger调用Web API的接口，看能不能正常返回SOAP服务的响应
• 如果遇到认证错误，先看Web App的日志（「日志流」或者「应用服务日志」），再看本地SOAP服务的IIS日志，排查是身份配置问题还是网络问题

内容的提问来源于stack exchange，提问作者Jayvin