Guest

Cisco Unity

Overcoming Protected Groups Permissions Problems with the Cisco Unity Permissions Wizard

Cisco - Overcoming Protected Groups Permissions Problems with the Cisco Unity Permissions Wizard

Document ID: 44164

Updated: Nov 20, 2007

   Print

Introduction

This document explains how to overcome the difficulty that arises when members of protected groups do not inherit permissions set by the Cisco Unity Permissions Wizard from their parent container.

Prerequisites

Requirements

There are no specific prerequisites for this document.

Components Used

This document applies to Cisco Unity 3.0(1) and later integrated with:

  • Exchange 2000

  • Exchange 2003

  • Mixed Exchange 2000 and Exchange 2003

  • Mixed Exchange 2000 and Exchange 2003 with Exchange 5.5

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Background Information

Within Active Directory there is a concept known as "a protected group." User objects either can be explicit or transitive members of a protected group. Explicit members are those that are members of the protected group and transitive members are those that are members of another security or distribution group, which in turn is a member of a protected group.

User objects associated with protected groups do not follow the standard Active Directory hierarchical permissions model. Instead of inheriting permissions from their parent container, their Access Control List (ACL) is a copy of the ACL on the AdminSDHolder object. Once an hour, the domain controller that holds the Primary Domain Controller (PDC) emulator and Flexible Single Master Operation (FSMO) role compares the ACL for user objects associated with protected groups against the ACL on the AdminSDHolder object. If a discrepancy is found between the ACL for a user object associated with a protected group and the AdminSDHolder object, the user object ACL is updated to match the current ACL of the AdminSDHolder object.

The protected groups in Windows 2000 are listed below:

  • Enterprise Administrators

  • Schema Administrators

  • Domain Administrators

  • Administrators

The protected groups in Windows Server 2003 and in Windows 2000 after you apply the 327825 hotfix or Service Pack 4 are listed below:

  • Administrators

  • Account Operators

  • Server Operators

  • Print Operators

  • Backup Operators

  • Domain Administrators

  • Schema Administrators

  • Enterprise Administrators

  • Cert Publishers

The following users also are considered protected:

  • Administrator

  • Krbtgt

Problem

Prior to the release of Cisco Unity 4.0(3), the Cisco Unity Permissions Wizard did not assign permissions to the AdminSDHolder object. Since permissions are not assigned to the AdminSDHolder object, Cisco Unity is not able to write the data necessary to maintain normal operation with user objects associated with protected groups.

Symptoms

Failure to write data to a user object can result in a variety of unexpected behaviors. Common symptoms include failure to import a user and updates to an extension, alternate extension, or transfer extension reverting back to the old value after a few minutes. If Cisco Unity attempts to write to the directory and is refused access, an error message always is logged. Check for an error message to determine if directory permissions are the cause, as shown in the examples below.

3.x Error Message Example:

adminsdholder1.gif

4.x Error Message Example:

adminsdholder2.gif

Solution

Several possible solutions exist to this problem. The method recommended by Cisco is to grant the following rights to the Directory Services Account on the AdminSDHolder object of each domain that Cisco Unity services. Apply onto this object only:

  • List Contents

  • Read All Properties

  • Write All Properties

The following steps should be taken to overcome this difficulty:

  1. Open the Active Directory Users and Computers window.

  2. Choose View > Advanced Features to set permissions on the AdminSDHolder object .

    adminsdholder3.gif

  3. Browse to the AdminSDHolder object. The object is in the following location for each domain in the Active Directory Forest:

    CN=AdminSDHolder,CN=System,DC=Cisco,DC=Com
    

    (Where "DC=Cisco,DC=Com" is the Distinguished Name (DN) of the domain.)

    Once located, right-click on the AdminSDHolder object and choose Properties.

    adminsdholder4.gif

  4. From the Properties window, click the Security tab and then click Advanced.

    Clicking Advanced brings up the Access Control Settings for AdminSDHolder window.

    adminsdholder5.gif

  5. From the Access Control Settings for AdminSDHolder window, click Add.

    This brings up the Select User, Computer, or Group window.

    adminsdholder6.gif

  6. From the Select User, Computer, or Group window, select the Directory Services Account and then click OK.

    This brings up the Permissions Entry for AdminSDHolder window.

    adminsdholder7.gif

  7. From the Permissions Entry for AdminSDHolder window, in the Apply onto field, select This object only and choose the List Contents, Read All Properties, and Write All Properties rights.

  8. Once step 7 is complete, click OK to close the Permissions Entry for AdminSDHolder window, the Access Control Settings for AdminSDHolder window, and the AdminSDHolder Properties window.

    Within one hour, the ACL will be updated on the user objects associated with the protected groups to reflect the changes.

Related Information

Updated: Nov 20, 2007
Document ID: 44164