.png)
绝望的菜鸟在这里...我的问题有点与“从 Azure AD SSO 身份验证迁移到 ADFS“ 和 ”在 Azure 中安装 ADFS 以供内部访问“尽管这些对我来说看起来有点过度——我们所处理的只是一个本地云 Java Web 应用程序和一个 Azure AD -> 本地 AD 转换的需求，没有联合/SSO/MFA，也没有与外部网络的连接。我们可以自由地进行清除重复（尚无数据），包括使用任何 Windows Server 版本进行整个 DC/AD 设置。甚至不需要面向未来，因为这是一个短期设置，可以在购买之前试用上述狭窄市场的应用程序，该应用程序来自使用 Azure AD 作为身份验证提供程序的独立开发人员。
我们无权“使用 Azure AD 作为身份验证提供程序”。不行。没有商量余地。开发人员无法提供帮助，他们只是使用了最直接的方法（例如来自Microsoft 学习课程，和 Swagger 框架)，但他们声称他们无意将他们的产品专门锁定在微软，没有对应用程序使用的任何 OAuth/OpenID 参数进行硬编码或调整。
因此，我们首先“按照设计”部署了此应用程序进行测试（并且必须尽快销毁它），只是为了确保所有部件都能协同工作并且正确遵循安装过程。是的，这一切都适用于 Azure。但我们需要它在本地 AD / FS 上工作。我找不到任何可以模拟完全和永久断开连接环境的 Azure 身份验证的东西。强文本如果存在，请建议，否则 Windows Server AD / FS 似乎是最可行的选择。
我认为对于像我们这样简单的场景，模仿 Azure AD 是可能的，因为我们设置的所有 OAuth/OpenID 部分都是手动过程 - 创建帐户、在 Azure 中注册企业 Web 应用程序、在部署之前配置 Java Web 应用程序...只是事物的名称不同，范围/声明/权利/等等，但核心技术是相同的，都是关于模板/约定......对吗？
因此，我被委以重任，要实现我认为可能实现的目标。现在，我搜索/阅读得越多，就越能看到操作指南和常见问题解答指向相反的方向，即从本地到云，而不是相反。
我完全错了吗？如果是，是否有万无一失的技术原因？还是我只是没有找到正确的指导？
我认为我需要的只是一个参考表，例如“什么在哪里表示什么，Entra ID 与 2022 AD FS”，或者一些如何在 Windows Server AD FS 4 中正确创建 Azure 企业应用程序模拟的方法。也许有人遇到了我上面提到的 Microsoft Learning 课程的 Azure 前版本，该课程教如何“正确”将 Windows AD 配置为 Web 应用程序身份验证提供程序？
我所说的“正确”是指当基于 Swagger 的简单 Web 应用程序发送（或不发送）额外参数（范围、令牌等）时，提供商不会中断流程，也不会发回任何可能使应用程序混淆的参数。换句话说，对于这样的用例，是否有通用的方法？
作为基准——这是我们在重新部署应用程序时放入配置文件中的内容：
Registration ID ( api://{unique GUID-formatted value of Azure Single Page application} )
Client ID, may be also called "App ID"
unique GUID-formatted value is the same as above
Metadata ( https://login.microsoftonline.com/{free Azure tenancy ID}/v2.0/.well-known/openid-configuration )
Authentication URL ( https://login.microsoftonline.com/{free Azure tenancy ID}/oauth2/v2.0/authorize )
Token URL ( https://login.microsoftonline.com/{free Azure tenancy ID}/oauth2/v2.0/token )
Authentication Authority ( https://login.microsoftonline.com/{free Azure tenancy ID}/v2.0/ )
像“值 A 来自标题为 C 的对话框中的字段 B，属于工作流 D”这样的指导会很有用。或者也许有人看到了 .ps1 来生成这样的配置？（再次强调，这与生产环境相去甚远，只是一个独立的隔离/离线环境）
F1，请按 F1！...咕噜...咕噜...咕噜...（气泡，沉默）