Shadow objects

Shadow Objects

Shadow objects are a special object type within ACMA. While presented to MIM as an ordinary object class, they are in fact objects that are tightly coupled to, and inherit from another object.

Built-in Shadow Attributes

There are special attributes that are used in the control and creation of a shadow object:

System-Managed Attributes

• shadowParent: Contains the reference to the object that created the shadow object (built-in, automatically managed)
• shadowLink: Stores the name of the link that defines the relationship between the shadow object and its parent (built-in, automatically managed)

User-Defined Attributes (Required)

The shadow parent itself requires two user-defined attributes to be specified in a shadow link:

1. Provisioning Control Attribute:

   • Must be a non-inherited Boolean attribute
   • Controls whether the parent should create a shadow object
   • true = ACMA creates a new shadow object
   • false = shadow object is deleted

2. Shadow Reference Attribute:

   • Must be a single-valued, non-inherited reference attribute
   • When provisioning attribute is true and shadow object is created, this attribute holds the reference to the shadow object
   • When shadow object is deleted, this attribute value is deleted

How Shadow Objects Work

Creation Process

The provisioning attribute is a normal attribute and can be set by any available means:

• Constructor
• Export from MIM
• PowerShell

Lifecycle Rules

• Cannot be directly created: You cannot export an object 'add' of a shadow object to ACMA. The only way to create a shadow object is to set the provisioning attribute.
• Can be directly deleted: MIM can export an object delete for a shadow object, and ACMA will delete the shadow object and set the provisioning control attribute to false.
• Parent dependency: Shadow objects cannot exist without their parent. If the parent is deleted, then the shadow object is automatically deleted as well.

Defining a shadow object relationship

This common use of this type of object is for the creation of a secondary account for a user. This might be for a high-privilege administrator account in a system. An attribute called hasAdminAccount could be bound to the person and used as the provisioning attribute, while the adminAccount attribute is used to store the reference to the shadow object.

Step-by-Step Example

1. Create base object class:

   • Create a new object class called person

2. Create control attributes:

   • Create a Boolean attribute called hasAdminAccount
   • Create a single-valued reference attribute called adminAccount

3. Bind attributes to parent:

   • Bind hasAdminAccount and adminAccount to person

4. Create shadow object class:

   • Create a new shadow object class called shadowAccount that inherits from person

5. Create shadow link:

   • Create a shadow object link with the name adminLink
   • Specify hasAdminAccount as the provisioning control attribute
   • Specify adminAccount as the reference attribute

Result

Whenever the hasAdminAccount attribute is set to true, a new object will be created. You can define constructors for the shadow object class and use it just as you would any other object class.

Common Use Cases

• Administrative accounts: Automatic creation of privileged accounts for users
• Service accounts: Provisioning of application-specific accounts
• Resource accounts: Creation of mailboxes, home directories, or other resources
• Dependent objects: Any scenario where one object's existence depends on another