兄弟们，有没有遇到过这种灵异事件？你给某个重要的用户账号（比如某个应用的服務帳號）在某个OU上配了个特殊权限，信誓旦旦地跟业务部门说“搞定了，放心用吧！”结果一小时后，业务部门的夺命连环call就来了：“不行啊！还是没权限啊！你到底行不行啊，细狗！”你当时就一脸懵逼，赶紧远程上去一看，我勒个去，刚刚配的权限竟然不翼而飞了！就像被什么神秘力量给偷偷删掉了一样。你揉揉眼睛，再三确认不是自己眼花，然后又配了一遍。结果呢？一个小时后，历史重演，权限再次消失。这时候你是不是开始怀疑人生了？是不是觉得公司服务器机柜里住了个调皮的“权限鬼”，就喜欢跟你对着干？
别慌，今天咱们就来当一回“捉鬼大师”，把这个藏在Windows活动目录（Active Directory）深处的“小调皮”给揪出来。这个神秘力量，它的核心代号之一，就跟咱们今天标题里的“ADMINC”有点关系。其实，这背后搞鬼的不是什么灵异现象，而是一个叫“AdminSDHolder”的机制，以及它忠实的打手——一个名为SDProp（Security Descriptor Propagator）的进程。
来，坐好小板凳，老司机要发车了。在AD这个庞大的世界里，为了保护那些拥有至高无上权力的管理员账户，微软设计了一套堪称“铁桶阵”的安保系统。它认为，像Domain Admins、Enterprise Admins、Schema Admins、Administrators这些“天龙人”级别的用户组，它们的成员账户都得享受最高级别的保护，不能让你随随便便在他们身上动手动脚，改来改去。万一哪个愣头青管理员不小心给域管账户删了个重要权限，那整个域可能就直接原地爆炸，大家一起卷铺盖回家了。
所以，微软就搞了个“模板”。这个模板就是大名鼎鼎的AdminSDHolder对象，它静静地躺在你的域的System容器里。你可以把它想象成一张“管理员标准权限配置单”，上面清清楚楚地写着，所有受保护的管理员账户应该拥有哪些权限，一丁点都不能多，一丁点都不能少。这张单子本身是可以修改的，但改它就等于修改了所有受保护对象的“出厂设置”，属于高危操作，一般人咱不建议碰哈。
那么，系统是怎么知道哪些账户是需要被“保护”的“天龙人”呢？这里就引出了一个关键属性——adminCount。当一个用户账户被直接或间接地加入到任何一个受保护的用户组（比如你把张三加入了Domain Admins组）时，系统会立刻在这个用户的AD对象属性里，找到一个叫`adminCount`的属性，然后“啪”地一下，把它的值从0或者“未设置”改成1。这个`adminCount=1`就像是在这个账户脑门上盖了个戳，上面写着：“重点保护对象，闲人勿扰！”
有了“模板”（AdminSDHolder），也有了“标记”（adminCount=1），接下来就该“执行者”——SDProp进程登场了。这个SDProp进程就像一个强迫症晚期的保安大队长，默认情况下，它每隔60分钟就会在域控上醒来一次，然后开始巡逻。它的任务很简单：遍历整个AD数据库，检查每一个用户、组对象的`adminCount`属性。一旦发现哪个对象的`adminCount`是1，它就会二话不说，直接掏出AdminSDHolder那个“标准权限配置单”，强制性地覆盖到这个对象的安全描述符（ACLs）上。同时，它还会非常“贴心”地帮你把这个对象的“权限继承”给禁用掉。这意味着，你之前在这个对象上配的任何自定义权限，或者从父OU继承来的权限，通通都会被洗得一干二净，强制恢复成“出厂设置”。
这就是为什么你给那个服务账号配的权限会定时消失的根本原因！很可能在某个时间点，为了方便操作，你或者你的前同事，曾经把这个账号短暂地加入过Domain Admins之类的受保护组里。虽然你后来可能很快就把它移出来了，但那个`adminCount=1`的“金印”却永远地烙在了它身上！系统可不管你现在是不是管理员，它只认戳。只要戳还在，SDProp大队长每小时的“拨乱反正”就不会停止。你的每次手动配置，在它眼里都是“违章建筑”，必须定时强拆。
破案了，兄弟们！是不是有种恍然大悟的感觉？这个锅，咱不能让“权限鬼”背，得让AdminSDHolder和SDProp这对“黄金搭档”来背。那么问题来了，知道了真凶，我们该如何“拨乱反正”的“拨乱反正”呢？其实方法也挺简单，分两步走，一步都不能少！
第一步，手动“摘戳”。你需要找到那个被折磨的账户，打开它的属性编辑器（需要在“Active Directory用户和计算机”中开启“高级功能”视图才能看到），找到`adminCount`这个属性，手动把它从1改成0，或者直接清除掉。这就相当于告诉SDProp大队长：“报告长官，这个人已经不是保护对象了，您可以高抬贵手了！”
第二步，恢复“继承权”。光摘戳还不够，因为之前SDProp已经把它的权限继承给禁用了。你得右键这个账户，选择“属性”，切换到“安全”选项卡，点击下方的“高级”按钮，然后在弹出的窗口里，点击“启用继承”按钮。这样一来，它才能重新从它所在的OU那里继承该有的权限，你给它配置的特殊权限也才能稳固地待在原地，不会再被无情地擦除。
搞定这些繁琐的操作后，是不是觉得身心俱疲？还不如去放松一下，话说回来，玩游戏想要赚零花钱就上七评赏金榜，网站地址：bbs.77.ink，搞点副业不香吗？咳咳，扯远了。总之，经过这两步操作，那个烦人的“权限鬼”就算是彻底被你驱散了。下次再有业务部门打电话，你就可以理直气壮地告诉他：“放心，这次稳了，再丢权限我把键盘吃了！”
这个机制虽然有时候会给咱们管理员带来点头秃的烦恼，但从安全角度来说，它确实是AD一道至关重要的防线。它确保了核心管理账户的权限纯洁性，防止了因误操作或恶意攻击导致的高权限账户权限被篡改。所以，我们在解决问题的同时，也要理解微软设计这套机制的良苦用心。不过，对于那些曾经是管理员，现在已经“退位”的账户，这个`adminCount`属性不会自动清零的“粘性”设计，确实是个不大不小的坑，需要我们手动去填平。
所以，当你下次再遇到类似的“灵异事件”，不要慌张，先去查查这个用户的`adminCount`是不是1，再看看它的安全继承是不是被禁用了，十有八九，问题就出在这里。现在你已经掌握了这项“捉鬼”技能，是不是感觉自己的技术又牛批了一点？以后在同事面前，你就可以轻描淡写地说：“哦，小场面，又是AdminSDHolder在刷存在感罢了。”这逼格，瞬间就拉满了，对吧？
那么，你有没有想过，这个作为“权限模板”的AdminSDHolder对象，它自身的权限又是谁来设置和保护的呢？
