问题描述
执行Get auth token命令时，使用管理员与操作员获取到的token值是一致的
重现步骤
-
redfish/v1/Managers/1/SecurityService设置IPMBAccessRole和SMSAccessRole为Administrator
-
busctl --user introspect bmc.kepler.ipmi_core /bmc/kepler/IpmiCore时
ChannelAccess 为Administrator
-
执行ipmitool raw 0x30 0x94 0xdb 0x07 0x00 0x39 0x04 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0 0x00 0x00 0x00 0x00 0x00 （管理员权限）
-
ipmitool raw 0x30 0x94 0xdb 0x07 0x00 0x39 0x03 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0 0x00 0x00 0x00 0x00 0x00（操作员权限）
-
查询token结果
期望结果
获得的token值不一致
实际结果
使用管理员与操作员获取到的token值是一致的
尝试过的解决方案
之前的帖子：执行Get auth token命令时，使用管理员与操作员获取到的token值是一致的 - 交流互助区 - openUBMC 论坛
现在查看发下疑似未生效
分析结论
[详细总结您对此问题的分析结论]
答案内容由AI生成，仅供参考：
根据您提供的回答内容，其中明确标有“结论”章节，具体内容如下：
结论
这是 openUBMC 的设计行为：Get Auth Token 命令在带内（IPMI/Redfish）身份验证场景下，最高只能发放 操作员级别 的令牌。即使请求中携带管理员角色 ID，也会被降级为操作员，故管理员与操作员获取的 token 值完全相同。
点击此处查看详细分析解答
根据您提供的复现步骤以及知识库中的相关信息，执行 Get Auth Token 命令时使用管理员与操作员获取到的 token 值一致，这是由该命令本身的设计与权限映射机制决定的，并非异常现象。
原因分析
-
命令中角色 ID 的映射规则
在 openUBMC 的 Get Auth Token 命令请求结构中，第 5 字节用于指定角色组 ID（Role ID），其定义如下（来自官方命令文档）：
| 值 |
含义 |
| 2 |
普通用户 |
| 3 |
操作员 |
| 4 |
操作员（带内身份验证令牌最高为操作员） |
关键点：角色 ID 4 在命令文档中明确标注为“操作员（带内身份验证令牌最高为操作员）”，并未定义真正的“管理员”角色 ID。这意味着即使客户端传入 ID 4，系统实际发放的令牌仍是操作员级别的权限。
-
您使用的实际请求
- 步3中使用了
0x39 0x04 0x01 ...（Role ID = 4）
- 步4中使用了
0x39 0x03 0x01 ...（Role ID = 3）
根据映射规则，两者最终都对应操作员角色，因此返回的 token 值自然一致。
-
通道访问角色设置的影响
您通过 SecurityService 设置了 IPMBAccessRole 和 SMSAccessRole 为 Administrator，这仅控制了IPMI 通道的最小权限要求，但并未改变 Get Auth Token 命令本身对角色 ID 的解析逻辑。该命令严格遵循上述固定映射，不会因通道访问角色提升而发放管理员级别的 token。
-
历史讨论的佐证
- 用户
kunlun_jiaoxinchao 曾在论坛提出相同疑问。
- 社区专家
LiJiang 建议使用管理员权限执行该命令，但经过实际测试（如您当前所再现）仍得到一致 token，进一步说明命令本身不支持发放管理员级 token。
结论
这是 openUBMC 的设计行为：Get Auth Token 命令在带内（IPMI/Redfish）身份验证场景下，最高只能发放 操作员级别 的令牌。即使请求中携带管理员角色 ID，也会被降级为操作员，故管理员与操作员获取的 token 值完全相同。
建议
- 若需实现严格的角色隔离，应使用**外部 API 层面（如 Redfish Session 创建）**进行权限控制，而非依赖
Get Auth Token 命令。
- 可关注后续 openUBMC 版本是否引入更细粒度的令牌角色映射。
Larry_Li
(LiJiang)
3
