Identity Engineering

One of the first things I do when building a new FIM service instance is to create an admin account for myself, so I can use PowerShell tools, log into the portal etc without having to use things like runas to log in as the built-in admin account. While you can create a resource manually in the portal, you can't easily set the binary ObjectSID value on the resource, and without that, you can't log in. Manipulating binary attributes quite tricky to do with the out of box tools. To set the users up properly, you usually have to flow them in from the AD MA with the ObjectSID present. Which can take quite a bit of effort. I prefer to cheat, and get my own account into the portal via script. The Lithnet FIM/MIM Service PowerShell Module  has first-class support for binary attributes, so using this to add the ObjectSID is just as easy as it is to set a string value. This script will add the specified AD user to the FIM/MIM service and add them to the administrators...

The Lithnet FIM/MIM Service PowerShell module (LithnetRMA) allows you to not only drastically reduce the code you have to write to perform basic create, update and delete operations, but it’s significantly faster than the out-of-box FimAutomation module too. I love hearing reports from people about how they were able to cut hours off the execution time of their existing scripts by converting them to use LithnetRMA! Read about how Jon got a script down from 22 hours to 6 mins using the Lithnet #fim2010 PowerShell module. Awesome! https://t.co/bVr1dHx7ey — Ryan Newington (@RyanLNewington) October 9, 2015 Read about Ike's performance improvements using Lithnet #fim2010 PowerShell module - 12 hours down to 30 minutes! http://t.co/KVpv4qreV1 — Ryan Newington (@RyanLNewington) September 2, 2015 One of the biggest speed advantages that LithnetRMA has over the out-of-box FIMAutomation module is that it supports composite updates. Composite updates combine multiple updates ...

Thanks to all who came along to my session at Microsoft Ignite today. Here are the resources I presented at today’s session WIN332 – From Fortran to FIM: Dragging your identity management system of our the dark ages. Resources for Engineers and Admins Lithnet ACMA Codeless business rules engine ACMA is a fast, efficient, codeless way of implementing business rules that can create and transform information within your FIM/MIM implementation. ACMA comes with a UI editor for your rules file, a PowerShell module for modifying ACMA objects directly, and a unit testing engine that allows you to test all the rules you have created. Check out the video link below for a more detailed demonstration of the capabilities of ACMA Lithnet Universal MA Rules Extension (UMARE) UMARE is a codeless rules extension for FIM/MIM. It can be used on any MA to perform transform operations on incoming and outgoing identity data. With over 40 transforms available out of the box, including very common scena...

There are many systems out there that just don’t support delta imports. Deltas are important for ensuring speedy and efficient operation of the FIM synchronization engine. While we can’t invent true deltas when the connected system doesn’t provide the information, sometimes its enough to just provide FIM the deltas of what it has changed. This is especially relevant for systems where FIM is mostly responsible for the data in the connected system. What would be handy, is if at export time, we could provide FIM with the confirmed changes made in the target system. While FIM allows us to say that an export was successful, it still expects to confirm those changes took place on the next import operation. What if we could construct our import CSEntryChange objects at export time? The Lithnet.MetadirectoryServices library contains a set of helper classes to make writing management agents and rules extensions a little bit easier. One of the tools it contains is a CSEntryChangeQueue clas...

Summary The FIM Service allows you to query for resources using a subset of the XPath 2.0 dialect. It provides a quite powerful mechanism for searching for resources, but has more than a few curiosities when it comes to constructing queries for different attribute types. The Lithnet FIM Service PowerShell module includes three cmdlets to help take the guess work out of constructing your XPath queries. New-XPathQuery The New-XPathQuery cmdlet creates a predicate that forms part of an XPath expression. The query is the Attribute = ‘value’ component of the expression New-XPathQueryGroup An XPath query group contains multiple XPath query objects, or other query groups, that are combined together with an ‘and’ or ‘or’ operator. New-XPathExpression The XPath expression wraps the query or query group with the appropriate syntax defining the object type (eg /Person[query] ) Working with different attribute types The cmdlets generate the correct syntax for each attribute type,...

The FIMAutomation PowerShell module requires you to write a lot of code to perform even the most basic tasks. Let’s have a look at the following example in which Paul Williams provides some very well-written code for updating the EmployeeEndDate attribute of a user using the FIMAutomation snap-in. Now lets look at doing the same thing with the Lithnet FIM Service PowerShell module The same task requires much less code, and much easier to understand. Perhaps most importantly, we don’t need to understand the inner workings of the FIM Service itself (import changes, put operations, etc) to do something as simple as updating an attribute value. Just get, set, and save.

Keeping track of your FIM Service configuration can seem like a daunting task. Even more so when you have multiple DEV, QA, and production instances that need to be kept consistent. We can make version controlling the FIM service a lot easier with some simple modifications to the schema, some clever scripts and a bit of process control. This post will reference the configuration management capabilities of the Lithnet FIM Service PowerShell module , but the same concepts can apply even when using your own tools. Firstly, break up your FIM service design into components. A component is a collection of resources such as sets, MPRs and workflows that come together to perform a particular function. For example, the self-service password reset functionality can be grouped together as an SSPR component. You might have a group of workflows, sets and email templates that handle expiry notifications. I generally use the following components as a starting point; User Interface (RCDCs, Nav b...

At the University I work for, we recently had an opportunity to redesign our student lab workstation environment from scratch. One of the seemingly simple requirements we had was to ensure that after a certain period of inactivity, users were logged off the machines. Sounds simple right? Microsoft have a KB article that suggests a method to do this, but it’s not the best solution. It uses a screen saver as the timing mechanism, and starts a count-down timer in the background. If the user returns to the computer, they need to click a ‘cancel’ button that appears to stop them from being booted out. Not a very good user experience. We couldn't find anything that did what we wanted. Something that would sit in the background, unobtrusively, and just log a user out after a predetermined amount of time. Oh, and it would be nice to control that amount of time if needed rather easily. Oh, and it would also be nice to disable the auto-logout completely if needed. And if its not asking to...

Lithnet.MoveUser is a command line tool that can be used to change the owner of a profile from one user to another. It is designed to be a replacement for Microsoft's moveuser.exe tool (used for Windows XP), originally included in the Windows Resource Kit, and the Win32_UserProfile.ChangeOwner WMI method, used for Windows Vista and above. The Lithnet.MoveUser tool provides the same functionality as the other tools, but overcomes some of the shortcomings of the Microsoft provided toolsets . It does not require any scripting knowledge, provides a consistent experience across Windows XP, Vista, and Windows 7, and provides detailed logging of progress and any errors encountered. The tool will perform the following tasks Change the owner of the profile to the destination user, and update associated permissions Add the destination user to the same local groups that the source user was a member of If the source account is a local account, then it can either be deleted, disabled, or...

Moveuser.exe Back in the early days of Windows XP, Microsoft released a tool for changing the owner of a user profile from one user to another. Moveuser.exe came in the Windows Resource Kit, and for the most part did an OK job. The most common use was for taking profiles that belonged to local user accounts, and attaching them to domain user accounts. It could also be used for migrating profiles from one domain to another, although the Active Directory Migration Tool (ADMT) was more commonly used for this task. The command line was simple enough; moveuser.exe oldusername newusername It took usernames in format of COMPUTER\username or DOMAIN\username . Once of the other nice things about moveuser.exe is that it also copied a user’s group membership on the local machine. Moveuser wasn't without its problems; Error messages returned by the tool were generally unhelpful. A single Win32 error code can't tell you a lot about why a profile migration might have failed. Moveuser.ex...