答案1
这看起来很有希望:
ADFS 的一个真正有用的方面是,ADFS 附带的 ASPX 页面中有一个代码级功能。这些功能对于添加代码以使用默认主域或出于自定义原因更改 ADFS 的行为非常有用。它们还提供了一种对收到的 SAMLResponses 进行自定义验证的简单方法。这还可用于在 ADFS 使用 SAMLResponse 之前对其进行操作,以实现 ADFS 未提供的某些功能。
通常,对于传入的 SAMLResponse,需要检查几个标准事项,ADFS 也会这样做,但可能并不总是向您提供人类可读或可理解的错误消息。以下是一些示例:
- 检查签名,因为 ADFS 已配置(正确的算法,使用了正确的证书)
- 检查 ADFS 配置是否加密
- ETC...
在收到的 SAMLResponse 中检查这些典型详细信息将帮助您识别问题,以便您的合作伙伴能够快速处理问题。
一个常见的请求是能够将 ADFS 收到的每个请求的 SAMLResponse 记录到数据库中。为此,只需向 global.asax.cs 文件添加一些代码,例如以下代码片段:
public void Application_BeginRequest()
{
HttpRequest request = HttpContext.Current.Request;
HttpResponse response = HttpContext.Current.Response;
if (!String.IsNullOrEmpty(request["SAMLResponse"]))
{
SaveSamlResponseToDB(request["SAMLResponse"].ToString());
}
}
完成此操作后,您可以操作 SAMLResponse 并对其进行自定义验证。这提供了一种机制,可以进行超出 ADFS 当前功能的额外验证,并且对各种测试场景非常有用。
答案2
根据 Windows 管理员的建议,我执行以下操作解决了该问题。
- 确保 W32Time 服务正在使用 NTP(但实际上没有)
- 确保所有更新均已安装(已安装)
- 确保所有服务都在服务帐户下运行,而不是域控制器帐户下运行(它们不是)
- 确保 ADFS 在服务帐户下运行后,重新创建服务提供商
此时,错误仅发生在部分 AD 用户身上。对于这些用户,我重置了他们的密码,问题就解决了。
虽然我不完全确定为什么会发生这种情况或这些步骤如何修复它,但我的理论是,不使用一个服务帐户来管理所有内容导致写入的文件无法由在不同帐户下运行的进程读取。
希望这对某人有帮助。