Wednesday, August 31, 2011

Annoying little feature got me...

As I was building some new customer FIM 2010 workflows for a customer, I ran into that little annoying feature called Blocked File Protection Control.

I had created my initial Workflow Activity Library for FIM and references the FIM binaries to get access to the FIM activities. As I build my project I received a compiler error saying "Compilation failed. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information."; this had me for several hours.

It turned out that since I had copied the FIM binaries from the FIM server to the Windows 7 developer computer, the OS had detected these files as potential "harmful" (FIM 2010 harmful :-) ?) and blocked these files. The error message that I got from the compiler was very helpful, so it actually took me a few hours to realize what was going on. After unblocking the DLL's I was able to compile.

If you run into this problem, check if the DLL's are blocked; in Explorer, goto Properties on the file and check the general tab for the text "This file came from another computer and might be blocked to help protect this computer".

Monday, August 22, 2011

I love LINQ (even being a FIM guy)

Doing a FIM 2010 project for a customer, I had to crunch an LDIF file and convert some of the data in that file to a valid attribute-value pair file for use FIM 2010. I considered a lot of possibilities but ended up utilizing LINQ a lot throughout the code.

As an example I had to extract the parent department for a distinguished name coming from an X500 directory LDIF file. The distinguished name would be something like this -

cn=Willis Bruce, ou=TSX, ou=TS, ou=T, ou=MOX, l=Denmark, c=DK, o=customername, o=customer holding, cn=Main company

The parent department name is the second ou= element (in this case ou=TS) and to extract that I ended up using - what I think - is simple LINQ statement in a method on my user class -

        public void GetParentDepartment()
        {
            string temp = this.dn.Split(',').Where(key => key.StartsWith("ou=")).Skip(1).FirstOrDefault();
            this.parentDepartment = (temp != null) ? temp.Replace("ou=", "").ToUpper() : null;
        }


Hope this will help someelse crunching data. I know that I will definitely try to use LINQ whereever possible as its is pretty nice and very elegant for many tasks.

Monday, August 15, 2011

Refreshing the FIM portal

Carol Wapshere did a nice post on refreshing the FIM portal when you make changes to RCDC and such. I've taken this to heart and put together a small Powershell script to do the job.

You can use the script like this -

"AppPool name" | .\Recycle-IisAppPool.ps1

i.e. "Sharepoint - 80" | .\Recycle-IisAppPool.ps1

You could even send several AppPool names through the pipeline, i.e.

"SomeAppPool", "Another AppPool", "Sharepoint - 80" | .\Recycle-IisAppPool.ps1

Ooh, and the script; here it is (remember to save it with a .ps1 extension)

process
{
 $_ | % { Invoke-WMIMethod -Name Recycle -Namespace "root\MicrosoftIISv2" -Path "IIsApplicationPool.Name='W3SVC/AppPools/$_'" }
}

Thursday, August 11, 2011

The death of hierarchical IdM systems?

Here is an interesting article with non-technical (directly anyway) stuff; looking at how you traditionally approach Identity Management in organizations, there may just be a point in the statement that hierarchical systems for identities might work for an organization but cannot be translated to "The Cloud".

Think about it - I know I will...

Wednesday, August 10, 2011

Kerberos and FIM working together

Configuring Kerberos with FIM 2010 can be kind of tricky; however, a good guide and description (better than the installation guide or a good supplement) by Thomas Vuylsteke can be found here.

Tuesday, August 9, 2011

Granting the Replicating Directory Changes Permission

At a lot of my customers I run into the job of granting and documenting having granted the access right "Replicating Directory Changes" for the Active Directory Management Agent service account.

The necessary permissions are documented nicely by Microsoft in http://support.microsoft.com/kb/303972/en-us; however, I like scripting because it's repeatable and you're sure that its gets done the right way each time - and also, you can delegate the task of granting the permission to someone else, i.e. the customers directory administrator.

I know that most of this stuff is old news, but I just wanted to share the script that I use at my customers to grant the permission; hopefully this can be useful to others as well.

The syntax for running the script (from a PowerShell prompt as an account holding he appropriate permissions) is something like this if you wanted to grant the permission to the user called SVC-FIM-ADMA -
.\Grant-ReplicatingDirectoryChanges.ps1 -Account SVC-FIM-ADMA

Usually, though, I tend to recommend my customers to create a new domain security group and grant the permission to that group instead. And then just add the MA account that needs the permission to that group. Seems like a more sustainable approach, allowing you to delegating the permissions to another account without having to run the script again. If you want to use this approach, the script will work as well - just give the group name as a parameter instead of a username.
Enjoy and here’s the script (remember to save it as a .ps1 file)

# Grants necessary permissions for AD MA Service Account for
# FIM 2010 or ILM 2007 according to directions in
#
http://support.microsoft.com/kb/303972/en-us article
#
# Please note that this script has only been tested on Windows Server 2008 R2
param (
 $Account
)
# get domain environment information
$RootDse = [ADSI] "
LDAP://RootDSE"
$DefaultNamingContext = $RootDse.defaultNamingContext
$Domain = [ADSI] "
LDAP://$DefaultNamingContext"
$DomainNetBIOSName = $Domain.Name.ToString().ToUpper()
$DomainFQDN = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
# translate to SID (I like this due to it's uniqueness characterictics
$UserPrincipal = New-Object Security.Principal.NTAccount("$DomainNetBIOSName", "$Account")
$SID = $UserPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
DSACLS "$DefaultNamingContext" /G "$($SID):CA;Replicating Directory Changes";

Friday, August 5, 2011

Got a Twitter account

Join me on Twitter as well for smaller and quicker updates. You can catch me at @mrgranfeldt.

Hope to see you there.