Bobby and Nima's ILM Blog

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!