我会这样做，因为在将Ad更新为IDM之后这不会触发任何操作。

在AD更新中（每晚，每小时？），我不仅会删除AD sys-priv/only-priv/其他诸如ACCOUNT之类的东西，而且还会删除所有与AS Java存储库相关的东西。 所有特权都应以{D} {DIRECT_REFERENCE = 1 !! LINKID = 123456}为前缀，这通常是在"源"标签中执行的

查询：

选择s.mcthismskeyvalue作为mskeyvalue，'{D} {DIRECT_REFERENCE = 1 !! LINKID ='+ convert（nvarchar（max），s.mcUniqueID）+'}'+ convert（nvarchar（max），mcOtherMSKEY）privRef
 从idmv_link_ext带有（nolock）
 ...-在这里检测您的用户和系统
 

这将为"源/目标"选项卡组合删除一个priv。 每个用户50个特权，日志中有50个条目需要修改。

如果您拥有Oracle，那么有一个更好的功能，可以在"源"选项卡中一次"分组"所有priv。 但是我已经忘记了这一点

这是一个非常好的解决方案。

正如我在上面对Matt的回答，这差不多是我所做的。 只有我使用javaScript而不是在source选项卡中使用SQL做到了。 从来没有想过这样做（使用SQL），并且将来可能会尝试减少JavaScript的工作时间。

谢谢

克雷格。

嗨克雷格，

简短的答案是，请确保人们不要这样做！ 现在为现实的答案。

我想这一切都取决于系统的设置方式。 您可以尝试强制对帐脏条目。 另一件事可能是更强力的方法，其中您检查idmv_link_ext视图中不存在的MX_PERSON的MSKEY，然后删除分配。 这确实是一种删除脏条目的激进形式。

如果我说的话没有道理或似乎不适用，请提供一些更多信息，屏幕截图，idmv_link_ext中的转储以及示例，等等。

谢谢

马特

根据 Dominik Trui 的评论，

听起来像在正确的轨道上。 祝你好运！

你好，克雷格，

您已经有了一些答案，但我想我也可以提出建议。 我们还将AD用作AS Java的数据源，所以我知道您的问题。

我刚刚向" SetJavaGroupForUser"和" SetJavaRoleForUser"添加了一个脚本作为输入脚本，该脚本检查当前配置的用户是否仍然具有AD帐户，如果没有，则跳过整个AS Java的配置。 这样，IDM中的特权就被删除了，等等，一切都变得井井有条。

在我们的系统中工作正常。 ^^

。

此致

Steffi。