? ? ? 最近被 Dynamics CRM 的權(quán)限配置問題惡心了一個星期，老是報“Access Is Denied”，幾經(jīng)波折，最后終于找到一個比較合適的解決方案，寫個博客 mark 下來，方便以后查看。

首先，介紹一下權(quán)限設(shè)置的要求：

? ? ? 1.在根 Business Unit 下建立好 Security Role，并根據(jù)文檔要求賦予 Sense Role 相關(guān) Entity 及 CRM 系統(tǒng)的操作權(quán)限；

? ? ? 2.建立多個 Team，每個 Team 都有各自的權(quán)限配置，給 Team Role 賦予不同的 Security Role；

? ? ? 3.創(chuàng)建 User，但是不給 User Role 賦 Security Role，而是直接將 User 加到 Team 中，這樣 User 也可以得到與 Team 相同的權(quán)限（但這個并不是User本身擁有的權(quán)限）。

?

然后，我來描述一下 Bug 是怎么產(chǎn)生的：

? ? ? 當(dāng)我按照需求設(shè)置好 Security Role 的各種權(quán)限并添加完 Team 和 User 后，開始使用這些 User 在 CRM 系統(tǒng)上進(jìn)行測試，當(dāng)我測試完某個 Entity 的 BPF（Business Process Flow），返回到列表視圖后，再次雙擊 Record 想進(jìn)來再查看的時候，開始報錯，如下圖所示：

圖1 Access Is Denied

?

? ? ? Acess Is Denied？ 此時的我？？？Ok，這條 Record 進(jìn)不去，那我換一條，雙擊，Access Is Denied。嗯？？？Ok，那我直接 New 一條 Record，Access Is Denied……

?

接下來，講一下我艱難的排 BUG 過程：

? ? ? 既然發(fā)現(xiàn)了 Bug ，那么先來找找 Bug 是怎么被觸發(fā)的。

? ? ? Download Log File，從文件里可以得到以下的一段信息：

<Message> SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: f7014009-b409-e911-943a-00155d16b40a, OwnerId: c062acbd-fcfc-e811-943a-00155d16b40a, OwnerIdType: 8 and CallingUser: c062acbd-fcfc-e811-943a-00155d16b40a. ObjectTypeCode: 2500, objectBusinessUnitId: 9cfbf85c-3e0f-e911-8b87-e0aa182461d5, AccessRights: WriteAccess </Message>

? ? ? 第一眼看到 WriteAccess，我以為是 Security Role 沒有設(shè)置好，檢查了一下，設(shè)置沒有問題，而且 Read 的權(quán)限也在正常運(yùn)作，因?yàn)榭梢钥吹?Active View 里所有的 Record。接著在屏蔽了 JS 以及 Plugin 代碼后，重新添加新的 system user 后，執(zhí)行一步 BPF：OK，不出所料報了 Acess Is Denied 的錯誤，通過測試驗(yàn)證了這個 bug 跟 JS 以及 Plugin 代碼無關(guān)，剩下就是要找出權(quán)限設(shè)置哪里出了差錯。

?

現(xiàn)在，就講一下這類bug要如何修復(fù)：

? ? ? 1.首先從下載下來的 log 中可以看到，ObjectTypeCode：2500，對 CRM 數(shù)據(jù)庫新建查詢，執(zhí)行以下查詢語句：

SELECT * from EntityView ORDER BY ObjectTypeCode

? ? ? ?可以得到一個列表，并且可以在列表中查詢到 ObjectTypeCode：2500 對應(yīng)的 Entity Name 為 UserEntityUISettings。

圖2 數(shù)據(jù)庫查詢結(jié)果?

?

? ? ? 2.在設(shè)置權(quán)限的時候我們可以看到這個 UserEntityUISettings 就在 Security Role -> Core Records -> User Entity UI Settings：

圖3 Security Role 設(shè)置

?

? ? ? 根據(jù) log 上報缺少 Write 權(quán)限，那么我們在 Security Role 里面將整行權(quán)限全部點(diǎn)上（這里的設(shè)置也只能點(diǎn)一下，賦予了 User 級別的權(quán)限），然后使用 User 重新打開剛剛 Access Is Denied 的 Record：發(fā)現(xiàn)還是打不開，還是報了 Acess Is Denied ，還是報了 ObjectTypeCode：2500 的錯誤。

? ? ? 猜想：難道是 Team Role 的權(quán)限不能被帶到 User Role 那邊？于是在 System User 的 User Role 里勾上了這個 Security Role，再次使用 User 打開 Record，驚喜，所有的操作都可以正常執(zhí)行，不再報 Acess Is Denied 的錯誤了（此刻內(nèi)心簡直思緒萬千）。然而，bug 雖然解決了，但這個方式顯然是不行的，因?yàn)槿绻?User Role 里勾選上與 Team Role 一樣的 Security Role 的話，那么通過將 User 加到 Team 里來獲得權(quán)限這一點(diǎn)就已經(jīng)失去了意義（除去 ownerid 為 Team 的情況），因?yàn)榇藭r User 自身已經(jīng)擁有與 Team 相同的權(quán)限。

? ? ? 為了符合通過將 User 加入 Team 來獲取權(quán)限這一需求，可以使用以下方法：

1 新建一個叫做 UI 的 Security Role，在這個 Security Role 只賦予它 User Entity UI Setttings 的權(quán)限； 2 其他 Security Role 不賦予 User Entity UI Settings 權(quán)限，并且這些 Security Role 只供 Team Role 使用； 3 每個 System User 的 User Role 都使用 UI Security Role，不必勾選其他 Security Role。

?

Note：

? ? ? 這里再提一個奇怪的修復(fù)方法，也算是一個隱藏 bug，就是當(dāng)你在 system user 的 User Role 那邊勾選了一個具有 UserEntityUISettings 的 Security Role，并使用這個 user 去訪問了之前無權(quán)限訪問的 Record 后，這個時候我們再將 User Role 上勾選的 Security Role 取消，再去訪問那些 Record，你可以發(fā)現(xiàn)都變成有權(quán)限訪問了……沒錯，它就是如此的神奇，可能是存在“緩存”，或者勾選了之后會在數(shù)據(jù)庫某張權(quán)限表上加了一條代表某種關(guān)系的記錄，取消勾選又不會移除該條關(guān)系，關(guān)于具體原因我并沒有深入探究，也不建議通過這種方式來修復(fù)這個 bug，因?yàn)楫?dāng)你新加了 Entity 實(shí)體后又會再次出現(xiàn)同樣的錯誤，因?yàn)槟阒安]有訪問過。

?

總結(jié)：

? ? ? 最后總結(jié)一下，當(dāng)出現(xiàn)“Acess Is Denied”相關(guān)的錯誤時，可以通過下載 log 文件，根據(jù)文件提示的?ObjectTypeCode 代碼及其他相關(guān)的日志信息，在數(shù)據(jù)庫中查詢出相對應(yīng)的 Entity Name，再具體修復(fù)該 bug。

?

參考：https://nishantrana.me/2018/05/15/seclibaccesscheckex-failed-objecttypecode-2500-accessrights-writeaccess-error-on-user-entity-ui-settings-in-dynamics-365/

轉(zhuǎn)載于:https://www.cnblogs.com/Sunny20181123/p/10283351.html

總結(jié)

以上是生活随笔為你收集整理的Dynamics CRM - 如何修复 Access Is Denied，ObjectTypeCode: 2500 的错误的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。