Live@edu ilm2007

Live@EDU Escalation Engineer Training

Module 6: Identity Lifecycle Manager

DRAFT V1.1 Released: July 12, 2010

Conditions and Terms of Use

Microsoft Confidential - For Internal Use Only

This training package content is proprietary and confidential, and is intended only for users described in the training materials. This content and information is provided to you under a Non-Disclosure Agreement and cannot be distributed. Copying or disclosing all or any portion of the content and/or information included in this package is strictly prohibited.

THE CONTENTS OF THIS PACKAGE ARE FOR INFORMATIONAL AND TRAINING PURPOSES ONLY AND ARE PROVIDED "AS

IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE

IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.

Training package content, including URL and other Internet Web site references, is subject to change without notice. Because Microsoft must respond to changing market conditions, the content should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

Copyright and Trademarks

© 2010 Microsoft Corporation. All rights reserved.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

For more information, see Use of Microsoft Copyrighted Content at http://www.microsoft.com/about/legal/permissions/.

Microsoft®, Internet Explorer, and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Microsoft products mentioned herein may be either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.

http://www.microsoft.com/about/legal/permissions/

Table of Contents

About This Course .................................................................................... Error! Bookmark not defined.

Course Contents .................................................................................................. Error! Bookmark not defined.

Document Conventions ....................................................................................... Error! Bookmark not defined.

Technical Terms, Commands, and Program Code ........................................... Error! Bookmark not defined.

Notes ............................................................................................................... Error! Bookmark not defined.

Tables and Figures ........................................................................................... Error! Bookmark not defined.

Course Document and Slide Numbering ......................................................... Error! Bookmark not defined.

Using the Keyboard and Mouse in a Virtual Machine ......................................... Error! Bookmark not defined.

Module 1: Introducing <product or technology> .................................... Error! Bookmark not defined.

Lesson 1.1: Title ....................................................................................... Error! Bookmark not defined.

Topic H2 ............................................................................................................... Error! Bookmark not defined.

Subtopic H3 ..................................................................................................... Error! Bookmark not defined.

Lesson Review ..................................................................................................... Error! Bookmark not defined.





Lab 1: Title ................................................................................................ Error! Bookmark not defined.

Module Review ........................................................................................ Error! Bookmark not defined.

Module 2: Installing and Configuring <product or technology> .............. Error! Bookmark not defined.









Lab 2: Title ................................................................................................ Error! Bookmark not defined.


Module 3: Managing and Maintaining <product or technology> ............ Error! Bookmark not defined.


Topic H2............................................................................................................... Error! Bookmark not defined.







Lab 3: Title ............................................................................................... Error! Bookmark not defined.


Module 4: Troubleshooting <product or technology> ............................ Error! Bookmark not defined.









Lab 4: Title ............................................................................................... Error! Bookmark not defined.


Additional Resources ............................................................................... Error! Bookmark not defined.

Course Review ......................................................................................... Error! Bookmark not defined.

Course Assessment .................................................................................. Error! Bookmark not defined.

Appendix *: Title ...................................................................................... Error! Bookmark not defined.

Overview Topic H3 .......................................................................................... Error! Bookmark not defined.

Appendix Topic H3 .......................................................................................... Error! Bookmark not defined.


DRAFT V1.1 Live@EDU Escalation Engineer Training

Global Technical Readiness Microsoft Confidential - For Internal Use Only 1

Module 6: ILM and Live@Edu This is the final module in the Live@Edu class. It covers ILM and our different

management agents.

Before You Begin

Before starting this module, you should:

Have a working understanding of Live@Edu under both Hotmail and Exchange

Done all the previous Live@Edu modules

What You Will Learn

After completing this module, you will be able to:

Understand ILM and its complexities

Configure and Install all three editions of the @EDU Management Agents.

Troubleshoot common configuration issues with all three versions.

Module 6: Identity Lifecycle Manager DRAFT V1.1 Lesson 1: Identity Lifecycle Manager

2 © 2010 Microsoft Corporation. All rights reserved.

Lesson 1: Identity Lifecycle Manager This lesson goes into depth about ILM and its configuration. Note that the vast majority

of this documentation came from existing Admin Guides and online documentation that is

available.

What You Will Learn

After completing this lesson, you will be able to:

Describe how ILM Functions.

Understand concepts like the Meta Verse.



Identity Lifecycle Manager

What is ILM

ILM 2007 is a metadirectory product that has a variety of uses for data synchronization

and identity management. In the case of the Live@edu program, it will be used to

facilitate the management of accounts by synchronizing data from the data source for

student information and Windows Live. To further understand the role of ILM 2007 as it

relates to Live@edu it is important to understand the fundamentals of this type of

product.

The ILM 2007 application runs on Windows 2003 or 2008 Enterprise Edition. It relies

upon Microsoft SQL Server as the application data store to retain all of the settings for

ILM 2007 as well as the identity data that is synchronized through it.

Metadirectory

A metadirectory collects information from different data sources throughout an

institution and then combines all or part of that information into an integrated unified

view. This unified view presents all the information about an object such as a student or

network resource that is contained throughout the institution. An Identity Management

system may have a metadirectory at its heart and ILM 2007 is such a system. A

metadirectory performs the following functions:

Connects to a variety of data sources, importing a desired subset of data from each one

Combines all the information about each student or resource into a single entry

Presents to the institution the unified view of all known information about each student

or resource

Enforces rules as to which sources are authoritative for a given attribute and what

precedence applies where more than one source is authoritative

Microsoft currently distributes two separate versions of ILM 2007. The Live@edu version

allows an institution to connect to one data source for account imports and to Windows

Live for account creation. The full version of Microsoft Identity Lifecycle Manager 2007 is

needed to connect to more than two data sources. The following table lists the supported

management agents for the full version of Microsoft Identity Lifecycle Manager 2007.

This table illustrates the capabilities of the full version of ILM 2007 to communicate with

some of the types of data sources that ILM 2007 includes out of the box.

System Management Agent

Network Operating Systems and Directory Services

Microsoft Active Directory Windows Server 2003 R2, 2003, and 2000 Microsoft Active Directory Application Mode Windows Server 2003 R2 and 2003 Microsoft Windows NT 4.0



IBM Tivoli Directory Server Novell eDirectory 8.6.2, 8.7, and 8.7.x Sun Directory Server (Netscape/iPlanet/SunONE) 4.x and 5.x

Mainframe IBM Resource Access Control Facility Computer Associates eTrust ACF2 Computer Associates eTrust Top Secret

E-mail and Messaging Microsoft Exchange 2007, 2003, 2000, and 5.5 Lotus Notes 6.x, 5.0, and 4.6

Applications SAP 5.0 and 4.7 Telephone switches XML-based systems DSML-based systems

Databases Microsoft SQL Server 2005, 2000, and 7 IBM DB2 Oracle 10g, 9i, and 8i

File-Based Attribute value Pairs CSV Delimited Fixed Width Directory Services Markup Language (DSML) 2.0 LDAP Interchange Format (LDIF)

All Other Extensible Management Agent for connectivity to all other systems

If the previous table does not include your student data source, you have several options.

The first is to get the data out of your data source and into a format that ILM 2007 can

recognize, such as an LDIF file or delimited flat-file. Flat-files can often be the lowest

common denominator between integrating two systems. You also have the possibility to

build your own extensible management agent to connect to the data source.

Data Aggregation

In most institutions, student information exists in many different data repositories

resulting in duplication of student information; there is no single, reliable place to go for

this information about a student or faculty. Directories that hold identity information are

often incompatible. These incompatibilities include different naming conventions,

different directory schemas, different communication protocols and different data

formats. The number of places in which organizations must manage identity information

increases with the addition of new systems. To solve the issues that result from identity

data residing in multiple repositories you can use a metadirectory to:

Combine the data for a specific person or resource in the metadirectory, thereby

creating a single entry that contains some or all of the identity information from each

directory.

Present a single unified view that contains some or all of the attributes from the

different directories regardless of whether the directories are compatible.



Provide a platform that can become the basis of an Identity Management (IdM) system –

it contains the authoritative identity information for objects.

Data Synchronization

Because an institution‘s student information is often contained in different data

repositories, a change made to data in one repository is not automatically made in any of

the other repositories. Making the change throughout the organization requires the

administrator(s) to make the change in each directory manually. Therefore, updating data

in each directory is costly, unreliable and may even present a security risk. Unmanaged

identity information quickly becomes disorganized which results in identity information

that is not synchronized throughout the organization. To manage changes to identity

information you can use a metadirectory to:

Identify changes to identity information from many sources.

Propagate those changes automatically to other directories as appropriate (i.e. as

defined by rules which have been configured to support company procedures).

These changes can be modifications to attributes or to whole objects. This change

detection infrastructure keeps the directories synchronized.

Data Enforcement

Data ownership issues often prevent effective coordination of an institution‘s identity

information even though it may be technically possible. Certain departments maintain a

strong ownership of their data. Although ownership of data is not an issue when

directories remain separate, retaining ownership when data is synchronized among

multiple directories becomes more challenging. To address data ownership issues you

can use a metadirectory system to:

Enable administrators to define and enforce ownership relationships at the attribute

level.

Allow, block, or reverse changes made to identity information. If a change to data is

consistent with the ownership rules it is allowed; otherwise, it is blocked (allowing local

control) or reversed.

Ensure that the departments that own the identity information in a specific directory

will maintain that ownership even when that directory is synchronized with other

directories in the organization.

Data Source

A data source for the Live@edu solution is any place where you have student information

– a directory, database, or other data repository that contains data to be integrated within

ILM 2007. Data sources can be enterprise directories (Active Directory, Novell, ADAM,

etc), databases (Oracle, SQL, etc), or even data in flat files, such as LDIF, DSML or

delimited text.



Management Agent

A management agent is a component of ILM that manages the data associated with a

specific data source and connectivity to the data source. The management agent not only

connects to the data source, but is responsible for managing the flow of data (inbound

and outbound). There is at least one management agent for each data source. For many

management agents, ILM 2007 communicates directly with the data source – these are

call-based and examples of such directories are LDAP and Active Directory. For others,

where a direct call is not possible, an intermediary file is used such as AVP, LDIF or fixed

width – these are file-based management agents. In some cases, the situation may be

more complex: there may be no management agent specifically for the data source or the

data source may, for example, support a mixture of file-based and call-based activities so

that a simple file-based management agent is insufficiently feature-rich. In such a case,

the extensible management agent allows a developer to create code which instructs the

management agent how to communicate with the data source.

Management agents are primarily configured by setting their properties within the

wizard-like interface in the Identity Manager, the application that manages and

configures ILM 2007. There are occasions when more complex operations are desired

than those possible through the user interface (for example, combining the contents of

FirstName and LastName to make a displayName); in this case, a management agent can

be augmented by .dll extensions produced using Visual Basic.NET or C# or, indeed, any

language making use of the .NET Common Language Runtime (CLR). It is not necessary to

write code in most basic implementations of Live@edu, however remember that the

capability is there if needed.

Metaverse

The Metaverse is a set of tables within ILM 2007 that contain the integrated identity

information from multiple data sources. All identity information about a specific student

or object, which is stored in multiple data sources, is synthesized into a single entry in the

metaverse. Your students will most likely have a single unique object in the metaverse

representing each student.

Connector Space

The connector space is a storage area and a staging area. It stores the different states that

are used to decide whether information in a data source has changed, or needs to be

changed. It is also, where changes are staged on their way into or out of ILM 2007. Each

data source has its own logical area in the connector space, which is managed by its

corresponding management agent. The connector space is essentially a mirror of the

related data source, with each object in the data source having a corresponding entry in

the connector space. The connector space does not contain the data source object itself,

but a subset of the object‘s attributes, as defined by the management agent.



Provisioning

When we think of objects in data sources, they will often be accounts, such as an Active

Directory® service account. The term account is often used even for groups, resources,

and so on. Provisioning is the creation of accounts in data sources (such as LDAP

directories, databases, and e-mail systems). Once provisioned, the account attributes can

be managed as those of any existing object. The manual creation (and removal or

disabling) of accounts in several systems is administratively burdensome, prone to errors

and inconsistency, and leaves potential security gaps. For Live@edu, the act of

provisioning refers to the creation of a Windows Live ID account. You can use ILM 2007

to:

Automatically create accounts (objects) in directories, based on their addition in one

(authoritative) directory.

Continue to manage those accounts, including removal (de-provisioning) and

disablement.

Provisioning will occur within ILM 2007 to create the Windows Live IDs in the Windows

Live environment. The Windows Live Management Agent is entrusted to handle this task

on behalf of ILM 2007. This management agent will take the e-mail address of the student

to be provisioned from the data source, connect to the Windows Live server, create the

account and then return the confirmation to ILM 2007. Similarly, should the user who has

an account need to have the account evicted (deleted) from the school namespace, the

management agent will again connect to the Windows Live server to evict the account.

In a simple to management agent System like the ones that are most commonly used for

Live@Edu the flow looks like.

In this example, data is being taken from a connected MA, Say ADMA, brought into the

connector space where Projection or Join rules are applied. From there the provisioning



rules trigger a creation into another connector space, any management agent. Finally, that

management uses an Export operation to push the data from ILM into its systems.

For systems that are more complicated it can look like:

In this example, there are multiple management agents and connector spaces. Here we

have a single data source that projects data into the metaverse. Another management

agent joins to the recently projected entry. This could be an example where you want

your HR/billing system to initiate the create of accounts however you may have an

existing account in a SQL or other data source. There are also 2 MAs that are triggered off

the provisioning code which would create a user. This logic is configurable where it could

create multiple different types of users. For instance a HR system create could trigger

admin accounts in a website or just a single user. The provisioning rules would calculate

that. Note that a single MA isn’t limited to just project or join to the metaverse. As you

can see there are 2 basic types of operations into the metaverse and 1 out. Based on

scenarios you may want to attempt a Join before you do a project. You could also

introduce a join when you have a projection rule. ( into : join & project ; output :

provisioning )

This is the core foundation of ILM and allows for a near infinite of flexibility and

configuration. The design is versatile enough to allow for any number of identity

management scenarios. The scenarios for Live@Edu are really only touching a small

fraction of what ILM can actually do.



Running a Synchronization

During development, a management agent is executed by means of the user interface. In

production systems, it is desirable to run management agents in sequence without user

intervention, both on a scheduled basis, and occasionally in response to specific events

(for example, the submission of a new student registration). Such automated execution of

management agents is achieved using the WMI functions of ILM 2007 in conjunction with

a scheduling agent (described in detail later).

Extensible Management Agents

Management agents allow ILM 2007 to connect to a wide variety of different data sources

to manipulate data from them. While most of the management agents allow for

connectivity to a specific connected data source the extensible management agent has

expanded the ILM 2007 connectivity options by allowing developers to build any

connection they want by simply creating code within the confines of a management agent.

Information is provided in the ILM 2007 developer reference help files and on MSDN.

State Based System

ILM 2007 is a state-based system. There are advantages to this (particularly robustness)

as well as potential disadvantages (extra processing and storage) but the actual result is a

very effective and flexible compromise. ILM 2007 stores a hologram for each external

object of which it is aware; this hologram represents the current view of the data stored

in each data source. During a subsequent import of the data from the data source, the

imported object data is compared with the hologram. If any differences are detected

between the two (for example, the values for the Student Type attribute do not match, or

a new or missing object is detected), a change is inferred and the change is passed to the

ILM 2007 Sync Engine to be propagated through the metadirectory. In a deployed system,

management agent runs are invoked by scheduled scripts, which are run either on a

scheduled basis or in response to external events (perhaps a web portal could invoke a

run to ensure that accounts created through the portal are created). ILM 2007 then asks

for data -- it is a pull system, which avoids the need for a push agent on each data source.

However, ILM 2007 can work with Delta Import (i.e. imports of only those objects that

have changed; as it happens, Exports are always delta in nature). Some data sources

support this already, others may be able to with some modification, yet others simply

cannot support this feature. Where deltas can be used, there are considerable savings in

processing time (traffic and state comparisons). Depending on how many students are

being processed by the system and the frequency of the processing, designing the data

source to provide ILM 2007 with delta updates may be extremely important. ILM 2007

can work entirely with Full Imports, minimizing the intrusion on data sources;

additionally, it is sometimes necessary to use a Full Import (for example on initial import

or when recovering from a data source failure).



Lesson Review

Topics covered in this lesson include the following:

How ILM operates

The Concept of the Metaverse

ILM being a State based system

Answer the following questions to confirm your understanding of lesson topics.

1. How does ILM work?

ILM operates through a series of connected MAs import and export data. Based on provisioning rules action is taken on the various objects and data is synchronized across. It has the ability to connect to multiple directory sources and is extensible enough to handle new ones.

2. Question

Answer



Lesson 2: Live@Edu Specific Management Agents

This lesson will explain more of the specifics of ILM with regards to Live@Edu. As you

read above ILM depends on connected Management Agents to enable data access

between the various components.

What You Will Learn

After completing this lesson, you will be able to:

Understand our MAv2 Offering

Understand our MAv3 Offering

Understand OLSync

Module 6: Identity Lifecycle Manager DRAFT V1.1 Lesson 2: Live@Edu Specific Management Agents


Management Agent V2 for Windows Live

Originally, Live@Edu's management agent was developed by an MCS consultant as a

means to integrate MIIS 2003, ILM 2007's predecessor, to Windows Live. The original

version, MAv1, was truly a first release product and functioned well. It did what it was in

scope to do.

Sortly after MAv1 was released it became apparent that the onboarding process for

Live@Edu needs to change drastically. We used to only be able to configure schools once

per quarter and depended on several other teams at Microsoft for provisioning. We

wanted to allow schools to onboard more quickly and shorten the pipeline.

MAv2 was the way to accomplish it. During the upgrade process from V1 to V2 we

changed a number of things dramatically.

V2 required the use of certificates instead of Username/Password authentication

V2 required network ACLs be put in place to allow for SCS offers to be provisioned

With these changes we were able to more agile deploy customers and speed up the

onboarding process to once per Quarter to a month deployment cycle.

How does MAv2 actually work?

MAv2 makes direct calls to SCS, LiveID, and Hotmail to handle account provisioning. As

we learned in Module 2 this can use a Certificate and SiteID. SCS is a unique platform and

only accepts certificate authentication. This requirement drove the change from V1 to V2

to use certificates. The same certificate that was uploaded to IDSAPI is the same one

configured in SSAPI, SCS's API. The relationships look like:



Inner workings

MAv2 creates accounts differently than the sequence diagram that was presented earlier.

You can see the updated flow below:

Here we see that MAv2 communicates directly with each service. Note that it has built in

error handling to overcome communication glitches like a timeout to LiveID on create

credential where it actually succeeded but we didn't get the data in time. In that instance

we automatically use another call in LiveID, GetNetIDFromSigninName, to get the NetID

for the account.

After the Credential and Profile or Passport are created then we initiate a call to Hotmail

to login to the mailbox. This is to set any specific language/region code on the mailbox

that the administrator might have defined.

Finally, we call SCG to stamp the mailbox with the Live@Edu specific offers. This enabled

them to have features like No Ads, Pop3 access, and higher levels of sending capabilities.

If the Hotmail mailbox doesn't exist then this call will automatically create the mailbox

with the data it has. If the customer has specified timezone or language it will not be

Module 6: Identity Lifecycle Manager DRAFT V1.1 Lesson 2: Live@Edu Specific Management Agents


configured on the mailbox by default. This was a problem previously as MAv2 would not

"wait" for a call but would call Hotmail and SCG at the time. Hotmail would normally win

but there were instances where SCG would win causing problems on the mailboxes.

Note that MAv2 is a one directional MA in that it only pushes information to the various

services. It does not have an Import capability.

Configuration Files

The MAv2 management consumes 3 different configuration files for various tasks. First

there is the PassportMA_GlobalConfig.xml. This file contains the primary set of

information that the MA uses to connect to LiveID, SCG, and Hotmail. This file contains

certificate identification in the form of the Subject Key Identifier or SKI of the certificate,

the SiteID, and endpoints for both Hotmail and SCG. During the labs you will have an

opportunity to configure these files.

Next there is the PassportMAProvisioningConfig.xml. ILM out of the box cannot provision

accounts on its own. It requires Provisioning Code to instruct it to create connectors. We

use a baseline provisioning code that reads from this XML. Specifically we look for a

couple things like the Name of the MAv2 MA, the Object inside ILM you are using, and the

email address attribute you have configured. This config file takes any metaverse

projection and creates a new connector in the MAv2 MA. This new connector ultimately

becomes a new LiveID and mailbox.

Finally we have the PassportMADomainRules.xml. This config file allows users to set

domain level attributes for their users. For instance if you use ILM to create both Student

and Alumni domains then you may want to provision offers on the student domain but

not on the Alumni. Additionally if you are multistate or multinational school you may

want to set a unique time zone for the various domains with different language codes.

This config file allows these per domain configurations. Note that any attribute flows

created for these values will overwrite what is configured in this file.



Lab 1: Configure your own MAv2 domain 1. Create and configure an ILM Service Account

a. Assign it to the Local Admin Security Group.

2. Create and Configure a SQL service account

3. Install SQL with a default instance and use the SQL Service Account

a. Select SQL Server Database Services

b. Select the Default instance

c. Configure it for Windows Authentication

4. Install ILM using the ILM Service Account

a. Install from: Desktop\ILm 2k7\Disk 1\MIIS\Setup\Microsoft Identity

Integration Server

b. Backup the Encryption Key for the DB on the Desktop.

5. Create a Delimited Text File MA

a. Open Identity Manager

b. Click Management Agents

c. Under Actions Click Create

d. Select Delimited Text File and use StudentMA as the name

e. For Input Text File use the template at Desktop\Files\Users.csv

f. Click “Use First Row for Header Names” and set Comma as the delimiter.

g. Set the EmailAddress as the Anchor Attribute

h. Under Join and Projection Rules click New Projection Rule to Person. (Just click

“New Projection Rule” and click OK

i. For Attribute Flow put the Email Address in the Mail Attribute and make it an

Import flow. Put the password in comment and name in display name.

j. Create a Full Import and Full Synchronization run profile on the MA.

i. At Identity Manager under Management Agents Click Configure Run

profiles on the new MA

ii. Click New Profile

1. For the name use FIFS

2. Under the type select Full Import and Full Sync.

3. For the Input file name copy the template file we used earlier to

Program Files\Microsoft Identity Integration Server\MA

Data\StudentMA then select that file.

6. Create the Windows LiveID Management Agent

a. Install the Management Agent from Desktop\Files\MAv2. Run Setup from an

elevated command prompt.

b. Set the type to Windows LiveID and name it LiveIDMA

c. Leave Configure Connection Information Blank

d. Go to Configure Attribute Flow

i. Create an export flow for Mail -> Signin Name

ii. Comment -> TempPassword

e. Click through and complete.

Module 6: Identity Lifecycle Manager DRAFT V1.1 Lab 1: Configure your own MAv2 domain


7. Copy over the new PassportMA_Globalconfig.xml from Desktop\Files\MAv2\MA to

c:\program files\Microsoft Identity Integration Server\Extensions.

8. Install the Certificate by Double Clicking on “WindowsLiveIDExtensibleMA.msi”

selecting Install Certificate Only. Use the Certificate in Desktop\Files\MAv2\MA.

9. Configure the PassportMAProvisioningConfig.xml with the Name of the WindowsLiveID

MA and the mail Attribute. It’s located at c:\program files\Microsoft Identity Integration

Server\Extensions.

10. Restart the MIIServer.exe process.

11. Create a new User

a. Add a user to the Text File

b. Full a FIFS on the StudentMA

i. You should see a pending Export

c. Run an Export

i. Did the Account create properly

12. Login to that account at http://mail.live.com

Estimated time to complete the exercise(s): 60 minutes

http://mail.live.com/



Management Agent V3

The Management Agent V3 is the final evolution of the Hotmail based management agents

for ILM. It allows a much more convent interface for account provisioning and

maintenance. This management agent is titled MAv3 for convince but really it is called the

Windows Live Custom Domains Management Agent or WLCD MA. This is because it was

written by an engineering team at Microsoft called SyndC. The original name for their

project was Windows Live Custom Domains before it was renamed to Windows Live

Admin Center.

How does it work?

The account provisioning stack for MAv3 looks like:

Here we see that MAv3 calls SyndC to do most of the work. This is the primary difference

between MAv2 and MAv3. Because MAv3 leverages the SyndC platform, Admin Center,

we were able to significantly speed up the onboarding time. Infact you went through that

same onboarding process when you enrolled your Hotmail domain. The process that used

to take weeks to be configured reduced to minutes.

The other advantage about using SyndC was this brought a significant improvement to

the account provisioning process. With it as the intermediary we no longer had to worry

about transient network issues that would disrupt account provisioning. SyndC was

always intended to be a consumer API whereas LiveID was primarily built for internals.

This new found resilency eliminated a significant number of support calls.

MAv3 also ended the sole dependence on certificates. With the SCG calls now done by

SyndC we were able to offer users the choice on how they wanted to authenticate. They

Module 6: Identity Lifecycle Manager DRAFT V1.1 Lab 1: Configure your own MAv2 domain


could use a certificate or they could use Username/Password. It was up to how they

wanted to implement their service.

Inner Workings

MAv3 follows the same account provisioning sequence diagram that was shown earlier in

Module 2. Here it is again for reference.

As we can see the calls between MAv2 and MAv3 are very similar. The biggest change is

that SyndC operates as an intermediary and has some business logic built in. This takes

care of some privacy concerns around Hotmail and mailboxes. For instance in MAv2 if

you deleted an account and recreated it immediately the new account would have access

to the previous accounts mailbox.



Config Files

MAv3 like Mav2 relies heavily on config files. Here the first file is the

WLCDGlobalConfig.xml. This file is effectively a merger between the

PassportMA_GlobalConfig.xml and the PassportMADomainRules.xml files. Here users can

configure a certificate for authentication and various domain settings like mentioned

above.

The second config file is the WLCDProvisioningConfig.xml. This file is virtually identical to

the one for MAv2. Its sole job is to take in configuration data for the provisioning rules

inside of ILM. It has the same required attributes as MAv2.

Module 6: Identity Lifecycle Manager DRAFT V1.1 Lab 2: Configuring MAv3


Lab 2: Configuring MAv3 1. Create and configure an ILM Service Account








a. Install from: Desktop\ILM 2k7\Disk 1\MIIS\Setup\Microsoft Identity

Integration Server


5. Create a Delimited Text File MA

a. Open Identity Manager

b. Click Management Agents

c. Under Actions Click Create

d. Select Delimited Text File and use StudentMA as the name

e. For Input Text File use the template at Desktop\Files\Users.csv

f. Click “Use First Row for Header Names” and set Comma as the delimiter.

g. Set the EmailAddress as the Anchor Attribute

h. Under Join and Projection Rules click New Projection Rule to Person. (Just click

“New Projection Rule” and click OK

i. For Attribute Flow put the Email Address in the Mail Attribute and make it an

Import flow. Put the password in comment and name in display name.

j. Create a Full Import and Full Synchronization run profile on the MA.

i. At Identity Manager under Management Agents Click Configure Run

profiles on the new MA

ii. Click New Profile

1. For the name use FIFS

2. Under the type select Full Import and Full Sync.

3. For the Input file name copy the template file we used earlier to

Program Files\Microsoft Identity Integration Server\MA

Data\StudentMA then select that file.

6. Create the Windows Live Custom Domains MA

a. Enter Connection Information for your domain admin. (Just Username and

Password)

b. Configure the Attribute Flows for name, Email Address, and Password just like

MAv2.

7. Configure the WLCD MA

a. Configure the WLCDProvisioningConfig.xml with the name of the Custom

Domains MA and set the email address to Mail.

b. Add any values you want to the WLCDGlobalConfig.xml.



c. Restart the MIIServer.exe in the Services MMC snapin.

8. Create a new User

a. Add a user to the Text File

b. Full a FIFS – See a pending Export?

c. Run an Export

9. Run the FIFS run profile you created

10. You should see Pending Exports

11. Run Export on the Windows Live Custom Domains MA.

Estimated time to complete the exercise(s): 45 minutes



Outlook Live Directory Sync

Outlook Live directory Sync or OLSync is an end to end provisioning solution developed

by the Exchange Team. The key difference between OLSync and MAv2/3 is that it includes

and configures the source ma for you. There are also a predefined set of logic used to

determine how accounts are to be created and what objects should be created.

One of the big challenges with OLSync is the various kind of objects it can provision. In

several situations OLSync can create Mail users, Mailboxes, or Mail Contacts. The default

rules created by the Exchange Team govern these scenarios and business logic.

How Does OLSync Work?

Because OLSync is an end to end solution it normally would be more complicated to

configure. The Exchange Team invested a lot and developed a simple way to install and

configure the MA. A fully automated installer detects and configures itself for the

environment it is going into. We have different configurations for:

Active Directory only system

Exchange 2003

Exchange 2007

Exchange 2010

These configurations are detected by the schema in AD. The AD Only profile is the most

basic implementation and does not provision to multiple object types inside Outlook Live.

Inner Workings

The most complex scenarios in OLSync first come from the default filtering it has enabled.

For the Exchange versions it doesn't just create accounts at will. Before they are

processed by ILM they must made it by the filter rules:

1. Recipient objects that don't have required attributes ILM reads the following

recipient objects. If any of the required attributes are empty (null), the recipient object

is filtered out.

Recipient object type Required attributes

Mailbox-enabled user mail, legacyExchangeDN,

proxyAddresses

Mail-enabled user mail, targetAddress



User (AD DS or Active Directory only; no

Microsoft Exchange installed)

mail

Mail-enabled contact mail, targetAddress

Distribution group, dynamic distribution

group, or security group

mail, proxyAddresses,

mailNickName

2. Recipient objects where the adminCount attribute is set to 1 The adminCount

attribute is used to identify users in protected administrator groups, such as the

Domain Admins and Administrators. If the adminCount attribute is set to 1 on any

recipient object, it is filtered out.

3. Mailbox-enabled user objects that are specified as mailbox plans, discovery

mailboxes, or arbitration mailboxes The msExchRecipientTypeDetails attribute

is used to identify mailboxes that are specified as mailbox plans, discovery mailboxes,

or arbitration mailboxes. These mailbox-enabled users are filtered out.

4. The mail attribute on an AD DS or Active Directory-only user that doesn't match

the provisioning domain In an on-premises environment where Microsoft Exchange

hasn't been installed, OLSync filters out all user objects where the mail attribute

doesn't contain an SMTP address that matches the provisioning domain.

5. The attribute used to generate the Windows Live ID doesn't match any of the

accepted domains The final pass filters out recipient objects that are configured for

auto-provisioning but don't have an accepted domain match in the attribute that is

used to generate the Windows Live ID.

The attribute used to generate the Windows Live ID must contain a domain name that

matches one of the accepted domains that you have configured in Outlook Live. As

described in step 4, by default, OLSync looks to the user principal name (UPN) for a

match unless you have set the MVWindowsLiveIdAttributeName parameter to use a

different attribute. In this case, OLSync matches the SMTP address that is stored in the

attribute that you have specified in the MVWindowsLiveIdAttributeName parameter. In

any case, if OLSync can't find a match to an accepted domain, the recipient object is

filtered out.

Once they get past the filtering rules then they make it into the provisioning rules. They

can best be described by the scenarios below.



Beyond the provisioning scenarios there are a number of parameters that are configured

inside OLSync. Note these parameters themselves are stored in an XML file but that XML

file is not the authoritative source. OLSync automatically populates that XML file during

each Sync so that it can be used by other processes like PCNS.

Parameter name Default Description Recommendatio



paramete

r?

n

ProvisioningDom

ain

Yes.

If you

configured

OLSync

with a

OLSync

service

account,

the

Provisioni

ngDomain

parameter

is set to

the

domain

that you

specified

in the

Windows

Live ID for

that

account.

If you

configured

OLSync to

use

certificate-

based

authentica

tion

instead of

a service

account th

e

Provisioni

ngDomain

parameter

will be

empty and

The

ProvisioningDom

ain parameter is

required. It must

include at least

one accepted

domain in

Outlook Live.

The

ProvisioningDom

ain parameter is

used as a trigger

to auto-provision

mailboxes in

Outlook Live.

Only an accepted

domain can be a

provisioning

domain.

You can add

multiple domains

to this parameter

separated by

semicolons, for

example,

contoso.edu;

fabrikam.edu.

Do not remove

domain entries

from the

ProvisioningDom

ain parameter

after you have

run a

synchronization

cycle. To change

a provisioning

domain, add a

new domain

name to this

parameter.

After users are

provisioned,

changing the

value of the

ProvisioningDom

ain parameter

doesn't remove

those user

accounts.

Accounts that

have been

created in

Outlook Live will

remain and are

represented in

ILM by a GUID in

the metaverse.

Therefore, the

user accounts

will continue to

be updated

according to the

changes on the

source object in

the on-premises



you have

to set it.

Note Cert

ificate

authentica

tion is no

longer

supported

for new

installatio

ns of

OLSync.

Active Directory

Domain Services

(AD DS) or Active

Directory

directory service

as long as the

object exists in

the ILM

metaverse.

ResetPasswordOn

NextLogon

Yes.

Default is

True.

Setting this

parameter to

True will force

users to reset the

password on

their new

Windows Live

account when

they sign in for

the first time.

This is the default

behavior.

This parameter

doesn't apply if

you are running

Outlook Live in a

Connected

Federation

deployment.

Connected

Federation

passwords are

managed by the

on-premises AD

DS or Active

Directory. As a

security best

practice, you

shouldn't set this

parameter to

False.

MVWindowsLiveI

dAttributeName

Yes.

Default is

UserPrinci

palName

The

MVWindowsLiveI

dAttributeName

parameter

defines how

OLSync provision

s the Windows

Live account

names in Outlook

In an

environment

where Microsoft

Exchange isn't

installed on-

premises, if the

MVWindowsLiveI

dAttributeName

parameter is set



Live.

By default,

OLSync names

new Windows

Live accounts

according to the

userPrincipalNa

me (UPN)

attribute on the

on-premises

recipient object.

Therefore, when

OLSync

provisions new

accounts in

Outlook Live, the

new Windows

Live ID matches

the on-premises

UPN for the

corresponding

account.

The

MVWindowsLiveI

dAttributeName

parameter takes

any attribute

name. For

example, you can

enter

customAttribute

1 if you are

flowing a custom

attribute from

the on-premises

extensionAttrib

ute1 attribute.

You must only

enter attributes

that hold a single

SMTP address

to null,

OLSync uses the

mail attribute to

name the

Windows Live

IDs for the

Outlook Live

mailboxes that

are provisioned.

In an

environment

where Microsoft

Exchange is

installed on-

premises, and if

the

MVWindowsLiveI

dAttributeName

parameter is set

to null,

OLSync uses the

primary SMTP

Address in the

proxyAddresses

attribute on-

premises to name

the Windows

Live IDs for the

Outlook Live

mailboxes that

are provisioned.



value. For this

reason, don't

enter the

proxyAddresses

attribute for this

parameter. If you

want to flow the

primary SMTP

address from the

on-premises

mail-enabled

users or mailbox-

enabled users,

leave the

MVWindowsLiveI

dAttributeName

parameter

empty. The video

demonstration at

the end of this

topic shows how

to configure the

primary SMTP

address as the

provisioning

SMTP address.

Do not remove

the

MVWindowsLiveI

dAttributeName

parameter from

the Additional

Parameters page.

If the

MVWindowsLiveI

dAttributeName

parameter is

removed, OLSync

uses the UPN

value.

DisableWindowsL Yes. Set the Although the



iveId Default is

False.

DisableWindowsL

iveId parameter

to True to disable

Windows Live

accounts when

the on-premises

source account is

removed. When

the Windows

Live account is

disabled, it is

removed and the

owner of the

Windows Live ID

loses all

Windows Live

services.

If you leave the

DisableWindowsL

iveId parameter

set to False,

Windows Live

accounts whose

corresponding

on-premises

source account is

removed are still

able to access

Windows Live

services.

However, the

corresponding

Outlook Live

mailbox or mail-

enabled user

object is deleted.

Important Be

careful when you

move on-

premises objects

between

organizational

default behavior

is False, the

recommended

setting for the

DisableWindowsL

iveId parameter

is True. When it

is set to True,

after a mailbox is

deleted, the

owner of the

Windows Live ID

associated with

that mailbox can

use the Windows

Live ID for other

services by

renaming the

Windows Live ID

the next time

they sign in. If

this parameter is

set to False, after

the mailbox is

deleted, the

Windows Live ID

can't be used

again except for

association with

a new mailbox.



units in AD DS or

Active Directory.

For example, if

you move objects

that are

provisioned as

mailboxes in

Outlook Live to

an on-premises

organizational

unit that isn't

configured to be

synchronized

with OLSync, the

corresponding

mailboxes in

Outlook Live will

be deleted.

PasswordFile Yes.

Default is

report\pa

ssword.x

ml

Specify the name

and location of

the password file,

for example,

D:\admin\pwd.x

ml.

If a file name is

provided, the

default path is

<system

drive>:\Program

Files\Microsoft

Identity

Integration

Server\MaData\

Hosted\.

When OLSync

provisions a new

Windows Live

account in

Outlook Live, the

password for the

new Outlook Live

Initial passwords

for each Outlook

Live mailbox or

Windows Live

ID-enabled

synchronized

user are stored

cumulatively in

the password file.

You must

distribute the

initial passwords

to your users. By

default, the

ResetPasswordOn

NextLogon

parameter is set

to True, so users

are forced to

change the

password when

they sign in for

the first time.



account is

written to the file

that is specified

in this parameter.

We recommend

you specify a

secured directory

for the password

file.

SyncProxyAddress

Protocol

No By default,

OLSync

synchronizes SM

TP and X500

addresses in the

ProxyAddresses

attribute from

the on-premises

recipient object

to the

corresponding

Outlook Live

object. Set the

SyncProxyAddress

Protocol

parameter to

synchronize

other protocol

address types.

For example, you

can synchronize

additional

protocol address

types such as SIP

by setting the

SyncProxyAddress

Protocol

parameter to SIP.

You can add

multiple protocol

address types to

this parameter

separated by

semicolons, for

example, EUM;

Set the

SyncProxyAddress

Protocol

parameter only if

an additional

protocol is

required by your

Outlook Live

feature set.



SIP.

Valid values for

this parameter

are determined

by the protocol

address types

that you have

stored on the

ProxyAddresses

attribute on

recipient objects

in your on-

premises Active

Directory.

If you remove an

additional

protocol address

type from this

parameter after

you run a full

synchronization,

OLSync removes

the addresses on

the

corresponding

Outlook Live

recipient object

during the next

full

synchronization.

EvictLiveIdOnCre

ate

No An e-mail as sign

in ID (EASI ID) is

a Windows Live

ID that was

created in a

domain

namespace

before Outlook

Live was

deployed in the

same domain

Set the

EvictLiveIdOnCre

ate parameter to

True if you want

all provisioned

accounts in your

Outlook Live

domain to match

the

corresponding

on-premises



namespace.

For example, a

student at

Contoso

University may

have created a

Windows Live ID,

KwekuA@contos

o.edu, before

Contoso

University

enrolled in

Outlook Live.

After Contoso

University

establishes a

contoso.edu

Outlook Live

domain, the

Windows Live ID,

KwekuA@contos

o.edu, is an

unmanaged EASI

ID in the Outlook

Live contoso.edu

domain.

By default, when

OLSync tries to

create a mail-

enabled user or a

mailbox-enabled

user in Outlook

Live where a

matching EASI ID

already exists, an

error is logged

and a recipient

object in Outlook

Live isn't created.

You can change

this behavior by

accounts.

Setting the

EvictLiveIdOnCre

ate parameter is

recommended

for organizations

that are running

in a Connected

Federation

environment.

If your

organization isn't

running in a

Connected

Federation

environment, you

should consider

importing

existing

Windows Live

accounts for

users in your

organization that

already have a

Windows Live ID

in your domain.

For more

information, see

Import or Evict

Existing

Windows Live

IDs.

http://help.outlook.com/en-us/140/dd219462.aspx






setting the

EvictLiveIdOnCre

ate parameter to

True. When you

set the

EvictLiveIdOnCre

ate parameter to

True, the EASI ID

is evicted from

the domain and

new recipient

objects are

created in the

Outlook Live

domain

according to their

corresponding

on-premises

names.

When a Windows

Live account

status is set to

"evict," the

account is in a

state that forces

the user to

rename the

Windows Live ID

the next time the

user signs in.

After the user

renames the

Windows Live ID

to an unmanaged

domain name,

the account is

fully functional

again.

Inside OLsync we include a script that users can run called StartSync. This script will

automatically run the various run profiles for users in the correct orders. Users are not



required to manually create run profiles like they had to for the other management

agents.

Module 6: Identity Lifecycle Manager DRAFT V1.1 Additional Resources


Additional Resources Implement Outlook Live Directory sync






Lab 3: Outlook Live Directory Sync 1. Create and configure an ILM Service Account



3. DC Promo the Machine and create a new domain that matches

a. Use the Domain <Alias>.Contosou1.com

b. IP Configuration Dynamic.

c. Connectivity: Needs internet access over Https/Http

d. Domain Functional Level: 2003

e. DNS: Yes Please install DNS






a. Install from: Desktop\ILM 2k7\Disk 1\MIIS\Setup\Microsoft Identity

Integration Server


6. Install ILM Updates

a. Desktop\Files\ILM Hotfix.exe

b. Desktop\Files\ILM PowerShell CMDLets

7. Create a New AD OU for OLSync to pull accounts from.

8. Install and Configure OLSync

a. Desktop\Files\OLSync_R4_V2

b. Follow the OLSync Install instructions from http://help.outlook.com/en-

US/140/dd490636.aspx

9. Configure the Password Extension for OLSync

a. Double Click the OLMA MA

b. Click Configure Extensions

c. Click Connection Information for Password Extension

d. Enter Username/Password and Connection URL.

10. Configure the Provisioning domain in the Hosted (OLMA) config for the

<Alias>contosou1.com domain.

11. Create a user account in AD in the New OU and Assign the Email Address within

contosou1.com.

12. Use the StartSync.PS1 script to create the user (StartSync.ps1 -FirstRun)

a. It’s in c:\Program Files\ Microsoft Identity Integration

Server\SourceCode\Scripts folder

13. Install PCNS

a. Files\PCNS.exe

14. Configure the SPN and PCNSConfig.exe

http://help.outlook.com/en-US/140/dd490636.aspx

http://help.outlook.com/en-US/140/dd490636.aspx

Module 6: Identity Lifecycle Manager DRAFT V1.1 Lab 3: Outlook Live Directory Sync


a. Setspn.exe -A SPN PCNSCLNT/<TargetServerName>

<Domain>\<ILMServiceAccount>

b. Pcnscfg.exe addtarget /n:Demo /a:<FQDN Of the TargetServer> /s:<SPN Set

Above> /fi:”Domain Users” /f:3

i. /N is the Name of the target. Anything

ii. /A is the FQDN of the target Server. In this instance it should be the

FQDN of the Lab machine

iii. /S is the SPN configured above

iv. /FI is the included users group. Anyone belonging to Domain users will

have their passwords synced to ILM

15. Enable PCNS inside ADMA

a. Double click on ADMA

b. Select Configure Containers

c. Click “Configure Password Synchronization Targets”

d. Select hosted

16. Attempt a Password reset on the user you created.

Estimated time to complete the exercise(s):75 minutes



Module Review Topics covered in this module include the following:

Topic 1

Topic 2

Answer the following questions to confirm your understanding of lesson topics.

1. <Question>

Answer

2. <Question>

Answer

Module 6: Identity Lifecycle Manager DRAFT V1.1 Additional Resources


Additional Resources <Title>

Presenter | Author: <Names>

Recorded: <Conference, Month, Year>

<Abstract>

Link to Source doc on Web

Link to copy in local \Additional_Resources folder



Education

Live@edu ilm2007