6.4 透過 iManager 以 XML 格式寫入授權

為協助您更加瞭解授權的相關內容，可在其中一個預先設定組態的驅動程式 (即已啟用授權的 Active Directory (AD)) 中查看授權和規則。 這包含檢查 Novell 的授權文件類型定義 (Document Type Definition，DTD)，然後查看根據 DTD 寫入授權的 XML 範例。

本節內容：

6.4.1 Active Directory 驅動程式在授權啟用時新增的內容

已啟用授權的 AD 驅動程式包含下列結構變更：

  • 將 DirXML-EntitlementRef 屬性新增至驅動程式過濾器。 DirXML-EntitlementRef 屬性可讓驅動程式過濾器監聽授權活動。
  • 建立使用者帳戶授權。 「使用者帳戶」授權會針對使用者授予或撤銷 Active Directory 中的帳戶。 當授予帳戶時，使用者會得到已啟用的登入帳戶。 當撤銷帳戶時，視驅動程式組態設定方式停用或刪除登入帳戶。
  • 建立群組成員資格授權。 「群組授權」會授予或撤銷 Active Directory 中群組的成員資格。 該群組必須與 Identity Vault 中的群組相關聯。 當撤銷成員資格時，會從群組中移除使用者。 群組成員資格授權不是在「發行者」通道上強制執行的。如果透過某些外部工具將使用者新增至 Active Directory 中的控制群組，驅動程式就不會移除該使用者。 此外，如果從使用者物件移除授權，而不是只撤銷授權，則 AD 驅動程式不會採取任何動作。
  • 建立 Exchange 信箱授權。 「群組授權」會在 Microsoft Exchange 中授予或撤銷使用者的 Exchange 信箱。
  • 將授權資訊新增至許多規則。

下列規則 (Policy) 包含可使授權正常運作的其他規則 (Rule)：

  • InputTransform (驅動程式層級)。 此規則 (Policy) 中的「檢查群組成員資格授權之新增關聯的目標」規則 (Rule) 會檢查用於群組成員資格授權之「新增關聯」的目標。 除非該使用者已成功建立，否則無法處理指定給正在 Active Directory 中建立之使用者的群組成員資格授權。 新增關聯表示，Active Directory 中的驅動程式已經建立物件。 如果該物件也標示為群組授權處理，它就會立即執行工作。
  • 事件轉換 (「發行者」通道)。 此規則 (Policy) 中的「不允許使用者帳戶刪除」規則 (Rule) 不允許使用者在 Identity Vault 中刪除使用者帳戶。 當使用「使用者帳戶授權」時，受管理的使用者帳戶由 Identity Vault 中的授權來控制。 Active Directory 中的刪除不會刪除 Identity Vault 中的控制物件。 對 Identity Vault 中物件的未來變更或合併操作可能會重新建立 Active Directory 中的帳戶。
  • 指令 (「訂閱者」通道)。 「指令」規則 (Policy) 包含有關授權的下列規則 (Rule)：
    • 「使用者帳戶授權變更 (刪除選項)」規則。 「使用者帳戶授權」會授予使用者已啟用的 Active Directory 帳戶。 根據您為「當撤銷帳戶授權時」全域變數所選取的值而定，撤銷授權會停用或刪除 Active Directory 帳戶。 當授權變更且您已選取「刪除」選項時，會執行此規則。
    • 「使用者帳戶授權變更 (停用選項)」規則。 「使用者帳戶授權」會授予使用者已啟用的 Active Directory 帳戶。 根據您為「當撤銷帳戶授權時」全域變數所選取的值而定，撤銷授權會停用或刪除 Active Directory 帳戶。 當授權變更且您已選取「停用」選項時，會執行此規則。
    • 「檢查要授予或撤銷之群組成員資格的使用者修改」規則。
    • 「檢查要授予或撤銷之 Exchange 信箱的使用者修改」規則。
  • 相符 (「訂閱者」通道)。 這是「帳戶授權」： 此規則 (Policy) 的「不符合現有帳戶」規則 (Rule)。 當搭配使用「使用者帳戶」授權與 Identity Manager 使用者應用程式或「角色授權」時，帳戶是透過授予或撤銷授權來建立和刪除 (或停用)。 如果使用者沒有 Active Directory 中帳戶的授權，則預設規則會與 Active Directory 中的現有帳戶不相符。 如果您想要將授權規則套用至 Active Directory 中的相符帳戶，請修改或移除此規則。 這可能會導致刪除或停用 Active Directory 帳戶。
  • 建立 (「訂閱者」通道)。 「建立」規則 (Policy) 包含有關授權的下列規則 (Rule)：
    • 帳戶授權： 未授予授權時封鎖帳戶建立。 當搭配使用「使用者帳戶」授權與 Identity Manager 使用者應用程式或「角色授權」時，僅會針對專門授予帳戶授權的使用者建立帳戶。 在未授予授權時，此規則會否決使用者帳戶的建立。
    • 如果停用的帳戶不存在，則啟用 Identity Vault 帳戶。
    • 準備在新增之後檢查群組授權。 因為新增的物件必須存在以新增至群組，所以會在新增完成之後處理群組授權。 當新增處理完成時，會以輸入轉換中核取的操作內容來對新增設旗標。
    • 發出在新增之後檢查 Exchange 授權的需求。
    • 將使用者名稱映射至 Windows 登入名稱。在設定 userPrincipalName 組態以遵循 eDirectory 使用者名稱時，請將 userPrincipalName 設為 eDirectory 物件名稱加上 Active Directory 領域的名稱。

藉由在 iManager 中執行下列步驟，您可以查看每個規則實際的 XML 碼：

  1. 選取「Identity Manager」>「Identity Manager 概觀」。
  2. 瀏覽至驅動程式所在的驅動程式集，然後按一下「搜尋」。
  3. 在「Identity Manager 概觀」頁上，從呈現的「驅動程式集」中選取「驅動程式」物件。
    選取驅動程式
  4. 從「驅動程式集」連按兩下驅動程式，以載上驅動程式頁面。 按一下驅動程式中心 (以紅色線圈住) 的「檢視所有規則」圖示。
    選取檢視所有規則
  5. 從「顯示所有規則」螢幕中選取規則之後，您可以檢視組成規則的條件和動作。
    檢視規則
  6. 若要檢視規則後面實際的 XML 碼，請從下拉式功能表 (此功能表預設為「Identity Manager 規則」) 中選取「編輯 XML」。 如需建立和編輯規則的相關資訊，請參閱《規則產生器和驅動程式自訂指南》，以及選定的《Identity Manager 驅動程式指南》，以建立該驅動程式特定的規則。
  7. 若要檢視已啟用授權之預先設定驅動程式 (我們的範例是 Active Directory) 附帶的授權，請遵循步驟 1 至步驟 4。但是，請選取驅動程式中心 (以紅色線圈住) 的「檢視所有授權」圖示。
    檢視所有授權
  8. 在「管理授權」頁上，按一下授權名稱以在 XML 檢視器中載上授權。 若要編輯授權的代碼，請按一下「啟用 XML 編輯」。

已啟用授權的 Active Directory 驅動程式附帶三種授權： 「使用者帳戶」、「群組」和「Exchange 郵件」。

圖 6-1 AD 驅動程式附帶的授權

您可以查看這些授權的 XML 碼，做為節 6.4.6, 協助您建立自己授權的範例授權中書面範例的一部份。

6.4.2 使用 Novell 的授權文件類型定義 (DTD)

部份授權在已啟用授權的驅動程式上預先定義。 您可以使用這些授權，或者可以在 iManager 或 Designer 中建立自己的授權。 使用下列 Novell 的授權文件類型定義 (DTD) 做為建立授權的範例，可以協助您建立自己的授權。

此文件類型定義 (DTD) 說明之後是四個範例，說明如何透過 iManager 使用此 XML 格式寫入授權。 如果您不想要擔心 XML 格式的相關問題，請使用 Designer 的「授權精靈」以一種更簡單的方式建立授權。

Novell 的授權文件類型定義 (DTD)

<!-*****************************************************************-> <!-- DirXML Entitlements DTD <!-- Novell Inc. <!-- 1800 South Novell Place <!-- Provo, UT 84606-6194 <!-- Version=1.0.0 <!-- Copyright 2005 Novell, Inc. All rights reserved --> <!--************************************************************* --> <!-- Entitlement definition stored in the XmlData attribute of a DirXML-Entitlement object. --> <!ELEMENT entitlement (values?)> <!ATTLIST entitlement conflict-resolution (priority | union) "priority" display-name CDATA #REQUIRED description CDATA #REQUIRED > <!ELEMENT values (query-app | value+)?> <!ATTLIST values multi-valued (true | false) "true" > <!ELEMENT value (#PCDATA)> <!ELEMENT query-app (query-xml, result-set)> <!ELEMENT query-xml ANY> <!ELEMENT result-set (display-name, description, ent-value)> <!ELEMENT display-name(token-attr | token-src-dn | token-association)> <!ELEMENT ent-value (token-association | token-src-dn | token-attr)> <!ELEMENT description (token-association | token-src-dn | token-attr)> <!ELEMENT token-association EMPTY> <!ELEMENT token-attr EMPTY> <!ATTLIST token-attr attr-name CDATA #REQUIRED > <!ELEMENT token-src-dn EMPTY> <!-- Entitlement reference stored in the DirXML-EntitlementRef attribute 	of a DirXML-EntitlementRecipient or a DirXML-SharedProfile object. --> <!ELEMENT ref (src?, id?, param?)> <!ELEMENT param (#PCDATA)> <!ELEMENT id (#PCDATA)> <!ELEMENT src (#PCDATA)> <!-- Entitlement result stored in the DirXML-EntitlementResult attribute of a DirXML-EntitlementRecipient object. --> <!ELEMENT result(dn, src, id?, param?, state, status, msg?,timestamp)> <!ELEMENT dn (#PCDATA)> <!ELEMENT state (#PCDATA)> <!ELEMENT status (#PCDATA)> <!ELEMENT msg ANY> <!ELEMENT timestamp (#PCDATA)> <!-- Cached query results stored in the DirXML-SPCachedQuery attribute of a DirXML-Entitlement object. --> <!ELEMENT items (item*)> <!ELEMENT item (item-display-name?, item-description?, item-value)> <!ELEMENT item-display-name (#PCDATA)> <!ELEMENT item-description (#PCDATA)> <!ELEMENT item-value (#PCDATA)> <!-- Representation of a DirXML-EntitlementRef within the DirXML Script and within the operation-data of an operation in an XDS document. --> <!ELEMENT entitlement-impl (#PCDATA)> <!ATTLIST entitlement-impl name CDATA #REQUIRED src CDATA #REQUIRED id CDATA #IMPLIED state (0 | 1) #REQUIRED src-dn CDATA #REQUIRED src-entry-id CDATA #IMPLIED >

6.4.3 授權文件類型定義 (DTD) 說明

授權文件類型定義 (DTD) 分為五個部份： 定義、參考、結果、快取查詢和內部參考資訊。 標題僅是備註，且是選擇性的。 在文件類型定義 (DTD) 中，「授權定義」的標題是：

<!-- Entitlement definition stored in the XmlData attribute of a DirXML-Entitlement object. -->

標題後面是「元素 (ELEMENT)」和「屬性清單 (ATTLIST)」。 以下是位於「授權定義」標題下面之元素和屬性的詳細說明。「授權定義」標題是您在建立授權時要特別注意的主要標題。

<!ELEMENT entitlement (values?)>

根層級元素是 <entitlement>，其可以包含單一、選擇性的子 <values> 元素。 後面是「屬性」清單包含 conflict-resolution、display-name 和 description。 衝突解析使用 Priority 或 Union 屬性值。

conflict-resolution (priority | union) "priority"

「角色授權」使用衝突解析來決定當多次將具值授權套用至相同的物件時，應該會發生的情況。 例如，假設使用者 U 是「授權規則 A」和「授權規則 B」的成員，兩個規則都參考相同的具值授權 E，但是具有不同的值集。 「授權規則 A」的授權 E 具有值 (a、b、c)。 「授權規則 B」的授權 E 具有值集 (c、d、e)。

衝突解析屬性決定使用者 U 應該套用的值集。如果設為 union，則會將兩個值集 (a、b、c、d、e) 都指定給使用者 U。 如果設為 priority，則根據優先程度較高的「授權規則」而定，使用者 U 僅會取得一個值集。

因為值的集合會導致套用多個值，所以如果授權是單一值，則必須依 priority 解析衝突。 目前，「角色授權」使用此屬性，而在以後，「工作流程授權」可能也會使用該屬性。

display-name CDATA #REQUIRED description CDATA #REQUIRED

授權不一定會顯示文字授權名稱。 Display-name 和 Description 屬性用於一般使用者顯示 (在 Designer 中，您可以選擇授權的顯示名稱，而不需要使用實際的授權名稱)。

<!ELEMENT values (query-app | value+)?> <!ATTLIST values multi-valued (true | false) "true"

<values> 元素是選擇性的，表示是具值授權。 如果您不使用此元素，則表示是無值授權。 具值授權的範例是會授予配送清單的授權。 無值授權的範例是在應用程式中授予帳戶的授權，例如 Active Directory 驅動程式附帶的「使用者帳戶」授權。

具值授權從三個來源接收值。 一個來源是外部應用程式 (由 <query-app> 元素指定)。. 另一個來源是列舉值預先定義的清單 (一或多個 <value> 元素)。 第三個來源是授權用戶端 (不具有 <value> 子代的 <values> 元素)。 這些範例對於說明值的工作方式而言很有用。

具值授權可以是單一值的或多值的，預設值是多值的。 強制執行此限制是授權用戶端的職責。

<!ELEMENT value (#PCDATA)>

授權值是不具類型的字串。

<!ELEMENT query-app (query-xml, result-set)>

如果值來自外部應用程式 (例如，電子郵件配送清單)，則您必須透過 < query-xml> 元素指定應用程式查詢。 並透過 <result-set> 元素從查詢中擷取結果。 我們在範例 2： 應用程式查詢授權： 外部查詢中顯示了兩個範例。

<!ELEMENT query-xml ANY>

XML 查詢是 XDS 格式的。 <query-xml> 指令用於從已連接的應用程式中尋找和讀取物件。 DirXML 規則、物件移轉等功能根據驅動程式對查詢指令實作的結果而定。 如需 XML 查詢的相關資訊，請參閱 Novell 關於查詢的開發人員文件。

<!ELEMENT result-set (display-name, description, ent-value)> <!ELEMENT display-name(token-attr | token-src-dn | token-association)> <!ELEMENT ent-value (token-association | token-src-dn | token-attr)> <!ELEMENT description (token-association | token-src-dn | token-attr)> <!ELEMENT token-association EMPTY> <!ELEMENT token-attr EMPTY> <!ATTLIST token-attr attr-name CDATA #REQUIRED

使用結果集元素，可以協助您解譯外部應用程式查詢的結果。 相關資料有三種： 值的顯示名稱 (display-name 子元素)、值的描述 (description 子元素) 和不會顯示的文字授權值 (ent-value 子元素)。

記號元素 <token-src-dn>、<token-association> 和 <token-attr> 實際上是 XPATH 運算式的預留位置，它們分別從 XDS 格式的 XML 文件擷取 src-dn 屬性值、關聯值或任何屬性值。 文件類型定義 (DTD) 假設查詢結果是 XDS。

文件類型定義 (DTD) 中的其他標題

授權文件類型定義 (DTD) 中其餘的授權標題具有不同的功能，但它們不是您在建立授權時需要特別注意的項目。

<!-- Entitlement reference stored in the DirXML-EntitlementRef attribute of a DirXML-EntitlementRecipient or a DirXML-SharedProfile object. -->

文件類型定義 (DTD)「授權參考」部份中儲存的資訊指向授權物件。 此資訊由管理代辦 (例如「角色授權」驅動程式 Entitlement.xml 或「核准流程」驅動程式 UserApplication.xml) 置於該處。 這是已連接系統中使動作發生的觸發事件。 您不需要對此標題下的文件類型定義 (DTD) 執行任何動作，但是可以使用此資訊來確定正在參考授權物件。

<!-- Entitlement result stored in the DirXML-EntitlementResult attribute of a DirXML-EntitlementRecipient object. -->

「授權結果」部份會報告授予或撤銷授權的相關結果。 資訊包含事件的狀態，以及授予或撤銷事件的時間 (透過時戳)。 您不需要對此標題下的元素和屬性執行任何動作。

<!-- Cached query results stored in the DirXML-SPCachedQuery attribute of a DirXML-Entitlement object. -->

「授權查詢」部份包含從外部應用程式蒐集的授權值。 如果授權用戶端需要顯示此資訊，則可以再次使用此資訊。 這些值儲存在「授權」物件的 DirXML-SPCachedQuery 屬性中。 您不需要對此標題下的元素和屬性執行任何動作。

<!-- Representation of a DirXML-EntitlementRef within the DirXML Script and within the operation-data of an operation in an XDS document. -->

因為文件類型定義 (DTD) 定義多個文件的值，所以此 EntitlementRef 部份實際上不屬於「授權」定義。 您不需要對此標題下的元素和屬性執行任何動作。

6.4.4 透過 Designer 建立授權

雖然節 6.4.5, 在 iManager 中建立和編輯授權中的範例顯示用於寫入授權的實際 XML 碼，但是寫入授權的一種更簡單的方法是使用 Identity Manager 隨附的 Designer 公用程式。 將 Identity Manager 驅動程式新增至 Designer 模擬器中的 Identity Vault 之後，您可以從「大綱檢視」中，在驅動程式上按一下滑鼠右鍵，並選取「新增授權」。 「授權精靈」會提示您指定想要的授權類型，然後精靈會指引您逐步完成建立程序。

如需使用「授權精靈」的相關資訊，請參閱《Designer for Identity Manager 3：管理指南》。

6.4.5 在 iManager 中建立和編輯授權

雖然建議您使用 Designer 的「授權精靈」來建立授權，但是您仍可以透過 iManager 建立授權。

  1. 請選取「Identity Manager 公用程式」標題下面的「建立授權」選項。
  2. 在「建立授權」頁上，輸入想要的授權名稱，然後使用「物件瀏覽器」尋找授權所屬的「Identity Manager 驅動程式」物件。
    建立授權
  3. 如果選取「定義額外的內容」，您會看到「XML 編輯器」頁，您可以在該頁針對此授權定義想要的元素。
    定義授權
  4. 核取「啟用 XML 編輯」，以將元素新增至授權。

附註：不建議您變更授權的名稱。如果您稍後變更授權名稱，還需要變更規則中實作授權的所有參考。 授權名稱儲存在規則內的 Ref 和 Result 屬性中。

6.4.6 協助您建立自己授權的範例授權

您可以建立兩種類型的授權： 無值授權和具值授權。 具值授權可以從外部查詢、管理員定義的清單或自由格式取得值。 下面是您可以建立的四種授權範例。

附註：如果您看到某行中沒有「小於號 (<)」，這表示此行已換行，資訊通常顯示在一行，而不是兩行 (或三行)。 另請注意，這些只是您可以針對每種具值授權建立的範例，而不是「帳戶授權」。

範例 1： 帳戶授權： 無值

<?xml version="1.0" encoding="UTF-8"?> <entitlement conflict-resolution="priority" description="This is an Account Entitlement" display-name="Account Entitlement"/>

在此範例中，無值授權的名稱是 Account。 其後接衝突解析行，預設設定為 Priority，表示在大部份情況下，如果授權用於「角色授權」，則會由優先程度高的 RBE 設定其值 (然而，因為這是無值授權的範例，所以不會套用值設定)。「授權」描述是 This is an Account Entitlement，顯示名稱是 Account Entitlement。 這是您建立「帳戶授權」所需的全部資訊，之後您可以使用該資訊來在應用程式中授予帳戶。

啟用授權的 Active Directory 驅動程式具有 UserAccount 授權，Active Directory 會使用該授權來授予或撤銷使用者帳戶。

<?xml version="1.0" encoding="UTF-8"?> <entitlement conflict-resolution="union" description="The User Account entitlement grants or denies an account in Active	Directory for the user. When granted, the user is given an enabled logon account.	When revoked, the logon account is either disabled or deleted depending on how the drive is configured."	display-name="User Account Entitlement" name="UserAccount"> </entitlement>

在此範例中，衝突解析是 Union，這可讓授權合併已指定的值 (同樣，值設定也不會套用至無值授權)。「描述」欄位說明此授權的用途及其建立的原因。 此資訊對於以後要修改授權的人員很有用。 授權的實際名稱是 UserAccount，然而 <display-name> 在管理代辦中顯示為「使用者帳戶授權」。

範例 2： 應用程式查詢授權： 外部查詢

已啟用授權之 Active Directory 驅動程式附帶的「群組」和「Exchange 信箱」授權提供應用程式查詢的範例。 當您需要已連接系統的外部資訊以執行事件時，請使用此授權類型。

<?xml version="1.0" encoding="UTF-8"?> <entitlement conflict-resolution="union" description="The Group Entitlement grants or denies membership in a group in Active Directory. The group must be associated with a group in the Identity Vault. When revoked, the user is removed from the group. The group membership entitlement is not enforced on the publisher channel: If a user is added to a controlled group in Active Directory by some external tool, the user is not removed by the driver. Further, if the entitlement is removed from the user object instead of being simply revoked, the driver takes no action."   display-name="Group Membership Entitlement" name="Group"> <values> <query-app> <query-xml> <nds dtd-version="2.0"> <input> <query class-name="Group" scope="subtree"> <search-class class-name="Group"/> <read-attr attr-name="Description"/> </query> </input> </nds> </query-xml> <result-set> <display-name> <token-src-dn/> </display-name> <description> <token-attr attr-name="Description"/> </description> <ent-value> <token-association/> </ent-value> </result-set> </query-app> </values> </entitlement>

在此範例中，如果將授權多次套用至相同的物件，「群組」授權會使用 Union 來解決衝突。 Union 屬性會合併所有相關「角色授權」規則的授權，因此，如果一個規則撤銷授權，而其他規則授予授權，則最終會授予授權。

因為「群組」描述很詳細，所以很有用，它會說明透過驅動程式規則 (Policy) 中的規則 (Rule) 所設定的項目。 此描述是您在定義授權時首先需要瞭解之詳細資料很好的範例。

<display-name> 是「群組成員資格授權」，顯示在管理代辦中，例如「角色授權」的 iManager 中。 該名稱是授權的相對可辨識名稱 (Relative Distinguished Name，RDN)。 如果您未定義顯示名稱，則授權的名稱是它的相對可辨識名稱 (RDN)。

啟始查詢值會在網路樹的頂端尋找「群組」的類別名稱，並會繼續搜尋其子網路樹。 這些值來自已連接的 Active Directory 伺服器，以及從 <nds> 標籤開始的應用程式查詢。 在 <query-xml> 標籤下面，此查詢會接收到類似於下列內容的資訊：

<instance class-name="Group" src-dn="o=Blanston,cn=group1"> <association>o=Blanston,cn=group1</association> <attr attr-name="Description"> the description for group1</attr> </instance> <instance class-name="Group" src-dn="o=Blanston,cn=group2"> <association>o=Blanston,cn=group2</association> <attr attr-name="Description"> the description for group2</attr> </instance> <instance class-name="Group" src-dn="o=Blanston,cn=group3"> <association>o=Blanston, cn=group3</association> <attr attr-name="Description"> the description for group3</attr> </instance> <!-- ... ->

然後，在 <result-set> 標籤下面，從查詢中接收到的資訊會填入各種欄位。 例如，<display-name> 欄位會收到 o=Blanston,cn=group1。<description> 欄位會收到 the description for group1，而 <ent-value> 欄位會收到 o=Blanston,cn=group1。因為有多個群組存在且滿足查詢條件，所以還會收集此資訊，並將其顯示為其他例項。

附註：關聯格式值對於每個外部系統都是唯一的，每個查詢到之外部系統的格式和語法也不同。

另一個範例是「Exchange 信箱」授權。

<?xml version="1.0" encoding="UTF-8"?> <entitlement conflict-resolution="union" description="The Exchange Mailbox Entitlement grants or denies an Exchange mailbox for the user in Microsoft Exchange." display-name="Exchange Mailbox Entitlement" name="ExchangeMailbox"> <values> <query-app> <query-xml> <nds dtd-version="2.0"> <input> <query class-name="msExchPrivateMDB" dest-dn="CN=Configuration," scope="subtree"> <search-class class-name="msExchPrivateMDB"/> <read-attr attr-name="Description"/> <read-attr attr-name="CN"/> </query> </input> </nds> </query-xml> <result-set> <display-name> <token-attr attr-name="CN"/> </display-name> <description> <token-attr attr-name="Description"/> </description> <ent-value> <token-src-dn/> </ent-value> </result-set> </query-app> </values> </entitlement>

在此範例中，如果將授權多次套用至相同的物件，「Exchange 信箱」授權會使用 Union 來解決衝突。 Union 屬性會合併所有相關「角色授權」規則的授權，因此，如果一個規則撤銷授權，而另一個規則授予授權，則最終會授予授權。

description 指出授權會針對 Microsoft Exchange 中的使用者授予或撤銷 Exchange 信箱，並會足夠詳細地說明授權作業。 display-name 是「Exchange 信箱授權」，顯示在管理代辦中，例如「角色授權」的 iManager 中。 該名稱是授權的相對可辨識名稱 (Relative Distinguished Name，RDN)。 如果您未定義顯示名稱，則授權的名稱是它的相對可辨識名稱 (RDN)。

啟始查詢值會尋找 msExchPrivateMDB 的類別名稱，這是 Microsoft Exchange 函式呼叫，它會在容器「組態」中開始尋找，並會繼續搜尋其子網路樹。 這些值來自已連接的 Active Directory 資料庫，以及從 <nds> 標籤開始的應用程式查詢。 類別 msExchPrivateMDB 在 eDirectory 中沒有等同項目，因此您需要熟悉 Microsoft Exchange 函式呼叫，以進行此類查詢。 但是因為在 Active Directory 驅動程式中找到規則 (Rule) 和規則 (Policy)，所以查詢完成。

授權消費者使用由查詢擷取的資訊。 例如，授權值 (ent-value) 透過 DirXML-EntitlementRef 屬性傳遞至 Identity Manager 規則。 顯示名稱和描述資訊由 iManager 或「使用者應用程式」顯示，並儲存在 DirXML-SPCachedQuery 屬性中。

範例 3： 管理員定義的授權： 包含清單

第三個範例是管理員定義的授權，它會在您選取清單項目之後建立授予或撤銷事件。

<?xml version="1.0" encoding="UTF-8"?> <entitlement conflict-resolution="union" description="This will show Administrator-defined Values"> <display-name="Admin-defined Entitlement"/> <values multi-valued="true"> <value>Building A</value> <value>Building B</value> <value>Building C</value> <value>Building D</value> <value>Building E</value> <value>Building F</value> </values> </entitlement>

在此範例中，授權名稱是管理員定義的，並具有「管理員定義的授權」的已定義顯示名稱 (如果您想讓顯示名稱與授權的相對可辨識名稱 (RDN) 不同，只需輸入顯示名稱)。衝突解析行顯示 Union 的設定，可讓授權合併已指定的值。

「授權」描述是「This will show Administrator-defined Values」。多值屬性設為 true，可讓授權多次指定值。 在此範例中，values 是公司建築字母： Building A 到 Building F。然後，使用者或定義任務的管理員可以透過授權用戶端 (例如 iManager RBE 任務) 或透過「使用者應用程式」，指定建築資訊，然後將此資訊包含在外部應用程式 (例如 Novell eDirectory) 中。

範例 4： 管理員定義的授權： 不包含清單

第四個範例是管理員定義的授權，它會強制管理員輸入值，然後授權才可以授予或撤銷事件。 如果您不具有啟始設定的所有資訊，而因此無法建立任務清單，則可以使用此類型的授權。

<?xml version="1.0" encoding="UTF-8"?> <entitlement conflict-resolution="priority" description="There will be no pre-defined list"> <values multi-valued="false"/> </entitlement>

在此範例中，授權名稱是「管理員定義的 (不含清單)」，因為沒有顯示名稱項目，所以它會使用授權名稱做為顯示名稱。 衝突解析會重新設為預設值 Priority，這表示如果授權用於「角色授權」，則會由優先程度高的 RBE 設定值。 您可以透過授權用戶端 (例如 iManager RBE 任務) 或透過「使用者應用程式」，指定建築資訊，然後將此資訊包含在外部應用程式 (例如 eDirectory) 中。

6.4.7 完成建立授權步驟

授權建立範例已顯示如何執行建立和使用授權的前兩個步驟，如節 6.2, 建立授權： 綜覽中所述。 這包含步驟 1：針對您想要使用授權達成的項目製作核對清單，以及步驟 2：撰寫授權，以處理核對清單中的項目。 步驟 3：建立 Identity Manager 驅動程式的規則；這已超出本章的範圍。 如需建立和編輯規則的相關資訊，請參閱《規則產生器和驅動程式自訂指南》和適當的 Identity Manager 驅動程式指南。

在建立授權 (或使用某些 Identity Manager 驅動程式預先設定的授權) 之後，您現在需要對它們進行管理，此為步驟 4。授權由兩個套件或代辦進行管理： 透過 iManager 做為「角色授權規則」，或透過工作流程提供中的「使用者應用程式」。 如需工作流程提供中使用的授權，請參閱「工作流程提供簡介」。 本章的其餘部份重點放在「角色授權」上。