Patent Application
20080046433
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards managing network account objects (sometimes referred to as security principals), wherein a network account object corresponds to a role and in general specifies the network access rights, privileges, resources and so forth for a given network entity such as a user, service or computer. Unlike past systems, in which a template was used to create a user account object and thereafter had no relationship with the user account object, various aspects of the technology described herein are directed towards maintaining an association between each network account object and a role template object (or template objects) after creation.
For purposes of simplicity herein, many of the various examples are directed towards one particular type of network account object, namely a user account object. Notwithstanding, it will be readily appreciated that this is only for example purposes, and that other network account objects, including but not limited to service account objects and computer account objects, are basically equivalent with respect to role template objects and/or lifecycle management.
In one example implementation, the network account objects and role template objects are maintained in an object store, which in an example implementation described herein, is an object store in a Microsoft® Active Directory® environment. Notwithstanding, it can be readily appreciated that the data of the objects described herein may be alternatively maintained in other data structures and/or data stores, and in other networking environments. Indeed, as used herein, the term “object” represents any data structure for maintaining data including attributes (equivalent to “properties” as used herein), and “object store” refers to any collection of objects, regardless of how they are physically and/or logically arranged and/or located. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and network management in general.
One of the computing devices (e.g., 1024) is shown as maintaining an object store 108, which as described below, stores role template objects and network account objects, which may be created based upon those template objects; note that in an alternative implementation, the object store 108 may be distributed and/or replicated across multiple computing devices. For example, in an Active Directory® environment, each role template object (e.g., named UserRoleTemplate) may be created in the Active Directory® schema and maintained in the Active Directory® primary object store.
A new type of template object, named a role template object herein, provides for the concept of a role to be maintained in association with network account objects, including maintaining the association after creation. One way to store the settings in a role template object is to express them in XML, with the XML vocabulary defined by a schema. This enables interoperability with other systems, e.g., as an extension to a System Definition Model (which supports the Microsoft® Dynamic Systems Initiative). An Active Directory® template object may store this XML description of the role values.
Moreover, in addition to maintaining the association after creation, role template objects add capabilities that are not present in existing templates (that are presently used only for user account creation). Examples of such additional capabilities include the ability to specify an event action (e.g., a set of one or more tasks) to take when a network account is created, an event action to take when a network account is assigned to a different role, and/or an action to take when a network account object is deleted. In general, these situations correspond to events in the life of a network account, and thus terms used herein to refer to such concepts in general include lifecycle milestones, lifecycle event actions and lifecycle management. Further, changes to network account objects may be propagated to those network account objects as a group if their corresponding role template is modified.
As generally represented in
Each role template object 221-224 is created with a number of attributes, which are filled in based on attribute types 231-239 defined in the user template object 220. For example, this may be accomplished via a template manager (editor) 229, such as an extension of a user/administration console that allows new role templates and network accounts to be created and managed, e.g., in a rich graphical user interface that lists network accounts in one sortable column and the role for each network account in an adjacent sortable column. The template manager 229 also may list tasks that may be performed on network account objects, e.g., including on multiple selected network account objects, such as all network account objects linked to a specific role. The application program 229 may allow administrators to choose from among typical role template objects, modify existing role template objects and create new role template objects (whether from scratch or based on an existing role template object, or based on an existing network account). Note that as described below, the act of modifying an existing role template object may result in the changes being propagated to the network account objects associated with that role template object, e.g., by the template manager 229. A default set of role template objects may be provided, e.g., including role template objects for common business and organizational roles that typical customers find useful, such as knowledge worker, sales person, manager, executive, student, volunteer, and the like.
Further, the template manager 229 provides a mechanism to specify the action (a set of one or more tasks) to be taken for each lifecycle milestone of a network account object.
For lifecycle management, the attributes in the role template object 224 include an action (e.g., a reference thereto) for each of the user lifecycle milestones, namely (in this user account-centric example) user account object creation 336, user account object moving (reassignment) 337, and user account object deletion 338. In general, these attributes identify the tasks to perform upon a milestone event occurring. Although it is feasible to store the set of tasks themselves in the user template objects 221-224, such as in the form of executable code, in the example of
As also represented in
Returning to
By way of an example of user account lifecycle management in a hypothetical company, a company administrator can set up each sales person user account 252-254 with an association with the corresponding role template object 223. The role template object 223 may, for example, contain attributes that assign new sales person user account objects to security groups A and B, and grant each user 50 MB of disk storage space for documents. In the event that this hypothetical company later decides to give sales people additional resource access, such as to also assign sales people to security group C and to increase the disk quota to 100 MB, the sales person template 223 is modified. Because the association is maintained after creation, the template manager 229 may propagate this change to the user account objects 252-254 that are currently associated with the sales person template 223.
Consider a further example in which this same company also has an employee role of sales manager with a corresponding template object 222 that assigns group membership in groups A, C, and D and rights to modify the tables of the sales tracking database. If an employee is promoted from sales person to sales manager, the user account administrator changes the template assignment for this person's user account object from the sales person template 223 to the sales manager template 222. As described below, as part of a move workflow, the template manager 229 may automatically give that user account object the new membership in group D and remove the membership in group B, while also granting the user account the privilege to update the sales database. For example, the move URI in the sales person template 223 may point to a workflow assembly that contains the remove-related membership tasks, while the move URI in the sales manager template 222 may point to an assembly that contains the tasks that add the appropriate memberships and privileges for the new role of sales manager.
In the event the employee leaves the company, the user account administrator deletes that user account object, e.g., the object 251. Via the deletion workflow assembly pointed to in the sales manager template 222, the template manager 229 takes appropriate deletion action, e.g., performs tasks to remove that account's security group memberships, its privileges in the sales database and to archive the former employee's documents and email that were associated with that user account.
An additional capability facilitated by role template objects is to list network accounts and/or search for network accounts based on role membership, e.g., for viewing and reporting purposes, and for propagating changes thereto. For example, search and categorization may be performed to list the network accounts that meet a certain criteria, such as role, location, or group membership. As represented in
As can be readily appreciated, the association between network accounts and templates thus provides for a mechanism to locate and/or apply changes to a template to all accounts associated with that template. This one-to-many propagation allows a company to evolve without significant manual intervention. Further, the template object stores information about an event action that should be taken at each milestone of an account's lifecycle, e.g., account creation, account reassignment, and account removal. The actions (or pointers to those actions) stored in a role template object are modifiable so that roles can evolve with the growth and changes in a company. Actions may be modified by changing the code that performs the task set (e.g., in the workflow assemblies to which the role template object points), or by changing the URI to reference a different workflow assembly. Note that in a given network it is feasible to associate a network account with more than one role template object, whereby the appropriate actions of each role template object may be applied cumulatively. An arbitration mechanism or the like may be used to resolve conflicting actions.
One way to author actions for user lifecycle milestone events is to use Windows® Workflow Foundation, which provides a user-friendly authoring environment that is an extension of Visual Studio. Notwithstanding, because in one implementation the action set is invoked through a URI, any executable code may be invoked. For example, any managed code assembly may be named and used, and thus any of the managed code languages such as C# or VB.Net may be used to author lifecycle actions. In one example implementation, actions may be invoked using an InvokeAction method of an Irole template objectActions interface. This interface also defines an event, ActionResult, which is called when the action completes, and conveys the success or error status of the action. A callback method, ActionProgress, may be periodically called to inform the template manager 229 of the progress of the action. ActionProgress may have a reference parameter that may be set to cancel the action. Actions may be transacted so that any tasks that were performed are undone (rolled-back) if all tasks did not complete successfully, e.g., due to error or user cancellation.
A lifecycle event action is thus a sequence of tasks. Examples of tasks performed by a user account creation action may include creating an Active Directory® user account object and setting its attributes (properties) based on the template, creating a mailbox for the user, adding the user to the role template-listed security and distribution groups, creating a network share and applying the quota as defined in the template, assigning permissions to a website (e.g., a Sharepoint Services web site), updating a Human Resources database, and so on. Analogous tasks may be executed for user role reassignment, e.g., moving the user to a different organization unit, changing the group membership, changing the quota, granting permission to a database, and so forth. Examples of tasks likely to be performed on user deletion include removing the Active Directory® user account object, deleting the user's mailbox such as after archiving the user's email, removing the network share after archiving the user's documents, and so forth.
Turning to other aspects, user administrators may manually give network account objects memberships and privileges beyond those assigned by the user's template. Similarly, a user administrator may change or remove some of the memberships or other network account object configuration state. As a result, when such a network account object is deleted, and the template manager 229 attempts to run the deletion workflow defined by the user's template, some of the tasks within the deletion action set may not be successful because of the manual changes. In such an event, the deletion action may note the individual task failures and continue until all of the action's tasks have been attempted. The user administrator is then given a report as to the status of the deletion actions.
As can be readily appreciated, consistency is maintained as long as operations are launched from a common administration console. However, if other tools are used to make changes, then the relationship between a network account object and its role template may be lost. As represented in
For example, in the event that a network account object is changed, e.g., by an administrator, one option is to run a service (e.g., continuously or periodically, such as daily) that makes sure that each network account continues to match the associated role template object's settings. Enforcement may be automatic, e.g., the service can restore the network account object to conform to the role template object. Alternatively, certain network accounts may be flagged so that they will be allowed to have settings that deviate from their associated template, e.g., by setting an “enforce-compliance” attribute to FALSE. Auditing may be performed to report which accounts are not in compliance, e.g., including a listing of who made the non-conforming changes and when they made them, and/or as well as recording the name of the person who set the enforce-compliance attribute to FALSE.
There also may be a “default” template for network account objects that have been manually modified such that they no longer correspond to the settings embodied in their former template. For example, before assigning the network account object to the default template, the template manager 229 may compare the modified user account object to the other templates to see if there was a match. When a network account object associated with the default template is deleted, a notification may be given to the administrator, e.g., to the effect that there may be resources that need to be manually deleted because the template manager 229 may not track the manual changes.
Another aspect is with respect to extensibility, in which the template system may be designed to allow third parties or IT administrators to add additional lifecycle operations. For example, a Customer Relations Management (CRM) system vendor may add a creation task that would add the new user to the CRM system database. This new task may be run after the role's included creation tasks. In other words, it is feasible for a role template to store a sequence of URIs to be performed at each lifecycle action, with the ability to add URIs to the end of this sequence, or even insert them elsewhere in the sequence.
Turning to an explanation of the example operation of a template manager 229 and workflows with reference to the flow diagram of
Step 504 represents an example of creating a network (e.g., a user) account and linking the account (e.g., via a GUID-based or similar association) to the role template object created in step 502. Note that as indicated via the dashed line, step 502 need not be performed for each user or other network entity, but rather only occurs upon creation of a role template object for a new class of network accounts. For example, step 504 may begin the process for a new user that links to an existing role template object; the administrator selects the template that will be used as the basis for creating the new user account object. In any event, in this example implementation, the new user account object has an attribute that identifies the associated role template object, and subsequent actions for that the user account are able to be invoked via the workflow assemblies identified in that template.
Step 506 represents looking up the URI in the attributes to the create workflow assembly, and running the create workflow for the user created at step 504. Note that part of the creation at step 504 may be performed via the workflow, e.g., tasks such as Active Directory® object creation, mailbox creation, document folder creation, quota setting and so forth may be accomplished as part of the create workflow at step 506.
Step 507 represents some lifecycle or role-related change occurring, typically in response to some administrator action, but possibly in response to an automated process, a timeout condition, or some other event or the like. Note that such a change need not correspond to simple edits, such as renaming, changing the user's phone number, and so on, which may be done directly on the user account object and are not represented by step 507. Further note that step 507 may occur long (e.g., days, weeks, months or years) after creation, and that the steps of
As described above, the template manager 229 allows an administrator to assign a user account object to a different role template. If this is the change that occurred, as evaluated by step 508, a move/reassignment action takes place. As represented via steps 510 and 514, the move workflow on both the old role template object and the new role template object may be invoked in that order (old first, then new). A parameter to the action-invoking function may be used to notify each workflow as to whether the role was being removed for that account (leaving the old role) or added for that account (entering the new role). In this manner, the old role template object may have its reassignment action invoked in remove mode so it may do whatever removal cleanup was required. The new template's reassignment action may be invoked in add mode so that a new configuration may be performed. As also represented by step 512, the role template object attribute is updated to point to the new template.
If not a move, step 516 evaluate whether the change corresponds to deletion of an account. As described above and represented via step 518, when the administrator deletes an account object, the application that performs the deletion reads the role template name from the object, and then performs the deletion action. In one example implementation, the deletion action is performed by reading the name (e.g., URI) of the deletion workflow assembly from the role template object. Via that URI, the named workflow will be invoked to do the deletion action (task or tasks).
Another possible change occurs when a role template object is modified, as detected via step 520. In such an event, the template manager 229 locates (e.g., via the search mechanism 460 of
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
