给同事开了本地管理员权限，策略却在"分配"这一步悄悄卡住了

子公司一位同事的电脑上，两款业务软件（一款社保申报客户端、一款银行侧的协作工具）每次登录都要求输入一次管理员密码——不是安装失败，是这两款软件本身的设计就要求以管理员身份运行。频率不低，几乎每月都要用好几次，每次都得远程连过去敲一遍密码，对双方都是消耗。

第一反应是”重装试试”：卸载重装、Windows 更新完重启，登录界面照样弹出权限提示。到这一步应该确认一件事——这类反复出现、且换了个”版本”或”重启”都不解决的权限提示，大概率从来不是安装问题，而是这台电脑上这个账号本来就没有本地管理员权限。原生地在电脑上手动把用户加进本地管理员组也不是选项——设备由 Intune 托管，本地手改的组成员身份要么被托管策略定期纠正回去，要么干脆没有权限动。

用已有模板起步：按人建组、按组授权

公司对这类”某个人需要本地管理员权限”的诉求，已经有一套跑通的模式，是照着一位高管既有的策略抄的：不要把权限直接挂在具体某个用户对象上，而是新建一个只包含这一个人的 Azure AD 安全组，再用 Intune 的”本地用户组成员身份（Local user group membership）“策略把这个组指派为本地管理员。好处很直接：以后要收回权限，删组或者清空组成员就够了，不需要再回头找这条策略改配置；权限边界也一目了然——策略名字本身就写着是谁的。

照这个模式：先建一个只包含这位同事的安全组，再在 Intune 的 Endpoint Security → Account Protection 里新建一份 Local user group membership 类型的策略，套用同样的命名规则。

分配页面卡住：“未找到任何组”

配置走到最后一步——Assignments（分配）——搜索框里怎么敲都是空的：“No groups found”。

原因很简单但容易忽略：刚创建的安全组需要一点时间在目录里落地/被检索到，而策略向导的分配页面是实时搜索现有对象的——组刚建完立刻切到策略向导，两者之间没有对上时机。解法是退回去，确认组已经在 Groups 列表里能正常搜到（必要时刷新几次），再回到策略的 Assignments 页面重新搜索并勾选。

这一步很容易被跳过而不自知：策略向导允许你在 Assignments 为空的情况下继续点 Next 直到 Review + create，策略本身依然能创建成功，只是没有被分配给任何人——它存在，但对谁都不生效。回头看当时的记录，正是这个空档导致第一次尝试完全没有效果，得回去补上分配、再等一轮 Intune 的 MDM 同步周期，策略才真正推送到设备上。

策略”创建成功”和策略”生效”之间，隔着一个容易被跳过不自知的分配步骤

底层其实就是一条命令

同一批记录里留了一行简单的验证命令，把这套图形界面操作的本质说得很清楚：

net localgroup administrators AzureAD\<user-principal-name> /add

Intune 的”本地用户组成员身份”策略，本质上就是在托管设备上代为执行这类 net localgroup 命令，把云端组的成员身份映射成本机本地组的成员身份——理解了这一层，遇到”策略应用了但本地组里看不到人”这类问题时，就知道该往哪个方向排查：策略同步状态、组成员是否落地、还是本地组本身被其他策略覆盖。

教训

1. 软件反复要求管理员密码，且换了个版本或重启都不解决，先怀疑权限而不是安装本身——这类问题的正确排查顺序是”这个账号在这台设备上到底有没有管理员权限”，而不是继续在重装上打转；
2. 按人建专属安全组、再把组指派为本地管理员，比直接把用户挂到通用管理员策略上更干净——收权限时删组即可，策略名字本身也是最好的权限台账；
3. Intune 策略向导允许你在 Assignments 为空的情况下一路点到创建完成——“策略已创建”不等于”策略已生效”，走到 Assignments 页面时确认真的搜到了目标组、真的勾选上了；
4. 新建的 Azure AD 组不一定立刻能在别的向导里被搜到——如果分配页面显示”未找到任何组”，先去确认组本身是否已经存在且可检索，而不是怀疑向导本身有问题。