About this blogThis blog started out being about MIIS, but has extended to whatever I happen to be working on - particularly when I've had to struggle through incomplete documentation, blog and forum trawls, and good old trial and error to work through a problem. The posts reflect my own homegrown approach to problems I encountered and are entirely based on my own experiences - I will try to avoid theorising!
Copyright NoticeAll text in this blog is original and the copyright is owned by the author. You are welcome to use the code (without warranty) but please do not copy the articles without asking first.
My social media policy
+ I will only accept facebook friend requests from people I know in person.
+ I will only accept linkedin requests from people I have worked with or had at least a few email exchanges with (remind me on the request if this is the case).
+ You are of course welcome to follow me on twitter (@miss_miis).
AD Best Practice BPOS Conferences Exchange 2007 Exchange 2010 FIM 2010 FIM 2010 R2 FIM Sync Service Groups ILM "2" ILM 2007 Logs MIIS 2003 MiisApp MPR newbie Office 365 Philosophising powershell RCDC Reporting Sets SQL Troubleshooting Uncategorized Unify VB.NET VBScript Workflow
- Kim Cameron
- Jackson Shaw
- Tomek Onyszko
- Brad Turner
- Jorge de Almeida Pinto
- David Lundell
- Henrik Nilsson
- Thomas Vuylsteke
- Anthony Ho
- Joe Zamora
- Darryl Russi
- Gil Kirkpatrick
- Peter Geelen
- Bob Bradley
- Craig Martin
- Blain Checkley
- Eihab Isaac
- Brjann Brekkan
- Joe Schulman
- Predica Team blog
- Nishant Kaushik
- Dave Nesbitt
- Paul Williams
- Wortell blog
- Peter Stapf
- Kim Cameron
Let’s start with a statement that can be made about any design: good design makes sense, it is coherent, it is self-evident and doesn’t need a lot of explanation.
While a simple IAM solution would be a fine thing, the reality is that we must deal with complexity in technical connectivity, data, business rules and processes, and what’s more, all these aspects should be expected to change over time. I firmly believe that good solution design means doing everything I can to minimise complexity by, for example, being fastidiously consitent with schema and naming conventions, doing similar actions in a similar way throughout the solution, and keeping all changeable configuration parameters and logic rules in one place.
I find the most efficient way to identify poor design is to try and explain, or even better, demonstrate it to someone else. Sometimes just hearing my own explanation is enough for me to think “that sounds ridiculous” – without even having to take their confused expressions into account.
Another fantastic way to improve design is to write the Operations Guide. If it takes you 5 pages to explain how to perform an operational task you have done it wrong.
The key point is that you should be doing this as part of designing and building the solution. If you leave the demos and operational documentation until you’re at the point of going into production, you’ve left it far too late.
This week I battled with an error from the OOB SQL MA for MIM 2016 (which I don’t think has changed at all from FIM 2010, and probably not earlier versions as well). The MA was working with a SQL database table on a server in another, non-trusting AD forest, and using Windows authentication. The table then got moved to yet another non-trusting forest and, when I tried to update the MA settings, I got:
Failed to retrieve the schema. Exception from HRESULT: 0x80231100
For those that just want to know the answer – it had something to do with clear text AD credentials being blocked, and the workaround was to create a SQL account and connect with that instead.
Sometimes I want to simulate connectivity from an application another way, usually for troubleshooting or verifying networks and accounts have been set up correctly. One thing that’s always been difficult is testing I can connect to a SQL database in a non-trusting domain, using an AD account in the other domain. I can’t hardcode credentials in the connection string, as that’s only for SQL accounts, and I can’t use RUNAS with the foreign account.
Then I read about RUNAS /NETONLY which just runs the over-the-network parts as a different account, so in this post I’m going to share a simple SQL query script, which does not need the SQL Management client or full SQL module installed, and can be used with RUNAS /NETONLY.
The “ideal” IAM solution would have a reliable flow of pre-checked data and a list of sound, proven business rules from which to provision all the accounts and access each person needs to do their job.
This is a fantasy.
The types of work people do, and the IT landscape they do it in, are increasingly fluid and, while we might be able to make “broad brush stroke” access rules, there is still going to be a percentage of access that must be requested, special user accounts that don’t fit the proscribed mould, and genuine emergencies. Our IAM solution must be designed with this expectation.
Automation isn’t just about replicating an existing manual processes. Yes we want the same end results, but the process will have to be different because it’s a dumb computer doing it and not a human.
Humans are really good at spotting patterns, including ones we’ve never seen before. A human operator will be able to say “this looks right”, and also “this doesn’t look right, I’d better tell someone”. We can’t realistically design IAM solutions to do that for all possible permutations of “looks right” and “doesn’t look right” – so our designs must include the expectation that bad data will come through, the IAM solution will have no way to “know” the data is bad, and undesired results may ensue.
Integration between IT systems is hard, even when they support common standards, so I understand this desire for a service tool that does “everything”. IAM software platforms are typically extensible in various ways such as scripting, custom schema and custom workflows, so it may well be that you can do something a bit out of the ordinary, but should you? Software is developed with certain uses in mind and trying to force it into some other shape is rarely good for the on-going effectiveness and maintainability of the solution.
Some “un-natural” things I’ve seen people try to do with their IAM solution: handling service tickets, service catalog, access audit in external systems, asset management, general purpose ETL and orchestration, non-IAM aspects of application administration.
It occurred to me while fighting with this over the last couple of days that I have never installed the MIM Portal in anything other than a lab. FIM Portal yes, but then only on SharePoint 2010 (even after 2013 was available, because it was a heck of a lot easier). While I know MIM 2016 SP1 ican now run on Windows Server 2016 and SharePoint 2016, the customer’s SOE is still the earlier versions. Also I had (perhaps too optimistically) assumed I’d be better off with Sharepoint 2013 because of this walkthrough.
There are a few problems with following this walkthrough, which is written for a lab, in a customer installation. Domain Admin accounts are used, it uses server names rather than aliases, and the SharePoint site is installed on port 82 for some reason. So I thought it worthwhile writing up my steps for reference.
When collecting requirements for an IAM solution we associate actions with various ways of categorising users – in other words, we are mapping “form” to “function”. When designing the IAM Solution, however, we need to provide a layer of separation between the two. The best way to illustrate why is with a real-life example.
I’ve really been trying to improve my skills at capturing and writing up requirements and one thing that helps is to list all the typical identity “lifecycle events”, along with:
- How to detect the event, and
- What to do when the event is detected.
So for each target system I will have a table like the following. The “Lifecycle Events” I’ve listed I think are fairly universal. How you detect them (the “Trigger”), and what actions the IAM solution takes will of course be solution-specific. In some cases the IAM Solution’s action will be “none”, but that should still be documented.