Bobby and Nima's Forefront Identity Manager Blog

Introducing Hierarchical Provisioning

Yesterday I was eating my bowl of Frosted Miniwheats (by Kellogg) for dinner  and out fell a coupon for another free box of Miniwheats. “Oh hot lam!” I exclaimed to myself. I had totally not seen the offer stamped on the front of the box for a free box of Miniwheats when I had purchased the jumbo, bachelor sized box of Miniwheats at Costco last Sunday.  A bowl of Miniwheats alone is enough to brighten my days, but winning another 12oz of the half-sugar, half-fiber narcotic ? Well that’s like Christmas in May. I love hidden surprises.

Much like my box of Frosted Miniwheats, FIM 2010 has a few hidden surprises of it’s own that lurk underneath the covers and are often ignored. One of these features is Hierarchical Provisioning. Much like the name would imply, Hierarchical Provisioning allows objects, and more importantly, any missing parent containers, to be provisioned into the connector spaces of LDAP MAs . Previously in MMS, MIIS, and ILM 2007, if one wanted to provision a user into a container in Active Directory, one would need to ensure that they created the container in Active Directory prior to provisioning the user with MMS/MIIS/ILM. However, with Hierarchical Provisioning, you do not need to do this anymore. With some settings configured in the Management Agent (MA), the missing container can be created automatically by the Active Directory Management Agent, and then the object provisioned within it.

The steps to configure this feature are relatively straight forward. Assume that you want to provision the following user into Active Directory: “cn=Bobby Gill, ou=Redmond, ou=Users, dc=fabrikam, dc=com”. In this case, the Redmond OU does not exist in the Active Directory domain. Before the ILM AD MA can provision this new user into the OU specified,  the OU needs to be created in Active Directory. This is where Hierarchical Provisioning comes into play.

 As an ILM Admin, to enable Hierarchical Provisioning on a LDAP MA, you need to configure a mapping within the MA such that anytime upon export the MA detects that a parent of a object doesn’t exist, it knows what object to create in the connected directory for that parent. This configuration is done within  the LDAP MA screens  by mapping valid DN components to object classes in the connected directory. In this case, you would set up a mapping between the “OU” DN component to the object class “organizationalUnit”. Thus in the above scenario, when the MA is exporting the object to AD and realizes that the “OU=Redmond” parent is missing, it will look up the mapping for the “OU” component and first create a new organizationalUnit object named “Redmond” and then export the new user  into the container.

 Steps to configure Hierarchical Provisioning: 

 

1. Create a new instance of your favorite LDAP Management Agent. Personally, I’m a Microsoft guy, so obviously I always choose Active Directory Domain Services.
2. You’ll notice a new page on the left tab titled ‘Configure Provisioning Hierarchy’.
3. Map DN components to Object Classes. The DN Component list box lists all known valid DN components for the given directory, this is inferred by analyzing the LDAP schema of the directory. To the right is the list of available object classes in the directory, again taken from the LDAP schema.

 

4.)    Mappings are created by selecting a DN component in the left list box, and a object class in the right list box, and then clicking “new”. You can only create 1 mapping per DN component.

 Once setup, Hierarchical Provisioning is transparent to the actual provisioning mechanism. Thus, if you are using Synchronization Rules or even a traditional scripted Metaverse Extension, these settings will be applied to both at export time.  Hierarchical Provisioning further reduces the burden on IT Pros by allowing much more flexibility in terms of provisioning decisions made in the FIM Workflows and eliminates an often tedious manual step whenever a new business unit comes online and an associated container or OU needs to be created.

The feature is available to all LDAP Management Agents and is available in the ILM "2" RC0.

 

 

Topics Wanted!

The hardest part of this blog is finding topics to write about that would be interesting and useful to the community at large. If you have a topic or a question that you want to see addressed on this blog, please email me and I will see if I can post something up for it.

Dependencies - not just for avoiding taxes!

What's our name again?

Whoa, new product name! For those of you who have been chasing butterflies for the past month, what was once known to us as Identity Lifecycle Manager "2" is now called Forefront Identity Manager.  I know, it's not the sexiest name in the world and is probably the 5th different name the product has had since it's conception, but it reflects the combination of Microsoft's security and identity product lines into the Forefront brand announced last year.

Personally, I wanted to name the product "Black Thunder II", but then again there are a myriad of reasons why I am not allowed to name Microsoft products.

 But back onto the topic at hand...

Synchronization Rule Dependency

I decided to take some time off today to briefly talk about Synchronization Rule Dependencies, a powerful yet not well understood part of ILM FIM's synchronization capabilities. In brief, a Synchronization Rule Dependency allows one to construct and apply a series of outbound Synchronization Rules ontop of each other. The scenarios that spring to mind whereupon this functionality is useful are things such as adding/removing Exchange mailbox provisioning, or adding/removing VPN access upon a user's Active Directory account (with the former 2 being dependent on the latter).

If an Outbound Synchronization Rule (the dependent) is marked as having a dependency on another Synchronization Rule (the root), the dependent rule will apply itself ontop of the connector that the root Synchronzation Rule is applied on. At run time, when a FIM Action Workflow attempts to add an Expected Rule Entry (ERE) object for the dependent Synchronization Rule onto a FIM Resource's Expected Rules List (ERL) , there needs to also exist an ERE-Add object for the root Synchronization Rule on the ERL.  (I am just going to take a minute here and say I don't think there has been that many acronyms stuffed into one sentence since the merger between the wrestling giants WWF and WCW was announced). Conversely, if an Action Workflow adds a ERE-Remove entry for a root Synchronization Rule, all EREs that correspond to Synchronization Rules further up the dependency tree will be removed.

Its important to note that when you design an Action Workflow to add or remove a series of EREs that correspond to a Synchronization Rule dependency chain, the root rule must be added to the workflow surface prior to any other dependent rules.

Multiple levels of dependency can be created, with more than one Synchronization Rule being made to depend on a single Synchronization Rule.

In the Synchronization Rule Designer, to create a Synchronization Rule Dependency is relatively straightforward. The first page of the designer allows you to select another outbound Synchronization Rule to make a new Synchronization Rule depend on. When selected, the Scope and Relationship pages are automatically greyed out. Once a Synchronization Rule is made to depend on another rule, the only settings that are adjustable on that rule are the workflow parameters and the outbound attribute flows. Conceptually, this falls cleanly from the fact that a dependent Synchronization Rule is being applied "on top" of another rule.

I wish I could paste some screenshots of what this looks like, but the FIM UI has changed markedly since the RC 0 release and I dont want to ruin the surprise just yet :)

The canonical scenario in which Synchronization Rule Dependency's are used are around creating business processes to manage the provisioning/deprovisioning of capabilities that stem from attributes set on a Active Directory user account. In a typical provisioning scenario, one would construct a base "Active Directory User Synchronization Rule" which, as the name implies, would create a new AD User object, flow the necessary base DN, samAccountName and name information. On top of that, you could then model a dependent Synchronization Rule for granting an Exchange mailbox. This Synchronization Rule would be dependent on the Active Directory User Synchronization Rule, and as a consequence would only have a single flow to the homeMDB attribute. Modelling the user account provisioning seperately from the mailbox provisioning, through the use of Synchronization Rule dependency, allows you to define independent business processes around the lifecycle management of the two through Management Policy Rules and workflow.

 As always, feel free to email me any questions you might have and I will do my best to get back to them.

Bobby

XPath Filter Dialect: Examples

The product team and I just wrapped up our week at the TechReady event in Seattle.  Bobby presented an excellent session on codeless provisioning, focusing on configuration and tips and tricks, and I presented a session on workflow and activity extensibility in ILM "2".  We also had the opportunity to solicit feedback about the product from attendees.  This event reminded me of just how new so many of the concepts in ILM “2” are, and how much more knowledge there is which can be shared.  My last post on the XPath Filter Dialect addressed one area where we frequently get questions, as our use of the xpath language is so pervasive throughout the product. 

While many of the common questions and areas of concern are fresh in my memory, I’ll proceed to share some guidance where I can. 

Let’s start with some examples that demonstrate the use of the XPath Filter Dialect addressing common queries (for reporting and other scenarios).  I’d recommend first reading the previous post on the xpath fundamentals.

Note: The XPath Filter Dialect is case sensitive.  Keep this in mind when writing your xpath filters.  For example, /Person[displayname = ‘value’]  is NOT the same as /Person[DisplayName = ‘value’].

Example 1:  A User’s Pending Approvals

You’ll need the following xpath if you want to build a report or page that lists all the approvals that are pending a response from a specific user.

Let’s assume the user, for which you want to see the pending approvals, has an Account Name of ‘mmeyers’ and an ObjectID of  ‘11111111-1111-1111-1111-111111111111’.

This first filter demonstrates how to identify the pending approvals based on the user’s ObjectID:

/Approval[ApprovalStatus = ‘Pending’ and Approver = ‘11111111-1111-1111-1111-111111111111’]

This second filter demonstrates how to identify the pending approvals based on the user’s Account Name:

/Approval[ApprovalStatus = ‘Pending’ and Approver = /Person[AccountName = ‘mmeyers’]]

Notice that in the second example we make use of a location path expression, /Person[AccountName = ‘mmeyers’], inside the predicate in order to identify approvals where the Approver is a user with the specified Account Name.

Note that the ApprovalStatus represents the status of an approval and can have one of the following values:

·          Pending

·          Approved

·          Rejected

·          Expired

A status of ‘Pending’ means the approval is currently awaiting a response from one of the users listed in the Approvers attribute of the approval.

A status of ‘Approved’ means the Request associated with the approval has been approved by the required number of approvers.  After an approval has been created it will only be marked as ‘Approved’ if the minimum number of responses, as specified by the ApprovalThreshold  attribute of the approval, is met.

A status of ‘Rejected’ means a user designated as an approver for the approval have rejected the approval.  At any point in time if a valid approver rejects an approval, that approval is immediately rejected and the workflow and associated Request is terminated.

A status of ‘Expired’ means the approval has reached the time indicated by the ApprovalDuration attribute on the Approval object as no response to the approval has been submitted.

Example 2:  All Security Groups expiring within the next 7 days.

/Group[Type= ‘Security’ and ExpirationTime <= op:add-dayTimeDuration-to-dateTime(fn:current-dateTime(), xs:dayTimeDuration(\"P7D\"))]

Example 3:  All Orphaned Security Groups

An ‘orphaned’ security group here refers to a group with no owner.  The following is the xpath to identify such groups:

/Group[Type = ‘Security’ and Owner != /Person]

Example 4:  People who are members of both the "Interns" group and the "Full Time Employees" group:

While my example here may not be a very compelling one, the goal is to demonstrate how we can identify users that are in sets or groups producing conflicting roles or permissions.

/Person[ObjectID = /Group[DisplayName = ‘Interns’]/ComputedMember  and  ObjectID = /Group[DisplayName = ‘Full Time Employees’]/ComputedMember ]

Note that I used the DisplayName attribute to identify the groups of interest, but the better practice would be to use a unique identifier to identify the groups, such as their ObjectID attribute.

Example 5:  People who were EVER members of both the "Interns" group and the "Full Time Employees" group at the same time:

The previous example identified people who are currently members of two conflicting groups.  The following example identifies people who were ever members of these conflicting groups at the same time.   This example makes use of the historical querying feature of ILM to scope the query to a time in the past.

allTime(/Person[ObjectID = /Group[DisplayName = ‘Interns’]/ComputedMember and ObjectID = /Group[DisplayName = ‘Full Time Employees’]/ComputedMember ])

Example 6:  All permissions that Kim Abercombie had in the month of January, 2009.

Again, here we see the use of historical query to check for a condition that was met at some time in the past.  This time we are checking for permissions that existed for a user between a specified time period.

betweenTime(/ManagementPolicyRule[GrantRight = 'True' and PrincipalSet = /Set[ComputedMember = /Person[ DisplayName = ‘Kim Ambercrombie’]]] , ‘2009-01-01T00:00’, ‘2009-01-31T00:00’)

Notice that the filter above is looking for any Management Policy Rule, of the type that grants permissions, which granted permissions to a set that contained Kim Ambercrombie in its membership

Example 7:  Changes to security groups in the last 10 days

/Request[Target = /Group[Type = 'Security'] and Operation = 'Put' and CreatedTime >= op:subtract-dayTimeDuration-from-dateTime(fn:current-dateTime(), xs:dayTimeDuration('P10D'))]

The above filter is returning all Requests that were created, within the last 10 days, to modify a security group.  If you want to find only the Requests that were actually ‘completed’, or the ones that were ‘rejected’ or still pending, simply add an additional condition based on the status of the request.

Example 8:  All full time employees that were ever contractors (ie. transitioned from one job to another).

/Person[EmployeeType=’Full Time Employee’ and ObjectId = allTime(/Person[EmployeeType=’Contractor’])]

 

Each of these examples is related to a question I've recieved in the past.  As more common scenarios become apparent, I will post examples addressing them. 

 - Nima

XPath Filter Dialect: Fundamentals

ILM “2” provides a Web Service Enumeration (WS-Enumeration) end point by which client applications can run queries and retrieve the results. Please refer to Joe Schulman’s excellent extensibility blog for more details on using the WS-Enumeration end point in ILM “2”.

This blog focuses on the XPath Filter Dialect, which you can use to create the queries to submit through the ILM Web Services.  XPath Filter Dialect is a subset of the XML Path Language (XPath) 2.0, with some additional functions.

Client applications can send WS-Enumeration Enumerate messages to the ILM Service to identify a of resources and attributes.  The subsets resources to return are identified by expressions in the XPath Filter Dialect (from here on usually referred to simply as an ‘xpath filter’ in this blog). 

If you are developing your own custom client for ILM, or submitting queries to ILM through a custom activity, you will need to use the xpath filter as your query language.  In the ILM portal, xpath is the language in which you express the queries for Search Scopes that can be created.  Xpath is also used to express the membership conditions of calculated groups and sets.

The following is an example of an xpath filter that identifies all people whose Job Title is ‘Engineer’: /Person[JobTitle = ‘Engineer’]

Rather than continue listing examples of xpath filters you may find useful, I’m going to use this blog post to describe the fundamentals of the ILM Xpath Filter Dialect so that you can understand the expression language and construct any filter you need.  I will follow up this blog with another post of some sample filters for commonly requested queries and reports.

Much of the content I include here is probably covered by the ILM “2” SDK in much more detail, but hopefully you’ll also find some of the guidance here conveniently available and useful J.  I will build on this topic with examples as people request them, so feel free to make suggestions!

Let’s start by looking at the data types the ILM xpath filters support.

Data Types

The ILM XPath Filter Dialect supports the four data types defined for XPath 1.0, plus the dateTime type that is defined in the XML Schema specification. These types are defined in the following table.

Data type	Definition
node-set	A collection of XML nodes without duplicates.  Refer to Joe Schulman’s blog for examples of node sets in ILM WS-Enumeration.  Think of a node-set as a collection of resources.
Boolean	true or false
number	A signed integer.
string	Any sequence of characters from the Universal Character Set.
dateTime	The dateTime represents a date and time in Universal Coordinated Time.
reference	A GUID that identifies a reference to a resource.

 

Now that we know what types of data we can filter on in our expressions, let’s take a look at what types of expressions we can actually define.

Types of Expressions

ILM “2” supports the following types of xpath expressions:

1. Location path expressions
2. Boolean expressions
3. Equality expressions
4. Relational expressions
5. Function calls

 

1.    Location Path Expressions

A location path expression identifies a node-set (collection of resources). A location path expression consists of one or more location steps. Location step expressions are delimited by a forward slash (/).  A location path expression must refer to an object type in ILM, or an attribute of type reference which refers to a resource.  Location path expressions have the following form:   /step/step/… | step/step/…

A forward slash at the beginning of an expression indicates an absolute location path expression as distinct from a relative location path expression. A relative location path expression identifies a node-set relative to the context node-set. The context node-set is the set of nodes that have already been identified.

Example: /Group/ComputedMember is a location path expression that consists of two location steps: Group and ComputedMember.  The result of this filter is all resources that are the ComputedMember of any Group.

Example: /Person[AccountName = ‘nima’]/Manager returns the resource referenced by the Manager attribute of the Person with an Account Name of ‘nima’.

Example: /Person[AccountName = ‘nima’]/DisplayName is not a valid xpath filter because DisplayName is not a reference type attribute.

            Union of location path expressions

The union of one or more location path expressions can be obtained by linking the location path expressions with the union operator, which is denoted by the vertical bar character, |.

Example:  /Person | /Group returns all people and groups. 

Predicates

Predicates are expressions that appear enclosed in brackets at the end of location steps. In the XPath Filter Dialect, predicate expressions must be Boolean expressions, equality expressions, function expressions or relational expressions.

Predicates filter the current node-set to produce a subset. A predicate is evaluated for each node in the current node-set. If the result of the predicate is true for a node, that node is included in the subset yielded by the predicate; otherwise, it is excluded.

Example:  /Person/Manager[JobTitle = ‘VP’] returns all people whose Manager’s Job Tile is ‘VP’.  The location step here are Person and Manager[JobTitle = ‘VP’] .  The second location step consists of a node name, Manager, and a predicate, JobTitle = ‘VP’.  

You can even have location path expressions nested inside predicates.

For example, the filter /Person[Manager = /Person[JobTitle = ‘VP’]] returns all people whose Manager is a person with a Job Title of ‘VP’.  Note that this returns us the same result as a previous example: /Person/Manager[JobTitle = ‘VP’].

2.    Equality Expressions

Equality expressions test the equality of terms. They have the following form: left_hand_term operator right_hand_term

The valid equality operators are as follows:

Operator	Result
=	Yields true if the term on the right and the term on the left are equal; otherwise yields false.
!=	Yields true if the term on the right and the term on the left are not equal; otherwise yields false.

The left-hand term of an equality expression must be the name of an attribute in the ILM schema.

The right-hand term of an equality expression can be one of the following:

·         A function call.

·         A Boolean value.

·         A dateTime value.

·         A number.

·         A string.

·         A reference value.

If the left-hand term is a reference type attribute, the right-hand term can be a location path expression (ie. a filter representing a sub-condition).

 

Multi-Valued Equality Expressions

When the = operator is used in an equality expression where the left-hand term is a multi-valued attribute and the right-hand term is a literal value, the expression evaluates to true if the value of the right-hand term is any of the values contained in the left_hand_term.

Example:  /Group[ComputedMember = ’11111111-1111-1111-1111-111111111111’] returns all groups whose ComputedMember attribute contains the resource with the ObjectID ’11111111-1111-1111-1111-111111111111’. 

When the = operator is used in an equality expression where the left-hand term is a reference attribute (multivalued or single valued) and the right-hand term is a location path expression, the expression evaluates to true if the value of the attribute on the left-hand term is any of the values contained in the node-set returned by the right_hand_term. 

Example:  /Group[Owner = /Person[EmployeeType = ‘Contractor’] returns all groups whose Owner is a Contractor. In other words, this filter returns all groups where any of the values of their Owner attribute is among the set of people whose Employee Type is ‘Contractor’.

3.    Relational Expressions

Relational expressions compare the values of two terms. They have the following form: left_hand_term operator right_hand_term

Valid relational operators are: <=, <, >=, >, which are pretty self explanitory.

4.    Boolean Expressions

Boolean expressions evaluate the validity of two expressions in a predicate using ‘or’, and ‘and’.

When ‘or’ is used, the predicate evaluates to true if either expression is true.

Example: /Person[JobTitle = ‘VP’ or ‘Senior VP’] returns people whose Job Title is ‘VP’ or ‘Senior VP’.

When ‘and’ is used, the predicate evaluates to true only if both expression are true.

Example: /Person[JobTitle = ‘VP’ and Department = ‘Sales’] returns people who are VPs and are in the Sales department.

5.    Function Calls

The ILM XPath Filter Dialect provides the following functions that can be used in location path expressions:

Function Signature	Description
boolean contains(Attribute, string)	Returns true if the value of the first argument, which must be a valid attribute in the ILM schema, contains the second as a substring; otherwise returns false.
boolean starts-with(Attribute, string)	Returns true if the value of the first argument, which must be an attribute in the ILM schema, starts with the second; otherwise returns false.
Boolean ends-with(Attribute, string)	Returns true if the value of the first argument, which must be an attribute in the ILM schema, ends with the second; otherwise returns false.
Boolean not(boolean)	The not function returns true if the argument evaluates to false and false if the argument evaluates to true.  The argument must be one of the following expressions which returns a Boolean: 1.     Relational expression 2.     Equality expression 3.     Function call
dateTime current-dateTime()	Returns the current date and time with time zone. For more information see current-dateTime in XPath 2.0.
dateTime dateTime(date, time)	Returns the arithmetic sum of the arguments. For more information see dateTime in XPath 2.0.
dateTime add-dayTimeDuration-to-dateTime(dayTimeDuration, dateTime)	Returns the result of adding the values of the two arguments. For more information see add-dayTimeDuration-to-dateTime in XPath 2.0.
dateTime add-yearMonthDuration-to-dateTime(yearMonthDuration, dateTime)	Returns the result of adding the values of the two arguments. For more information see add-yearMonthDuration-to-dateTime in XPath 2.0.
dateTime subtract-dayTimeDuration-from-dateTime(dayTimeDuration, dateTime)	Returns the results of subtracting the value of the second argument from the value of the first argument. For more information see subtract-dayTimeDuration-from-dateTime in XPath 2.0.
dateTime subtract-yearMonthDuration-from-dateTime(yearMonthDuration, dateTime)	Returns the results of subtracting the value of the second argument from the value of the first argument. For more information see subtract-yearMonthDuration-from-dateTime in XPath 2.0.
node-set descendants(locationPathExpression, attributeName)	Returns a node-set (set of resources) that consists of the dereferenced resources obtained by dereferencing the reference attribute specified by attributeName, starting with the resource specified by the location path expression.  Example: descendants(/Person[DisplayName = Nima’], ‘Manager’)  returns the manager of the person with the DisplayName of ‘Nima’, and the manager of all those people recursively (ie. everyone ‘Nima’ reports to indirectly)
Bool descendant-in(attributeName, Filter)	This function obtains a set of resources by recursively dereferencing the reference attribute specified by attributeName, starting with the context node. If the set of resources obtained contains the resource identified by Filter (or is among the resources identified by Filter), the function returns true; otherwise, it returns false. Example: /Person[ descendant-in(‘Manager’ , /Person[DisplayName = ‘Nima’])] returns all people who report to ‘Nima’ (ie. people who have ‘Nima’ in their management chain).
node-set membersof(ObjectID)	The membersof function accepts the unique identifier of a Set as input, and returns the members of that Set.
node-set allTime(locationPathExpression)	The allTime function accepts a valid filter expression in the XPath Filter Dialect as input, and returns the resources matching that expression at any time over the history of the data in the ILM Service database.
node-set atTime(locationPathExpression, dateTime)	The atTime function accepts a valid filter expression in the XPath Filter Dialect and a DateTime as input. It returns the resources matching that matched the expression at the specific DateTime specified.
node-set betweenTime(locationPathExpression, dateTime,  dateTime)	The betweenTime function accepts a valid filter expression in the XPath Filter Dialect, two DateTime values as input, and returns the resources matching that expression at any time between the two DateTimes specified.

 

Hopefully this blog helps you understand the structure of the XPath Filter Dialect expression language.  Trust me when I say this knowledge will come in extremely handy if you will be performing any of the following:

·          Creating search scopes for the portal.   Search scopes are pre-canned searches you can use in the portal.

·          Creating advanced calculated sets and groups that cannot be created using the Filter Builder control in the ILM portal.  One example of such a set is the set of all resources that contain an Expected Rule Entry for a particular Synchronization Rule in their Expected Rules List.

·          Creating custom activities that will query the ILM Service database.

·          Creating a WS client that will submit queries to the ILM Web Service.  Such clients can be used for purposes such as reporting.

Stay tuned as I will be following up with some xpath ‘tips and tricks’ and sample filters for commonly requested queries.

Cheers,

Nima Ganjeh

ILM "2" also comes as a hybrid...

For those of you who are MIIS / ILM 2007 pros, when seeing the Codeless Provisioning functionality one of the first questions that comes to mind is "can I use my existing rules extension in ILM "2"?".

Of course.

At a basic level, with ILM "2" RC, you can take an existing ILM 2007 deployment and migrate it's synchronization engine component straight into ILM "2" RC. You can do this by copying the IdentityIntegrationServer DB to a ILM "2" server, and upon installing ILM "2" point to this database instance during the setup of the synchronization component. The installer will then migrate that data forward such that all existing MA and MV configurations are ready to use right away, including rules extensions.

But if you want to go beyond this, its important to note how Codeless Provisioning works side-by-side with existing ILM synchronizaiton concepts. That is, while Codeless Provisioning bubbles up a business process driven approach to synchronization it is inherently underpinned by the same basic mechanics which power the ILM synchronization engine. As such, the adding of this functionality should not in any way change the behaviour of how MA's work, how rules extensions are called or how traditional metaverse provisioning is done.

This side-by-side coexistence is collectively referred to as a hybrid deployment.

Metaverse Provisioning 

In fact, it is supported to run Codeless Provisioning based provisioning logic side by side with traditional metaverse extensions. Codeless Provisioning is driven through the processing of Expected Rule Entry (ERE) objects, these determine which MV objects are provisioned a connector and how flows are applied on top. For a MV object being sync'ed, this processing is done prior to the calling of the Metaverse rules extension. Hence if for any reason the ERE's attached to a MV object do not achieve a desired outcome in a CS, you can use a Metaverse extension to provision additional connectors, apply initial flows and deprovision existing connectors just you would have done with ILM 2007.

Custom Functions = Rules Extensions 

Metaverse extensions are just one aspect of a hybrid scenario. A more common use case is for scripted flow. ILM "2" RC contains around 20 built in functions, which for the most part should satisfy most basic needs. However if this is not true, then you can always use an traditional Rules Extension to apply a transformation on a outbound flow. Using an MA, you can defined an advanced flow like before. This flow will be applied after any Sync Rule flows have been pushed onto an object, thus allowing you to append or overwrite attribute flow data that was provided by a Sync Rule.

Join / Projection Rules

On the inbound side, the traditional Join/Projection concepts live on as you remember them in ILM 2007. Just like the extension points, you can use traditional declared/advanced join projection rules along side Synchronization Rule concepts. In this case, if you have defined a Inbound Synchronization Rule on an MA that also has traditional join/projection rules defined the Synchronization Rule will be evaluated first. So if a disconnector exists within this MA such that it matches a Synchronization Rule's connected scoping filter, than this disconnector will be attempted to be joined/projected to the MV based on that Synchronization Rule definition. If the evaluation of that disconnector against the Synchronization Rule results in the CS object remaining a disconnector, then the existing declared join/projection rules will be executed against it.

How to make ILM "2" scream.

One of the big features of ILM "2" RC are the changes we have made to the portal and server to enable ILM to scale higher. In the portal and in the ILM service we've tuned, and jiggered with the way we interact with SQL and on the wire to make the ILM experience faster and snappier. Out of this, we've both gotten a better idea of what it takes to deploy ILM in such a way to maximize performance as well as key pieces of knowledge to help administrators keep their deployment running zipper quick. I will be writing a series of posts outlining much of this knowledge over the coming days.

Hardware

• If you are asking yourself which hardware to buy to deploy ILM, recognize that ILM is extensively CPU bound. Having a fast disk is essential, however the key gating factor is the CPU horsepower on your box. This is because of ILM's policy and rights calculations require SQL to execute multiple-statement operations when performing what are seemingly simple operations from the portal. Typically we use 4xQuad-Core boxes in our performance deployments.
• In an organization of 50,000 users, 20,000 groups, you should expect your base database size to be about 7 GB or so. The growth of this database will be dependent on the frequency of changes executed on the ILM system. Any rig set up for ILM should have enough RAM to load this database entirely into memory.

SQL

SQL is where performance starts and ends in the ILM Service. It is critical to having ILM perform at enterprise scales that SQL is setup such that it can best serve the ILM application. You may wonder why we took the hard dependency on SQL Server 2008 in RC, and the answer is more than it's snappy new logo. SQL Server 2008 introduces a new feature called Filtered Indices which specifically aims to limit index pollution as well improve queries across sparse columns by selectively including values within specified indices. ILM weakly-typed, single-table based storage mechanism begs for the usage of this new capability and we did it. If you only have 1000 objects in your ILM store, well then this isnt much of a deal, but when you start scaling into the 50k+ arena, filtered indices come into their own.

Beyond this, deploying ILM requires a steady eye towards maintaining and monitoring ILM performance. Here are couple of tips off hand which should help you keep ILM screaming:

• Turn off Automatic Statistics Updating. SQL uses a sampling technique by default to generate the statistics it uses for creating query plans. We've found that sometimes SQL grabs a bad sample and as such you will see queries all of a sudden fall off of a cliff. To prevent this turn off the automatic statistics update and manually run a fullscan statistics update on the ObjectsInternal table. Frequency of executing this will depend on the frequency of updates to the ILM database.
• Pre-grow your ILM DB, TempDB and Transaction logs. Ensure that you max out these files from the get-go so you do not take the cost of incrementally increasing the files during normal operation.
• Ensure you have seperated out the ILM DB, TempDB, and Transaction logs onto seperate drives.
• Ensure that SQL has been set to have a fixed upper limit on the memory it can consume during operation. If left uncheck you will see SQL gobble away memory until it starts to adversely affecting the performance of both the OS and as a result ILM.

ILM Service:

The ILM Service itself is actually quite lightweight and  very much dependent on the performance of SQL. To help streamline the service further you can try:

• Ensure tracing is set to error level or is off completely. Running at an excessive tracing level is guaranteed to bring ILM to it's knees.
• If you find certain queries are taking so long that the underlying SQL connections are timing out, you can use the dataReadTimeout and dataWriteTimeout attributes within the resource management service node in the resource management service configuration file to set the number of seconds for the underlying SQL timeouts.

That's all for now. Look for some further posts talking about other ways to monitor and manage ILM performance.

 In the meantime, we are currently at Tech Ed Europe in Barcelona. You can come find me, or Nima,  at the ILM booth located in the main exhibition area for the next couple of days. I will be running an Instructor Led Lab on ILM on Thursday at 1pm.

If you get a chance, I definitely recommend attending one of the many ILM sessions being done over the next couple of days:

Thursday: Identity Lifecycle Manager 2 (Part 3): Extensibility and provisioning with ILM 2 (Nima GanjeH)

2:40-3:55pm

Wednesday: Identity Lifecycle Manager 2 (Part 2): Expressing and enforcing business policy (Alex Weinert)

1:30-2:45pm

Announcing Identity Lifecycle Manager “2” Release Candidate

We're back! Today we have a guest blogger to announce the Release Candidate for ILM "2":

 

 

I’m Lori Craw, group product manager covering identity and security at Microsoft. Today I am pleased to announce the exciting news that the Identity Lifecycle Manager “2” Release Candidate (RC) is now available.

 

ILM “2” builds on our Identity Lifecycle Manager 2007 investments, and includes solutions that will help IT more efficiently and effectively automate identity policies for users and their associated credentials and entitlements. An important set of features in this release focus on self-service for end users, enabling them to manage some of their own information like their passwords and groups, using self-service tools built into Office. The IT pro tools, combined with end-user self-service in Office and developer experiences using .NET and Visual Studio add up to a very powerful combination.

 

We’ve received great feedback on these features from our beta and TAP customers so far. We also have seen some great momentum with core partners, including Quest, Omada, and Unisys.

 

So what’s new in the RC, you ask? Some of the top new additions to the RC include:

- Support for scale out of the ILM "2" middle tier database and portal on separate servers, and support for multiple portal servers
- Added support for managing groups across multiple Active Directory forests
- Improvements in the request and notification emails, including customizable notification emails and request details baked into the out-of-box request emails
- Support for third-party certificate authorities (CAs)
- Performance and stability improvements
- Localization support for German and Japanese

I’d like to invite you to learn more about ILM “2” and to try out the RC for yourself by visiting www.microsoft.com/ilm2.

 

Regards,
Lori Craw
Group Product Manager
Microsoft Identity and Security

Custom expressions in advanced attribute flows

If you are at the point where you're comfortable with using the functions and various options in attribute flow creation, I'd like to introduce you to a really cool feature to add some efficiency and extra capabilities to your attribute flow creation:  Custom Expressions.

The synchronization rule designer provides you the ability to type in any attribute flow you can define using the flow definition user interface.  This is supported through the CustomExpression option you'll find under the advanced options in the value selection list when selecting a value for Source in an attribute flow.  See the screenshot below for clarification.

 So, what syntax exactly do you use to define the flows in this custom expression box?  Create an attribute flow in the normal manner (without using CustomExpression) and take a look at the attribute flow summary view when you save the flow, as shown below. 

 This summary view represents the attribute flow in a short form syntax as follows:

·         Constant strings are represented in quotes (“ “)

o   Eg. “Nima”

·         Constant numbers are represented simply as numbers.

o   Eg. 456

·         Attributes are represented as the attribute name.

o   Eg. FirstName

·         Synchronization rule parameters are represented as the parameter name prefixed with ‘$’.

o   Eg. $InitialPassword

·         Functions are represented as the name of the function and the associated parameters are given values that follow the syntax outlined here.

o   Eg. Left(“TestString” , 5)

·         The concatenate operator is represented as ‘+’.

o   Eg. FirstName + LastName

 

The syntax above is the exact same syntax you would use with the CustomExpression option.  The example below defines an attribute flow for generating a random password.

 Hopefully this makes defining flows a bit quicker for some of you.

The use of the CustomExpression option extends beyond just efficiency for power users though.  The CustomExpression option also allows you to define attribute flows containing nested functions, as you saw in the example above for generating random passwords.  In addition, you can also use CustomExpression with another very cool function available in the synchronization rule designer:  The IIF function.

 IIF function (Immediate IF) returns one value if a specified condition evaluates to true, and another value if the condition evaluates to false. 

The function's signiture is as follows:  IIF(condition, valueIfTrue, valueIfFalse).  -  Note that in beta 3 the function is mispelled as IFF :)

We use this type of functionality in programming all the time, so how does it provide value in the context of an attribute flow?  Well, think of any example where you'd want to flow a particular value to an attribute if some condition was true, and another if it was false.  One such example is defining the flow for an employee's email address.  Let's assume we want to prefix the email alias of a vendor/contractor with a "v-", and for full time employees we leave the alias as is. 

In other words, if the employee is a vendor/contractor, his email becomes his mailnickname "@microsoft.com" prefixed with "v-".  So, if nimag was a contractor, his email would become "v-nimag@microsoft.com"

In the synchronization rule designer, we can specify this attribute flow as follows:

For the condition, we used the CustomExpression option to allow us to specify an expression to evaluate.  Here we used the Eq() function which takes two arguements as inputs and compares them for equality, returning true if the attribute has the given value and false if not.  The condition is not very clear from the screenshot above, and its complete form is Eq(managed:EmployeeType, "Contractor").  The condition is checking to see if the managed:EmployeeType attribute has the value "Contractor".

Our return value if the condition ( the result of the Eq() function ) evaluates to true is the employee's email address prefixed with "v-".  The return value if the condition evaluates to false is the employee's email address as is (no prefix).

 The following are functions available for use as expressions in the IIF function:

Eq - This is the function used in the example above.  This function compares two arguements for equality.

NotEquals - This function compares two arguements for inequality, returning true if they are not equal, and false otherwise.  Example:  NotEquals(managed:EmployeeType, "Contractor")

LessThan - This function compares two numbers, returning true if the first is less than the second and false otherwise.  Example:  LessThan(Salary, 100000)

GreaterThan - This function compares two numbers, returning true if the first is greater than second and false otherwise.  Example:  GreaterThan(Salary, 100000)

LessThanOrEquals - This function compares two numbers, returning true if the first is less than or equal to the second and false otherwise.  Example:  LessThanOrEquals(Salary, 100000)

GreaterThanOrEquals - This function compares two numbers, returning true if the first is greater than or equals to the second and false otherwise.  Example:  GreaterThanOrEquals(Salary, 100000)

 Hopefully this helps bring to light some of the powerful capabilities you now have with the new provisioning features of ILM "2" !

- Nima

One DRE and a large shake to go...

For those of you who have used ILM "2" Beta 3, you have probably used in some form the new codeless provisioning functionality included within it. There is a ton of functionality encapsulated within this one area, and one of the less-talked about and centrally important pieces of this functionality is something we call the Detected Rules Entry (DRE). Do not confuse this with the Expected Rule Entry (ERE) object as they are two ends of two different sticks. The DRE very simply is an object that is created by the ILM "2" synchronization engine and associated to an ILM managed object when the synchronization engine detects that the flows as defined within a specific Synchronization Rule have been confirmed to exist within the connected system. More simply, the DRE is designed to provide the truth with regards to an object's state in a connected system, with the lingua franca in this case being communicated via definitions of logic which are Synchronization Rules. If the ERE can be thought of what we want the desired state of an object to be in a connected system, the DRE is the actual state of the object.

 How are DRE's created?

 You may have noticed within the Synchronization Rule designer a check box on the attribute flow page which says "Use as Existence Test?". When checked, the conjunction of all flows marked as being Existence Tests are evaluated by the synchronization engine against all connectors associated with any ILM object. This evaluation is done during synchronization of a management agent and obviously done on connector objects which are being processed as part of that synchronization run. If a connector space object is detected as having met the conditions of the Synchronization Rule, the synchronization engine creates a DRE object in the Metaverse, and places a forward link from the ILM Metaverse object to which the aformentioned connector object is joined to. From an ILM Metaverse object perspective, it has an attribute called "Detected Rules List", which is a multi-valued reference attribute to all DRE objects associated with it.

 

Ok, so why should I care?

Aha. This is the important part. DRE's allow you to create and launch business processes after a particular state is confirmed to exist within a connected system. (Think of needing to create a home directory after an AD user account is created)  DREs are only ever created based off of changes that are confirmed within the connected system (i.e. brought in through in an import), this allows you to then launch actions after having a particular state pushed to a connected system. After creation, DRE's are pushed via the ILM MA to the ILM Resource Management service. They are then subject to MPR and Process evaluation just like every other change coming to the web service.

So if we take an example of an Active Directory User Account synchronization rule. You may have anywhere from 5-20 flows for an AD User account synchronization rule. However, ask yourself this, what's the limited set of flows that you need in order to confirm  that a particular ILM object is associated with a confirmed AD user account? Probably 2, one for detecting the state of the userAccountControl attribute being set to 512  and the other matching the samAccountName on the user account with the managed:AccountName attribute on the Person object. By setting these 2 flows as existence flows within the Synchronization Rule designer, you can then trigger the creation of DRE's anytime the Synchronization Engine confirms those two flows on a connector object.

Some scenarios where this may be useful:

 - Triggering the granting of other out-of-band provisioning tasks that require an Active Directory user account to be present prior to launch.

- Compliance detection. DRE's are triggered on changes brought in from other systems. You can use DRE's to detect if somebody has an account in a system which was not granted via ILM, and then use MPR and Process to launch a workflow notifying their manager or an administrator of the existence of such an account.

 

Caveats in Beta 3:

- Existence flows cannot be defined for function flows and reference attribute flows

- Currently no mechanism to trigger workflow decisions based on the parent object of a DRE

Data transformation and attribute flow without writing code: functions to the rescue!

If you read the post on setting up the synchronization rule for the flowing of Computers to AD, you'll notice we make use of a concatenation option to concatenate multiple values and flow them to a destination attribute.  Concatenation is an example of a data transformation function that allows you to operate on and transform data you wish to use in the context of an attribute flow or workflow.  In ILM "2" you have over a dozen such functions available for you to use.  These functions are a critical aspect of "codeless" provisioning in ILM "2". 

In future posts I will dive into detail on specific functions and how you can use them to support your scenarios.  For now I want to introduce you all to this piece of functionality you may not be aware of.   To begin using these functions, either a)create an action workflow with the function activity or b)create an attribute flow for a synchronization rule.

The inclusion of functions in attribute flows means you can construct flows that involve more than just a simple attribute to attribute flow without writing any code.  For those of you that are familiar with writing scripted attribute flow in ILM 2007, you'll immediately appreciate some of these functions as they remove the need for writing custom code for many of the attribute flows you require.

It's easy to identify a case where you require the use of a function.  Perhaps you wish to generate a random password to flow for a new user account that is provisioned.  The screenshot below, from the synchronization rule designer, demonstrates the use of the concatenation and random number functions to create a password that consists of the string "Password" concatenated with a random number.  Of course we could define a more complex password, but this illustrates a simple example of how we can use functions.

Stay tuned for a detailed overview of specific functions.

 - Nima

The Mysteries of the ILM Management Agent Uncovered:

 

One of the many changes we made across the ILM to support the new declarative synchronization and provisioning concepts (aka 'codeless provisioning') was with the ILM Management Agent (hence forth referred to as ILM MA)  configuration experience. 

 

While at first glance the ILM MA may walk like, look like and act like any one of the many management agents that we have all come to know and love from the MIIS/ILM days, this resemblance is, at best, superficial. In fact the ILM MA is not your typical Management Agent, and has a unique design experience tailored to fit within the broader conceptual relationship between the ILM Application Store and the ILM Metaverse. While the two stores co-exist as independent stores in ILM "2", the relationship between the two should not be thought of  in the same vein as the typical relationship between a connected system and the Metaverse. Instead, it is envisioned that the ILM Application Store is in fact conceptually equivalent to the ILM Metaverse. Taking this notion one step further you should view the Metaverse serving as a transient storage mechanism on the road to and from the ILM Application Store, the ultimate  location for any data being synchronized into ILM. Seeing this,  we can then very easily imagine data moving from Active Directory or another third party system into the ILM realm and immediately coming under the control of the policy and process framework which applies to all data within the ILM Application Store and is at the conceptual heart of ILM application. (In order for this statement to be valid is for all data to make it to the Application Store)

 

With this view in mind, when we looked at the ILM MA, we wanted to make the experience of setting up the Management Agent between the Metaverse and Application Store to both provide a simple and "replication" like experience as possible. Thus, when you configure the ILM MA, you do not set up join and projection rules, nor do you need to write provisioning code or use Synchronization Rules to move data between the ILM MA connector space and the ILM Metaverse. Instead, you simply map object types from the Metaverse to object types in the Application Store, and then setup the attribute flow relationships between the two. After this point in time the ILM MA will automatically make sure that any new objects which are created in the ILM Application Store of the type specified in the mapping  are replicated to the ILM Metaverse as an instance of the second type specified in the aforementioned mapping (and vice versa).  The ILM MA thus allows customers the flexibility to connect newly defined ILM Application Store types to existing schema elements that they have created with their existing ILM Metaverse deployments.

 

Some of you may wonder if you are able to use scripted attribute flow and other extension mechanisms within  the ILM MA. The answer to this is no. The reason for this is that transforming data as it flows between the ILM Metaverse and the Application Store would violate the conceptual tenant that the two are logically equivalent. Instead, any desired data transformation should be done either upon inbound flow from a connected system into the Metaverse (via a Synchronization Rule or scripted flow) or in the ILM Application Store (as part of a workflow or through a web service call).

 

If we look at Nima's example of setting up the flowing of Computers, his configuration of the ILM MA demonstrates the new mapping functionality. You will notice in the ILM MA that the projection and join screens have been replaced by a Object Type Mapping screen. It is in this screen in which you map a Application Store type to its associated Metaverse type. (a known issue in Beta 3 is that your Metaverse type must be pre-fixed with "managed:" to be visible in the object type selection).

 

On the next page, you will then need to configure the attribute flows between the two types. ILM does not attempt to automatically map the attributes themselves and leaves it up to the user to determine how the attributes should be flowed. (Note: only direct flows are supported). The ILM MA also automatically adds a set of built in flows needed to support the replication functionality of the ILM MA, do not delete these!

 

 

Extending ILM "2" to manage and provision computer objects

One topic for ILM “2” that came up repeatedly at TechEd IT Pro North America this year was extensibility.  Specifically, many customers asked how the system can be configured to manage an arbitrary resource, enabling them to apply policies to and provision any resource they care about.  To demonstrate this, I included a demo in Fred Delombaerde’s extensibility breakout session where we demonstrated how ILM can be configured to manage computers.  Part of this demo involved managing computer security group memberships and provisioning new computers to Active Directory. 

 

A few people asked if we had the steps to perform that scenario documented anywhere.  Since we didn’t publish a hands on lab for this, I’ve included a step by step to accomplish the scenario below. 

 

What is the objective?

Our goal is to manage computers assets.

Steps to accomplish our goal:

         1.  Create a Computer object type.

         2.  Create objects of type Computer.

         3.  Add the computer objects to a security group called “All Computers”.

         4.  Have computers provisioned automatically to AD.

 

How to do it?

1.       The first thing we need to do is extend the schema to support computer object types.  Create a computer object type.

a.       Go to http://localhost/identitymanagement/aspx/schema/Schema.aspx

 

  

b.      Click on “New” and fill in the details for the new object type as below.

 

 

 

c.       Click “Finish” and “Submit”.

 

d.      A computer object type is created now, and we can actually now begin creating and managing computers.  If additional attributes beyond those on the base Resource type are desired for computers, you can create them and bind them to the computer object type.

 

 

2.       Create a new search scope “All Computers”.  The search scope will enable selecting computers to add to a group later on.

a.       Go to Administrative Settings > Search Scope Configuration:  http://localhost/identitymanagement/aspx/customized/CustomizedObjects.aspx?type=SearchScopeConfiguration&display=Search+Scope+Configuration

  

b.      Click on “New” and fill in the fields as below.

 

 

 

 

 

 

 

 

Click “Finish” and “Submit”

 

c.       Go to Run->Cmd and run “iisreset”.

 

 

Syncing Computers to the Metaverse:

 

To provision computers to downstream systems, we must first represent them in the metaverse.  Computer objects can be sync’ed to the metaverse through a combination of configuration in the portal and in the ILM MA screens within the Identity Manager. The overall steps for replicating Computer objects in the portal are:

1.)    Add the Computer object type to the Synchronization Filter (such that the ILM MA can see it).

2.)    Configuring the App Store <-> Metaverse object type mapping within the ILM MA that will replicate computers into the metaverse.

 

1.    Go to the “All Resources” page.

2.    Click on Page 2, and click on Synchronization Filter.

3.    There will be a single Synchronization Filter object defined.

4.    Add Computer to the Synchronize ObjectType Description reference attribute.

 

 

 

 

At this point, Computer objects should now be visible from the ILM MA. Return to Identity Manager and follow these steps:

1.)    Click on the ILM MA, and select “Refresh Schema”

2.)    You should see a new schema update being pulled back as a result of the previous action.

3.)    Go to the MA properties, go to Object Types, click “Show All” and you will see the computer object type. 

 

 

The next thing you need to do is configure the mapping between the object type in the app store and that in the metaverse. This is new in Beta 3, in that by creating this mapping you will automatically replicate objects from the App store into the Metaverse and vice versa.

 

Before we can add a mapping for the Computer object, we must first define an object type to represent it in the metaverse.

1.     Go to the Metaverse Designer page in Identity Manager and select "Create Object Type" from the list of actions.

 

2.   Specify a name for the new object type and select any attributes you want in the metaverse for this object. 

 

 

3.     Now go back to the ILM MA properties, go to Object Types, click “Show All” and you will see the computer object type.  Select it.  Note: You will need to repeat this step for the AD MA as well, so that you can define attribute flows for Computers in AD.

 

 

4.     Go to "Configure Object Type Mappings" in the ILM MA properties and "Add Mapping” between the Computer object and an object type in the metaverse. (Note in beta 3, your metaverse object type has to be prefixed with ‘managed:’ in order to be visible here.)

 

 

5.     Go to Attribute Flow, you will see the mapping you selected on the previous page visible here. Set up all necessary attribute flows to replicate a Computer object into the managed:Computer object type. Note if you want data to flow both ways you will need to setup flows in both directions.

 

 

In order to being provisioning computers to AD using processes in ILM, you need to first define a synchronization rule for computers, along with the provisioning process and Management Policy that triggers it.

 

1.       Create a new synchronization rule for computers.

a.       Go to http://localhost/IdentityManagement/aspx/syncrule/AllSyncRules.aspx

 

 

b.      Click on “New”

 

 

c.       Specify general information for the synchronization rule and indicate this is an outbound synchronization rule.  If we were importing data from AD into ILM this would be an inbound synchronization rule.

 

 

 

d.      Proceed to the Scope page, selecting the managed object type representing computers in the metaverse, your AD MA, and the computer object type on the MA as below.

 

e.      Proceed to the Relationship page and specify the relationship criteria used to identify related computers.  The example below uses DisplayName as the criteria.  Select the object creation option and if desired, the relationship termination options as below.

 

    

 

f.      Proceed to the Outbound Attribute Flow page to define the flows for this synchronization rule.  For this example, we will provide the minimum flows required to provision the computer to AD: We’ll define a flow for our relationship criteria (DisplayName), and for the dn of the computer.

 

g.      Define the flow for the DisplayName.  Click on the “Click to define flow” link and specify the flow as below.  Click OK when finished.

 

h.      Define the flow for the dn attribute.  Click “New Attribute Flow” and click on the “Click to define flow” link to bring up the flow definition page again.

                                                                    i.            Select “dn” as the “Destination” for the flow.

                                                                  ii.            For the flow’s “Source”, specify the value that should be used.

 

 

i.      Make sure you’ve selected “Initial Flow Only” for both the flows defined above.

 

 

 

2.       Create a new action process to add the synchronization rule to computers that should be provisioned.

a.       Go to the processes page in the portal: http://localhost/IdentityManagement/aspx/process/AllProcesses.aspx

 

 

b.      Click on “New”.

 

c.      Specify some general info about the process as below.  Select “Action” as the process type.  Click Next to proceed to define the activity.

 

 d.      From the list of available activities, select the Synchronization Rule Activity and click “Select”.

 

e.      Select the computer synchronization rule created previously as below, and click save.

 

f.      Now we’re finished defining the provisioning workflow, so click Finish and submit the new process.

 

 

3.       Create a new set that will contain the computer objects you want to provision.

a.       Go to the sets page in the portal: http://localhost/IdentityManagement/aspx/sets/AllSets.aspx

 

 

b.      Click on “New”.

 

c.      Specify some general info about the process as below and proceed to define the Dynamic Membership of the set.

 

 d.      Select the “Enable dynamic membership in current set” option and define the set’s membership criteria.  In the example below we’re creating a set of all computers, so we simply select “All computers” from the first line of the filter statement, and do not add any statements or sub conditions to further filter the membership.

 

e.      Click Finish and submit the request to create the new set.

 

4.        Create a new Management Policy Rule to kick off the provisioning process when a new computer is created in ILM.

a.       Go to the Management Policies page in the portal: http://localhost/IdentityManagement/aspx/policy/AllPolicies.aspx

 

 

b.      Click on “New”.

 

c.      Specify some general info about the Management Policy as below and proceed to define the Operation and Users.

 

 d.     Specify the operation and users that should trigger the computer provisioning process.  In the image below we’ve indicated that the operation we care about is the creation of new objects (computers), and the requestor of the operation can be anyone.  Proceed to the Condition After page when finished with this page.

 

e.     Now you must specify the set of resources whose creation should trigger our provisioning process.  Here we select the set of “All computers” we defined earlier.

 

f.      Finally we select the provisioning action process we want to run in the Policy Workflows page.   Click Finish and we’re done!

 

 

Now let’s create a new computer and a security group containing it as its member and see them provisioned to AD.

 

 

1.       Create instance of Computer object type “Comp0001”

a.       Go to http://localhost/identitymanagement/aspx/customized/AllCustomizedObjectTypes.aspx - All Resources

Click on “Computer”

 

 

b.      Click on “New”

 

 

c.       Fill in as below

 

 

 

Click “Finish” and “Submit”

d.      New object of type computer “Comp0001” is created

 

 

 

2.       Create a Group named “All Computers”

a.       Go to the Security Groups page in the portal: http://localhost/identitymanagement/aspx/Groups/CreateSecurityGroup.aspx?Previous=..%2fGroups%2fAllGroups.aspx

b.      Fill in as below

 

 

 

Click “Next”.

Deselect “Adminstrator”

From the drop down select “All Computers”

 

 

 

 

Select “Comp0001” and click “Finish” , “Submit”.

 

3.       Go to the created group “All Computers” @ http://localhost/identitymanagement/aspx/Groups/AllGroups.aspx

a.       Click on the group “All Computers”

b.      Go to members section

c.       So the computer object “Comp0001” is part of “All Computers” group.

 

 

Make sure the sync script that came installed on the beta 3 vpc is running.  After waiting a short while for the data to be sync’d out to AD, open the AD Users and Computers console and verify the computer was provisioned successfully.

 

- Nima 

 

Greetings!

 

This is us! We're Nima Ganjeh, and Bobby Gill, two Program Managers working on Microsoft's Identity Lifcycle Manager "2" product. We started this blog to serve as a resource to all of you for both learning about how the product works as well how to use ILM to solve specific scenarios.

 Topics will be driven by both feedback we receive from you, the beta 3 newsgroup, requests from customers as well things we think would be great sources of knowledge for you.

 If you're scratching your head wondering what ILM is right now, we urge you to check out http://www.microsoft.com/windowsserver/ilm2/default.mspx

 If you dont feel like reading check out these videos below which will give you a very brief outline about what ILM is all about:

In the following video Bobby walks through some of the core ILM "2" IT Pro scenarios as well as dives into using ILM 's codeless provisioning feature to provision users into Active Directory.

ILM User Provisioning with Bobby Gill

Next up is Alym, who in this video talks about how ILM "2" impacts end-users and knowledge workers, specifically focusing in on ILM "2" group management capabilities and password reset functionality:

ILM Password Resets with Alym Rayani

Want more? Join the ILM "2" public beta program! Doing so will get you not only access to the Beta 3 bits of ILM "2" as well as give you access to a wealth of knowledge being shared amongst other Beta program participants. You can sign up for the Beta at:

http://connect.microsoft.com/