Windows AD 实训：AD FS 与 Gitea 域账号联合登录

4.2.1 已定位：CA 网站本机可访问，FS01 不能访问#

本次 FS01 的实际查询显示：

• qy.net 同时解析到 192.168.254.10 和 192.168.254.11，不适合作为只部署在 CORE01 的 CA 网站固定入口。
• qynet-core01.qy.net 解析到 192.168.254.10。
• FS01 到 CORE01 的 Ping 成功，但按主机名及 IP 测试 TCP 8443 均失败。
• CORE01 的 8443 存在监听，LocalAddress 为 ::，OwningProcess 为 4。System／HTTP.sys 承接 IIS 连接时可以出现该结果，它不是“进程异常”的证据。
• 添加仅允许 FS01 地址访问的入站放行规则后，本人确认网页已可访问。该对照表明放行规则解决了本次连接问题，不等于所有网页访问失败都由防火墙引起。

排查命令，FS01 执行：

1
Resolve-DnsName qy.net -Type A
2
Resolve-DnsName qynet-core01.qy.net -Type A
3
Test-NetConnection qynet-core01.qy.net -Port 8443
4
Test-NetConnection 192.168.254.10 -Port 8443

CORE01 管理员只读检查：

1
Get-NetTCPConnection -State Listen -LocalPort 8443 |
2
    Select-Object LocalAddress,LocalPort,OwningProcess

需要重现实验放行时，先核对已有规则，不重复添加：

1
# CORE01：本次已有规则时只查询，不重复创建
2
Get-NetFirewallRule -Name 'Lab-CAWeb-8443-FS01' -ErrorAction SilentlyContinue |
3
    Select-Object Name,Enabled,Direction,Action,Profile
4

5
# 仅在规则不存在、地址已核对且确认需要放行时执行
6
# New-NetFirewallRule -Name 'Lab-CAWeb-8443-FS01' `
7
#     -DisplayName 'Lab CA Web 8443 from FS01' `
8
#     -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8443 `
9
#     -RemoteAddress 192.168.254.20 -Profile Any

用明确的主机名访问 https://qynet-core01.qy.net:8443/certsrv/；同时核对 IIS HTTPS 绑定和网站证书名称。端口通了不代表证书已受信任，证书错误仍需单独处理，不能靠忽略浏览器警告完成验收。

此 Web 页面提供申请、获取已签发证书及下载 CA 证书等不同功能；不是只要下载一个 CER 就完成申请。微软 Web 注册说明

4.2.2 已遇到：CA 证书、用户证书库与计算机证书混淆#

本次操作中先后遇到三个问题：

1. 下载证书“颁发给”和“颁发者”均为 DEMO-CA-2026，且没有 SAN。应结合基本约束确认它是不是 CA 证书，不能因为扩展名为 CER 就认作 fs.qy.net 的服务器证书。
2. Web 申请后将证书安装进当前用户库，同时将私钥设为不可导出。不能通过重新下载 CER 或把 CER 导入计算机库，把该用户私钥一起迁移过去；本次选择重新在本地计算机上下文申请，不强行绕过私钥保护。
3. 改用 certlm.msc 后选择了默认“计算机”模板：申请成功，有对应私钥和服务器身份验证用途，但实际 SAN 只有 QYNET-FS01.qy.net，不包含 fs.qy.net，因此不能作为本次规划名称的 AD FS HTTPS 证书。

两个“个人”库不是同一个位置：

“个人”是证书存储分类，不表示不能供服务使用。把证书放进计算机库也不等于已经配置给 AD FS，后续还要在向导里选择它。

这张计算机证书先保留；证书签发后不能原地修改 SAN，也不能改文件名解决名称不匹配。下面的专用模板和重新申请是待执行修正步骤，不把上述截图作为修正完成的证据。

4.2.3 CORE01：复制 Web Server 模板，允许提供服务名称#

管理员运行 certtmpl.msc：

1. 找到 Web Server／Web 服务器模板，右键 → 复制模板；不修改默认“计算机”模板。
2. “常规”页将显示名称设为 ADFS Lab TLS，记录内部模板名称。若同名模板存在，先核对用途，不覆盖。
3. “兼容性”选择 CA 和 FS01 实际支持的版本，不高于本环境版本。
4. “使用者名称”页选择“在请求中提供”，允许填写 fs.qy.net，而不是从 AD 自动取 FS01 的主机名。出现安全提示时理解含义：申请者能提供名称，所以必须限制注册权限。
5. “扩展” → 应用程序策略：本实验只保留服务器身份验证，不增加客户端身份验证、智能卡登录、任意用途等不需要的 EKU。
6. “安全”页 → 添加 → 对象类型勾选“计算机” → 添加 QYNET-FS01，给它读取、注册权限；不授予自动注册、写入或完全控制。
7. 检查 Domain Users、Domain Computers、Authenticated Users 等广泛主体不具有注册／自动注册权限；可以保留必要读取及管理员管理权限，不把所有读取 ACE 一并删掉。
8. 密钥选择 RSA，最小 2048 位；服务器私钥不启用需要交互确认的强私钥保护。兼容选项允许时使用传统 RSA SChannel CSP／交换密钥，符合所选 AD FS 版本要求。
9. 本轮直接在 FS01 计算机库使用，可保持私钥不可导出，不必为了之前的迁移问题改成可导出。保存模板。

不要为了 SAN 开启 CA 全局接受任意 SAN 请求属性的开关，也不把此模板注册权授予全域用户。 本轮只新增用途明确、权限受限的 HTTPS 模板。微软模板管理说明

4.2.4 CORE01：发布新模板#

运行 certsrv.msc → 展开 DEMO-CA-2026 → 右键“证书模板” → 新建 → 要颁发的证书模板 → 选择 ADFS Lab TLS。

确认发布列表出现新模板，记录模板配置与发布截图；截图未产生时不预放图片链接。

4.2.5 FS01：在计算机库填写 CN 与 SAN，再注册#

管理员打开 certlm.msc → 个人 → 证书 → 所有任务 → 申请新证书 → Active Directory 注册策略：

1. 选择 ADFS Lab TLS，不再选默认“计算机”模板。
2. 点击“需要更多信息才能注册此证书……”链接，打开证书属性。
3. “使用者”页按以下两行分别填写并点击“添加”，确认值出现在对应列表：

4. “常规”页可将好记名称设为 ADFS HTTPS - fs.qy.net，这个标签不代替 SAN。
5. 核对私钥、算法、用途等与模板一致，确定后点击“注册”。
6. 如 CA 要求审批，记录申请编号并由管理员核对后批准，不把“挂起”当失败而反复申请。

看不到模板时，勾选“显示所有模板”，读取不可用原因；依次检查发布状态、兼容性、FS01 计算机的读取／注册权限，重新打开注册向导。不要立即重启 CA、扩大注册权限或换用户模板凑合。微软注册说明

4.2.6 FS01：验证新证书，避免只看“注册成功”#

在 certlm.msc → 个人 → 证书打开新证书：

• “常规”显示具有与证书对应的私钥。
• “详细信息” → 使用者备用名称：包含 DNS Name=fs.qy.net。
• “详细信息” → 增强型密钥用法：服务器身份验证。
• “证书路径”：链状态正常；有效期符合实际日期。

PowerShell 只读验证，用 SAN 扩展筛选，避免把 Subject 中的名字误当 SAN：

1
$adfsCandidates = @(Get-ChildItem Cert:\LocalMachine\My | Where-Object {
2
    $dnsNames = @($_.DnsNameList | ForEach-Object { $_.Unicode })
3
    $hasSan = @($_.Extensions | Where-Object { $_.Oid.Value -eq '2.5.29.17' }).Count -gt 0
4
    $hasSan -and ($dnsNames -contains 'fs.qy.net')
5
})
6

7
if ($adfsCandidates.Count -eq 0) {
8
    '本地计算机个人库没有 SAN 包含 fs.qy.net 的证书，请继续排查。'
9
} else {
10
    $adfsCandidates |
11
        Format-List Subject,Issuer,DnsNameList,EnhancedKeyUsageList,
12
            HasPrivateKey,NotBefore,NotAfter,Thumbprint
13
}

存在多张同名证书时，按有效期、颁发者、指纹和私钥状态明确选定，不默认第一张就是新申请。记录待用证书指纹，后续 AD FS 配置时选择同一张。

截图中“指纹算法 sha1”是指纹计算方式，不等于证书签名算法；检查签名算法须查看其独立字段。

4.2.7 核对 CA 信任与证书用途边界#

FS01 和 USER01 在 certlm.msc 中核对签发 CA 的证书链。若信任已通过域策略建立，验证即可，不重复导入。缺失时只导入已核对指纹的 CA 公钥证书：根 CA 放“受信任的根证书颁发机构”，中间 CA 放“中间证书颁发机构”。不要把 fs.qy.net 的叶证书当根 CA 导入。

CER 可以是 CA 公钥证书，也可以是服务器公钥证书；单看文件扩展名无法区分。PFX 可以携带证书与私钥，不能上传博客或 Git。私钥应始终保留在实际使用它的 FS01 上。

Gitea 的 PEM 证书与私钥在第六节按另一条实验路线准备，本节 CA 签发的 AD FS 证书不等于已经覆盖 gitea.qy.net。

HTTPS 证书与令牌签名证书用途不同：前者保护连接并标识服务器；后者让应用验证令牌来源。微软 AD FS 要求

6.4.1 本机 HTTPS 警告：先确认协议，再建立信任#

本次 Gitea 最初启动日志为 HTTP，ROOT_URL 还是 localhost。按 6.3 节配置并重启后，实际日志确认加载 C:\GiteaLab\custom\conf\app.ini，监听为 https://192.168.254.20:3000，ROOT_URL 为 https://gitea.qy.net:3000/。这证明 HTTPS 已启用，但还不代表浏览器信任证书。

浏览器仍警告时，查询发现本机计算机根证书库没有对应 Gitea 证书；导入后，本人确认 FS01 浏览器已显示安全。处理步骤：

1. FS01 管理员运行 certlm.msc。
2. 受信任的根证书颁发机构 → 证书 → 右键 → 所有任务 → 导入。
3. 选择 C:\GiteaLab\certs\gitea.qy.net.cer，核对来源和指纹，只导入已确认的本实验自签名公钥证书。
4. 完全退出浏览器再打开 https://gitea.qy.net:3000/，确认不再有证书警告。这次仅新增客户端信任，不需要因此重启 Gitea。

公钥证书和本机信任的只读检查：

1
$giteaCert = Get-PfxCertificate -FilePath 'C:\GiteaLab\certs\gitea.qy.net.cer'
2
$giteaCert | Format-List Subject,Issuer,Thumbprint,NotBefore,NotAfter
3

4
# 确认实际 SAN，不把 Subject 中的 Gitea 当作域名错误
5
$giteaCert.Extensions |
6
    Where-Object { $_.Oid.Value -eq '2.5.29.17' } |
7
    ForEach-Object { $_.Format($true) }
8

9
# 无输出表示未在这个本地计算机根库找到同一张证书
10
Get-ChildItem Cert:\LocalMachine\Root |
11
    Where-Object { $_.Thumbprint -eq $giteaCert.Thumbprint } |
12
    Format-List Subject,Thumbprint

比较指纹须使用同一种算法；浏览器可能展示 SHA-256，PowerShell Thumbprint 通常是 SHA-1，不能仅因两串不同判定不是同一证书。若仍有警告，记录错误码并检查 SAN、当前时间、有效期和浏览器实际收到的证书，先不要重新生成。

本机证书信任与远程端口放行是两件事。 此时 USER01 的 3000 尚未放行，不影响 FS01 本机导入证书；后续 USER01 访问时也要在 USER01 核对并建立信任。

6.4.2 核对初始化状态与管理员回退入口#

安装页面核对：

这个管理员是 Gitea 内部账号，不是 AD 账号，也不是 Windows 管理员。保留它作为 OIDC 失效时的回退入口，不能拿它绑定域普通用户。

安装后用管理员登录，核对配置已有 [security] INSTALL_LOCK = true；若安装页仍可用，先修复再开放访问。保存生成的安全配置，不手动清空密钥。

8.3.1 新建声明用 Web API#

原服务器应用位于 Gitea-Lab-A。此次实际操作另建应用程序组 Gitea-Lab-A-Claims，选择独立应用程序中的 Web API，不是重新生成一个 OIDC 客户端。

Web API 标识符填写此次已注册服务器应用的客户端标识：9567c1a1-940a-4041-8d26-c9c27a2b92e8。此值只对应本次实验；复现实验应以实际注册值为准。

实验访问控制选择“允许所有人”，客户端选择原有 Gitea-Lab-A 服务器应用程序。这里不是允许匿名访问，而是资源的访问控制策略；生产应按实际授权范围限制。初始仅勾选 openid，后续补充 allatclaims。

摘要截图只是创建前的配置记录，不单独证明后续声明发行或自动建号成功。

8.3.2 作用域列表中没有 allatclaims#

最初客户端权限列表没有 allatclaims，不能仅靠反复查找复选框解决。先在 FS01 管理员 PowerShell 查询本机作用域定义：

1
Get-AdfsScopeDescription | Select-Object Name,Description

确认确实不存在后，在“新建作用域”中填写名称 allatclaims，或采用等价命令；已经存在则不重复添加：

1
$adfsScopes = Get-AdfsScopeDescription -ErrorAction Stop
2
if (-not ($adfsScopes | Where-Object Name -eq 'allatclaims')) {
3
    Add-AdfsScopeDescription -Name 'allatclaims' `
4
        -Description 'Request access-token claims in the ID token' -PassThru
5
}

重新打开该 Web API 的“客户端权限”，选中原 Gitea 服务器应用，勾选 openid 和 allatclaims，应用并保存。

作用域定义存在、客户端已获授权、客户端实际请求，是三个不同环节。手工新增定义不等于系统已经具备对应功能；Windows Server 2016 还需核对微软文档所列更新支持（KB4019472 或包含相关修复的后续累积更新），不能盲目安装旧补丁。AD FS 的 OIDC 概念与自定义 ID token 条件

8.3.3 修正用户名与邮箱的声明映射#

Web API 属性 → 颁发转换规则 → 添加规则 → “以声明方式发送 LDAP 属性”。以下两张保留了排障过程，不是最终配置：第一张尚未填规则名称和特性存储；第二张虽选了 Active Directory，但直接输入短字符串，尚未确认声明类型与 JWT 短名称的对应关系。

查询声明描述，检查实际 ClaimType 与 ShortName，而不是只看 GUI 显示文字：

1
Get-AdfsClaimDescription |
2
    Where-Object {
3
        $_.ShortName -in @('preferred_username','email') -or
4
        $_.ClaimType -in @('preferred_username','email')
5
    } |
6
    Format-List Name,ClaimType,ShortName

内置“电子邮件地址”的 ClaimType 为 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress，ShortName 为 email。用户名需要对应的声明描述：后续实际注册名称为“Gitea OIDC 用户名”、ClaimType 为 urn:gitea、ShortName 为 preferred_username，注册证据见 8.4.2。创建前先查询，已存在则复用，不重复添加或覆盖其他应用定义。声明描述与短名称参数

这一阶段 GUI 中的规则名称为 Gitea-UserProfile，特性存储选择 Active Directory，曾显示如下映射；显示名称不代表后台已经保存了正确的声明类型：

后续后台查询发现用户名类型被保存成了字面文本“Gitea 用户名”，实际修正见 8.4.2。不修改 sub 来凑用户名或邮箱，也不凭下拉框显示文字宣布声明已正确发行。

8.3.4 核对服务端授权与 Gitea 实际请求#

在 FS01 查询此次客户端与资源之间的授权：

1
$clientId = '9567c1a1-940a-4041-8d26-c9c27a2b92e8'
2
Get-AdfsApplicationPermission |
3
    Where-Object {
4
        $_.ClientRoleIdentifier -eq $clientId -and
5
        $_.ServerRoleIdentifier -eq $clientId
6
    } |
7
    Format-List ClientRoleIdentifier,ServerRoleIdentifier,ScopeNames

浏览器开发者工具 → Network，重新从 Gitea 点击 adfs，查看跳转响应的 Location。下面截图中，实际授权请求仍为 response_type=code、scope=openid，未携带自定义 resource，也没有请求 allatclaims。

以上是 2026-10-14 的停点：服务端权限核对通过，Gitea 侧请求适配尚未完成。 后续排查与实验性解决方案见 8.4，不能把这一阶段写成自动建号已通过，也不能将历史停点当作目前仍未解决。

排查只在受控本机查看必要字段，不把令牌、Cookie、客户端密钥上传到公开解码网站或报告中。

8.4.1 先区分“允许自动注册”和“资料声明已收到”#

最初 Gitea 提示自动注册已启用，但缺少 email、preferred_username，转到手工补全账户页面。说明开关已经生效，不代表 AD FS 已返回完整开户资料；此时不手工填写表单来冒充自动建号成功。

在 Gitea 管理员页面编辑 adfs 认证源，将“附加授权范围”加入 allatclaims 并保存。随后实际授权请求出现 scope=allatclaims+openid；加号是空格编码，作用域顺序不是故障原因。

原截图曾显示客户端密钥，公开版本已实心遮挡，未遮挡原图留在仓库外。仍建议在 AD FS 轮换该客户端密钥、同步 Gitea 并撤销旧密钥；本次没有密钥已轮换的验证记录。

allatclaims 的含义是请求把访问令牌中的声明也加入 ID token，不是自动查询所有 AD 属性。认证源中的“全名声明”“SSH 公钥声明”“外部 ID”“必需声明”分别用于资料读取、身份识别或准入检查，不能代替 resource 参数。保持 sub 作为身份标识，不按邮箱自动接管账户。

8.4.2 声明显示名称不等于实际 ClaimType#

在 FS01，以 qy\Administrator 运行后台查询后发现，规则实际保存的是 types=(“Gitea 用户名”, ”…/emailaddress”)；声明描述查询也只有 email。此前仅根据 GUI 中文名称判断配置完成，证据不足。

确认对应声明描述确实不存在后注册：

1
Add-AdfsClaimDescription `
2
    -Name 'Gitea OIDC 用户名' `
3
    -ClaimType 'urn:gitea:preferred_username' `
4
    -ShortName 'preferred_username' `
5
    -IsOffered $true `
6
    -PassThru `
7
    -ErrorAction Stop |
8
    Format-List Name,ClaimType,ShortName

已有同名／同类型定义时先核对，不重复执行；本次成功输出三个字段后才进入规则编辑。

重新打开 AD FS 管理，编辑 Web API 的 Gitea-UserProfile，选择已注册的“Gitea OIDC 用户名”；若使用可编辑类型框，填写实际 URN，而不是中文显示名称。保存后查询：

1
Get-AdfsWebApiApplication |
2
    Where-Object {
3
        $_.Identifier -contains '9567c1a1-940a-4041-8d26-c9c27a2b92e8'
4
    } |
5
    Format-List IssuanceTransformRules

这张修正截图仍使用 sAMAccountName。后续本人将来源调整为 User-Principal-Name（LDAP 属性 userPrincipalName），邮箱继续取 mail，传出声明仍对应 preferred_username／email。改用 UPN 只改变来源值，不会自动解决资源选择或声明未传递；最终 UPN 规则及开户用户名尚无补充截图。

8.4.3 核对的是 FS01，不是 USER01 的补丁#

曾误在 USER01 查询出 Windows 10 LTSB 的补丁；客户端版本不能证明 AD FS 服务器满足条件。回到 FS01 后，完整构建号为 14393.693。微软的自定义 ID token 方案列出 KB4019472，其对应版本为 14393.1198，旧构建尚不满足该更新条件；但补丁不是后续所有问题的唯一原因。方案条件、KB4019472 版本

本次离线更新安排为先安装服务堆栈 KB5126649，再安装累积更新 KB5126868。实际更新后构建号截图为 14393.9612；不据此补写未提供的 SSU 单独安装截图。不同时间复现应重新核对微软的适用版本、前置条件和已知问题，不将这一组包永久当作最新版。SSU 说明、累积更新说明

更新前应备份并安排 FS01 的共享、AD FS、Gitea 中断窗口。本次未确认完成完整目录备份，不补写“备份已完成”。重装程序不能代替恢复数据库、仓库、配置和私钥。

安装时进度条长时间不动，通过下面的只读命令观察后台：

1
Get-Content 'C:\Windows\Logs\CBS\CBS.log' -Tail 15 -Wait

这是提取 CAB、应用差分阶段的内部进度，不等于整个安装完成百分比。Ctrl+C 只结束日志查看；不能仅凭界面停留判断卡死，亦不强制关机。更新完成并重启后核对：

1
hostname
2
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
3
    Select-Object ProductName,CurrentBuild,UBR
4
Get-Service adfssrv
5
Invoke-RestMethod 'https://fs.qy.net/adfs/.well-known/openid-configuration' |
6
    Select-Object issuer,authorization_endpoint,token_endpoint

8.4.4 真正的定位证据：实际访问了默认资源#

Gitea 日志最新失败仍为缺少 email、preferred_username。早些时候另有 could not find a matching session for this request，属于其他请求的会话问题，不能混作同一次声明失败。曾手工追加 resource 做临时测试，但没有取得稳定、完整的请求链路，后续停止重放旧登录／回调地址。

普通 AD FS/Admin 错误／警告查询没有记录，不代表声明已正确发行。因此改用事件查看器：查看 → 显示分析和调试日志 → AD FS Tracing → Debug。只在复现窗口临时启用，USER01 正常登录一次后恢复原日志状态，导出短时间段到本机分析。微软日志说明

1000／1001 可作为声明排查入口，但不只按这两个 ID 筛选。本次 debug.evtx 共 290 条，覆盖 14:10:38～14:12:52，关键证据实际出现在其他事件中：

同一授权请求结合 Activity ID 关联，令牌与 UserInfo 调用再结合紧邻时间和客户端信息追踪，不能假设跨 HTTP 请求的 Activity ID 全部相同。

结论：声明规则已配置，不代表当前请求选择并执行了它。 自定义 Web API 的授权没有消失，而是 Gitea 未携带 resource，落入默认资源。原始 evtx、包含授权码的 Gitea 日志和客户端密钥截图不进入公开仓库；这里只摘录必要文本。

8.4.5 不重编译 Gitea：临时发现文档适配#

曾考虑通过修改 Gitea 源码添加参数，但进一步核对后发现，所用 OAuth 库会保留 authorization_endpoint 原有查询参数。因此“必须重编译”结论过早；本次最终没有替换 gitea.exe，也没有强行启用 form_post。URL 拼接实现

在 FS01 使用本机临时服务，先从真实 AD FS 拉取发现文档，只修改副本：

1. 给 authorization_endpoint 追加 resource=9567c1a1-940a-4041-8d26-c9c27a2b92e8。
2. 保留 issuer、token_endpoint 和 jwks_uri；认证、换令牌仍直接连接 AD FS。
3. 仅监听 127.0.0.1:18080，不开放 USER01 入站，不代理密码或令牌。

首次保留 UserInfo 端点测试后，出现新的 401／MSIS9921：访问令牌的 audience 已是自定义 Web API，而 UserInfo 要求 urn:microsoft。这是资源切换生效后的另一个兼容性问题，不是要求关闭 audience 校验。

Goth 的实现先读取 ID token，再按需查询 UserInfo；发现文档未提供 userinfo_endpoint 时会跳过后者。因此增加显式开关 -SkipUserInfo，只从副本移除该端点，让 Gitea 使用 ID token 中的资料；不关闭 AD FS 的 UserInfo，不伪造邮箱，也不关闭令牌或 TLS 校验。字段读取与可选 UserInfo 实现、跳过条件

下面是本次辅助脚本，保存到 FS01 的 C:\GiteaLab\Start-AdfsResourceDiscovery.ps1。仅适用于本实验名称；端点、issuer 或已有查询参数不符合预期时应停下核对，不移除保护检查。

1
# Lab-only discovery override. Run on FS01 before starting/testing Gitea.
2
# Does not proxy authorization/token/UserInfo requests or disable TLS checks.
3
[CmdletBinding()]
4
param(
5
    [string]$Resource = '9567c1a1-940a-4041-8d26-c9c27a2b92e8',
6
    [int]$Port = 18080,
7
    [switch]$SkipUserInfo
8
)
9

10
$ErrorActionPreference = 'Stop'
11

12
function ConvertTo-ResourceDiscovery {
13
    param(
14
        [Parameter(Mandatory)]$Metadata,
15
        [Parameter(Mandatory)][string]$Resource,
16
        [switch]$SkipUserInfo
17
    )
18

19
    # Work on a copy; preserve issuer, token endpoint, UserInfo and signing keys.
20
    $copy = $Metadata | ConvertTo-Json -Depth 30 | ConvertFrom-Json
21
    if ($copy.issuer -ne 'https://fs.qy.net/adfs') {
22
        throw 'Unexpected issuer. Stop and verify the original discovery document.'
23
    }
24
    foreach ($property in @('authorization_endpoint','token_endpoint','userinfo_endpoint','jwks_uri')) {
25
        $endpoint = [uri]$copy.$property
26
        if (-not $endpoint.IsAbsoluteUri -or $endpoint.Scheme -ne 'https' -or $endpoint.Host -ne 'fs.qy.net') {
27
            throw "Unexpected endpoint: $property. No override has been started."
28
        }
29
    }
30
    $builder = [System.UriBuilder]::new([string]$copy.authorization_endpoint)
31
    if ($builder.Query) {
32
        throw 'Authorization endpoint already has query parameters; review before modifying.'
33
    }
34
    $builder.Query = 'resource=' + [uri]::EscapeDataString($Resource)
35
    $copy.authorization_endpoint = $builder.Uri.AbsoluteUri
36
    if ($SkipUserInfo) {
37
        # Goth skips its optional UserInfo request when this endpoint is absent.
38
        # It must then obtain user details from the ID token; do not fabricate them.
39
        $copy.PSObject.Properties.Remove('userinfo_endpoint')
40
    }
41
    return $copy
42
}
43

44
$metadata = Invoke-RestMethod -Uri 'https://fs.qy.net/adfs/.well-known/openid-configuration'
45
$adapted = ConvertTo-ResourceDiscovery -Metadata $metadata -Resource $Resource -SkipUserInfo:$SkipUserInfo
46
$payload = [Text.Encoding]::UTF8.GetBytes(($adapted | ConvertTo-Json -Depth 30))
47
$listener = [System.Net.HttpListener]::new()
48
$listener.Prefixes.Add("http://127.0.0.1:$Port/")
49

50
try {
51
    $listener.Start()
52
    Write-Host 'Temporary lab discovery service. Leave this window open.'
53
    Write-Host "Discovery URL: http://127.0.0.1:$Port/.well-known/openid-configuration"
54
    Write-Host "Issuer preserved: $($adapted.issuer)"
55
    Write-Host "Authorization endpoint: $($adapted.authorization_endpoint)"
56
    if ($SkipUserInfo) {
57
        Write-Host 'ID-token-only probe: optional UserInfo endpoint omitted.'
58
    } else {
59
        Write-Host 'UserInfo endpoint preserved.'
60
    }
61
    Write-Host 'Ctrl+C stops this helper. No token or TLS validation settings are changed.'
62

63
    while ($listener.IsListening) {
64
        $context = $listener.GetContext()
65
        try {
66
            if ($context.Request.HttpMethod -eq 'GET' -and
67
                $context.Request.Url.AbsolutePath -eq '/.well-known/openid-configuration') {
68
                $context.Response.StatusCode = 200
69
                $context.Response.ContentType = 'application/json; charset=utf-8'
70
                $context.Response.Headers['Cache-Control'] = 'no-store'
71
                $context.Response.ContentLength64 = $payload.Length
72
                $context.Response.OutputStream.Write($payload, 0, $payload.Length)
73
                Write-Host ('{0:HH:mm:ss} Discovery document requested' -f (Get-Date))
74
            } else {
75
                $context.Response.StatusCode = 404
76
            }
77
        } finally {
78
            $context.Response.Close()
79
        }
80
    }
81
} finally {
82
    $listener.Close()
83
}

FS01 管理员打开独立 PowerShell，启动最终实验模式并保持窗口打开：

1
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\GiteaLab\Start-AdfsResourceDiscovery.ps1" -SkipUserInfo

ExecutionPolicy Bypass 仅作用于本次子进程，不要求永久修改执行策略；脚本自身须先审核。Gitea 认证源的发现 URL 临时改为：

1
http://127.0.0.1:18080/.well-known/openid-configuration?mode=idtoken

mode=idtoken 只是区分配置 URL、便于重新加载的标记，不是 Gitea 或 AD FS 内置开关；实际移除 UserInfo 由脚本启动参数 -SkipUserInfo 控制。保存认证源后，在 USER01 新开无痕窗口，正常点击 adfs，不再手动修改地址。若发现 URL 被网络访问策略拦截，先核对该版本的最小允许范围，不关闭全局出站保护。

8.4.6 实际结果、依赖和回退#

本人在最终模式下反馈“已经自动创建账号”。据此记录为本次环境自动建号实操成功反馈；目前没有新增成功页面截图，不伪造截图，也未独立复查数据库。以下仍待补充：新账户原先不存在的证据、实际用户名和邮箱、adfs 关联、再次登录不重复建号。

最终实验链路为：

1
Gitea 读取本机适配发现文档
2
  → 自动携带 resource 跳转到真实 AD FS
3
  → AD FS 完成域认证与令牌发行
4
  → Gitea 直接向真实 token_endpoint 换取令牌
5
  → 不调用不匹配的 UserInfo，读取 ID token 资料
6
  → 自动创建应用账户

保持辅助服务窗口打开。Gitea 可能缓存发现信息，关窗口后当前会话不一定立即失效，但进程重启／认证源重新加载会再次依赖该服务；不能把缓存造成的暂时可用写成已脱离脚本。回退时先将认证源恢复为 https://fs.qy.net/adfs/.well-known/openid-configuration 并保存，再关闭辅助服务；回退会失去本次适配，不保证仍能自动建号。不要删除现有账户、数据库或证书来“恢复”。

本方案仅用于受控实验，不将本机 HTTP 发现文档副本作为已经完成生产安全验收的部署，也不把脚本开机启动等同于生产化。OIDC 发现规范

本次结论只覆盖现有版本与参数组合：标准 OIDC 支持不等于所有产品扩展行为开箱即用；但本次通过发现文档实验适配成功，也不能反过来写成“Gitea 完全不支持自动建号”。