不同运行设备下EWS的Autodiscover服务无法正常工作问题咨询

错误根因说明 #

你遇到的HTTP/1.1 401 Unauthorized报错，附带LiveIdBasicAuth:UnfamiliarLocation标记，本质是微软账号的安全策略拦截：第二个邮箱的常用登录地与Azure服务器的公网IP归属地不匹配，触发了未知位置的基础认证登录拦截规则；第一个邮箱未被拦截是因为其安全策略配置、常用登录地范围包含了当前Azure的IP段。

排查步骤 #

• 核对登录拦截记录：登录第二个邮箱对应的微软账号管理后台，查看安全板块下的登录活动日志，找到IP归属为Azure区域的失败登录记录，确认拦截原因和时间与故障请求匹配。
• 对比两个邮箱的安全配置：检查两个邮箱的多因素认证（MFA）规则、信任IP/常用位置配置、安全默认值开关状态，确认第一个邮箱是否提前将Azure IP段加入信任列表，或是关闭了未知位置的基础认证拦截。
• 验证EWS配置正确性：确认故障环境中EWS实例的TraceFlags已设置为TraceFlags.ALL，使用的Exchange版本匹配outlook.de的服务要求，无基础认证参数填写错误的问题。

解决方案 #

方案1：添加Azure IP为信任地址（推荐） #

进入第二个邮箱的账号安全中心，个人账号直接在微软账号安全页的「信任位置」板块添加Azure服务器的公网出口IP；如果是企业租户账号，联系租户管理员在Azure AD的「命名位置」中添加对应IP段，同时调整对应账号的条件访问策略，放开该IP段的基础认证访问权限，配置完成后等待10~15分钟重新测试即可。

方案2：标记风险登录为可信 #

如果是临时使用的场景，可以在触发拦截后，登录该邮箱的绑定安全邮箱/手机，找到微软发送的异地登录告警，选择「本次是本人操作」，标记该登录行为为可信后，同IP的后续EWS请求即可正常通过校验。

方案3：更换为OAuth 2.0认证 #

目前outlook.de已经逐步收紧基础认证（Basic Auth）的适用范围，你可以将EWS的认证逻辑替换为OAuth 2.0认证模式，申请对应的EWS访问权限令牌后发起请求，该模式不受基础认证的位置拦截规则限制，安全性和兼容性更高。

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