Microsoft Identity Manager PowerShell Management Agent for Oracle Internet Directory

Why a FIM/MIM PowerShell Management Agent for Oracle Internet Directory? Why not just use the Generic LDAP Connector for Microsoft Identity Manager? I needed an integration solution that was able to update an Oracle Database behind Oracle Internet Directory. That meant I required a solution that was able to use LDAP to get visibility as to who/what was in OID, but then make updates into an Oracle DB. That functionality I wanted to be contained on a single Management Agent, not an MA for the Database and another for LDAP. Another perfect fit for the Granfeldt PowerShell Management Agent. This post details an LDAP Forefront / Microsoft Identity Manager PowerShell Management Agent for Oracle Internet Directory. The example in this post provides a working example to discover/import OID LDAP objects.

If you haven’t used the Granfeldt PowerShell Management Agent (PSMA) before, see the Getting Started with the Granfeldt PowerShell Management Agent section of my Identity Manager Management Agents page here.

Schema Script

Below is my Schema Script for Oracle Internet Directory for the Person/inetOrgPerson objectclass. Depending on what you are using OID for and what the requirements for the OID Management Agent are, you may need to add additional attributes or remove any superfluous ones. I’m using the OID Guid as the anchor.

Import Script

Key functions of the Import Script are;

  • Delta Sync (using OID Change Log)
  • Full Sync (based off an LDAP Filter)
  • Paging of Results through the MA

Authentication

Authentication credentials are provided from the Management Agent through to the Import script via the Connectivity tab Username and Password configuration items.

Microsoft Identity Manager Oracle Internet Directory Management Agent Credentials.PNG
Microsoft Identity Manager Oracle Internet Directory Management Agent Credentials

Delta Sync

The Import Script uses the OID Change Log to determine objects of interest that have changed since the last sync. The import script writes a watermark file that contains the last changenumber used so it knows on the next sync what to look for. This post here has more details around Changelog.

Full Sync

Full Sync is performing an LDAP query against OID based on an LDAP Filter and bringing through to the Management Agent attributes specified on the MA Configuration. Essentially it is a Management Agent version of the PowerShell LDAP query I detailed here.

Paging of Results

If you have a large OID its always a good idea to page the results through the MA. The Import Script below utilises Paging on the Management Agent to process the objects. The method I’ve used in this example is a little different that what I’ve previously posted here and here. Objects returned from OID as per your LDAPFilter (line 207) are split into groups based on the PageSize you have configured for your Run Profile. This is done using the technique shown here for splitting a large collection into manageable chunks.

Configuration Updates

Using the sample Import.ps1 script below, update;

  • Line 10 for the Debug Output Log location
  • Line 12 for the Delta Sync OID Change Log watermark file location
  • Line 161 for the OID Server Name
  • Line 162 for the OID Server LDAP Port
  • Line 179 for the BaseDN to search from
  • Line 207 for the LDAP Filter for OID Objects of interest for the MA

Password and Export Scripts

As per the Getting Started with the Granfeldt PowerShell Management Agent section of my Identity Manager Management Agents page here these need to be present (and can be empty). What your MA needs to do will define whether you need to implement them and with what. For example I have implemented Password Sync to an Oracle DB using this method.

Summary

Using the flexibility of the Granfeldt PowerShell Management Agent for Microsoft Identity Manager we can integrate with diverse systems in bespoke ways. Hopefully this post gives you a leg up if you need to integrate with Oracle Internet Directory keeping in mind Exports or Password Sync could be to Oracle DB’s not just OID using LDAPModify.

Forefront/Microsoft Identity Manager – Attempted to access an unloaded AppDomain

This post is more a note-to-self for future me in case I’m in this scenario again. Today I encountered the error Attempted to access an unloaded AppDomain.

I have a custom Forefront/Microsoft Identity Manager Management Agent that requires multiple credentials for the Web Service it is integrating with. In order to secure parts of the credentials that cannot be provided as part of the Connectivity configuration tab on the Management Agent Proporties I have generated them and exported them using Export-Clixml as detailed in this post here.

Today I was migrating a Management Agent from one environment to another and was sure I’d regenerated the credentials correctly. However the Management Agent wasn’t working as expected. Looking into the Applications and Services Logs => Forefront Identity Manager Management Agent Log ….

Forfront Identity Manager Management Agent.PNG

i found the following error ….

Unhandled exception, the CLR will not terminate: System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain

Attempted to access an unloaded AppDomain.PNG

Retracing my steps, I had logged on to the Synchronisation Server with the incorrect credentials to generate my protected credentials XML file.

When the Synchronisation Server was running the Management Agent and attempting to run Import-clixml “credentialFilename” the credentials/account that had exported the credentials did not match the service account that the synchronisation server was running with. And the error listed above was thrown.

Summary

Import-clixml and Export-clixml do exactly what they are supposed too and respect the context by which the credentials were exported and will only be able to access them when imported under that same context. The error doesn’t really tell you that but does hint at it with Attempted to access an unloaded AppDomain if you know what you are trying to do.

 

Configuring the Lithnet REST API for the FIM/MIM Service post MIM Version 4.4.x.x

Last year I wrote this post on installing and configuring the Lithnet REST API for the FIM/MIM Service and integrating it with Azure API Management.

This week on a fresh installation of Microsoft Identity Manager with SP1 I was installing the Lithnet REST API for the FIM/MIM Service and was getting errors from the WCF Web Service finding the correct version of the Microsoft.ResourceManagement.dll.

Error finding Microsoft.ResourceManagement DLL.PNG

After a little troubleshooting and no progress I recalled Kent Nordström posting the following tweet last month.

Kent Nordstrom Tweet.PNG

Looking back at my own environment the version of the Microsoft.ResourceManagement.dll that was installed in the product directory C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin was version 4.5.285.0. A different version to what Kent had.

ResourceManagement DLL version from Program Files.PNG

Looking for the Microsoft.ResourceManagement.dll under c:\windows\assembly\gac_msil\Microsoft.ResourceManagement the version that was on my installation was 4.4.1302.0.

ResourceManagement DLL version from GAC.PNG

Updating the Lithnet REST API for FIM/MIM Service web.config as detailed in my previous post on the Lithnet REST API for FIM/MIM Service therefore needed to reference 4.4.1302.0. After making that change everything worked as expected.

Version for Resource Management Web Service

Summary

Big thanks to Kent for saving me hours of fault finding. If you are on MIM version 4.4.x.x or later keep in mind that the version of the Microsoft.ResourceManagement.dll located in the product installation directory ( C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin ) differs from the version of the file that the installation puts in the GAC.

Also if you then subsequently update your Microsoft Identity Manager installation (maybe because of this obscure reason), don’t forget to then go back and update the Lithnet REST API for the FIM/MIM Service web.config to reflect the latest version of the Microsoft.ResourceManagement.dll.

Multiple Versions of Microsoft.ResourceManagement DLL.PNG

Error: Failed to connect to the specified database when creating a Microsoft Identity Manager Service MA

Last week I was installing Microsoft Identity Manager into a development environment. The install was using Microsoft Identity Manager 2016 with SP1 and was version 4.5.285.0. The install had gone well, SQL, Synchronisation Server, MIM Service and Portal etc. I had even created a couple of Management Agents. However when it came time to create the Microsoft Identity Manager Service MA, the Synchronisation Server returned the error “Failed to connect to the specified database”.

Failed to connect to the specified database.PNG

Jumping over to the Event Log I found the error below. The current version of database is not compatible with the one expected by Forefront Identity Manager service. The current version of the database is : 2008. The expected version is : 2015.

Now this was a fresh install. That error usually indicates the database has been restored from a previous version. But speed reading I thinking SQL Server, not Database. My SQL Server is 2016.

Current version of the database is 2008..PNG

Validating that via SQL Management Studio returned what I expected.

Actual SQL Version

Looking at the database itself, it showed a compatibility level of 2008.

FIMService Database Version

With nothing to lose I set the compatibility level to 2016. On the next attempt to create the MIM Service MA I still got my database error.

Change version from 2008 to 2016

At this point I was short on options. This was a fresh brand new installation so I had no backups yet.

I downloaded the latest hotfix for Microsoft Identity Manager (currently 4.5.286.0) from here and updated my Synchronisation Server and MIM Service and Portal.

Following that I was able to create the MIM Service MA and successfully perform a Stage of data from the MIM Service.

MIM Service MA Created and working

Summary

If on a fresh install of Microsoft Identity Manager you receive the error “Failed to connect to the specified database” and all your configuration settings are correct, and the event logs indicate a Database Version error, install the latest hotfix and you should be back in action.

Error 25009 HResult 0x80131700 when installing Microsoft Identity Manager

This week I was installing Microsoft Identity Manager in a new environment and wasn’t using my usual scripts that semi automate the process. During the installation of the Microsoft Identity Manager Synchronization Service I got the Error 25009 HResult 0x80131700 as shown below.

FIM Sync Server Installation Failed Configurating SQL.PNG
FIM Sync Server Installation Failed Configurating SQL

As mentioned above I normally do this semi-automated but this time I was updating a bunch of that so was starting with a fresh install on a Windows Server 2016 host.

Note: Windows Server 2019 isn’t an officially supported platform currently.

Re-running the install with an installation log as I detail in this post didn’t help much as the install log did show an error but not too much more.

Additional research indicated that this error can be caused for three varying scenarios;

  • insufficient permissions on the SQL Server
  • missing SQL Native Client on the Microsoft Identity Manager Sync Server
  • missing .NET Framework 3.5

Checking the SQL Server I could see that the login for the Sync Server Service has been created, so that discounted the first two. Looking at the installed applications on the Sync Server confirmed that I did not have the .NET Framework 3.5 installed.

Install NET 3.5.PNG

Looking back at my automation scripts one of my first lines is;

Install-WindowsFeature NET-Framework-Core
Following installation of the .NET Framework, 3.5 re-running the setup got me up and running.
Completed Successfully.PNG

Summary

In 2019 installing Microsoft Identity Manager 2016 with SP1 still has the same dependants that Identity Lifecycle Manager had in 2007.  .NET Framework 3.5 however isn’t installed by default on Server 2016 (.NET Framework 4.x is). If nothing else this will jog my memory for next time.

SailPoint IdentityNow Governance Groups Management Agent for Microsoft Identity Manager

Last week I posted a SailPoint IdentityNow Roles Management Agent for Microsoft Identity Manager. Today I’m posting a sister for it, an IdentityNow Governance Groups Management Agent.

I’ve posted about Governance Groups before. See Managing SailPoint IdentityNow Governance Groups via the API with PowerShell. That post details creating and managing Governance Groups via the API.

This Management Agent is essentially the enumeration of Governance Groups in IdentityNow via API wrapped up in a PowerShell Management Agent. You can extend the management agent for managing Governance Groups to fit your needs.

Prerequisites

  • On your MIM Sync Server you will need the PowerShell Community Extensions (PSCX)  for the Get-Hash cmdlet
  • Authentication to IdentityNow for Governance Groups can leverage the v2 Authentication method. I cover  enabling that in this post here. You can also use the v3 Authentication method I detail here. If you do that you will need to appropriately secure the extra credentials as I show in the Roles Management Agent.
  • The Management Agent leverages the Granfeldt PowerShell Management Agent. Start here to get up to speed with that. As detailed above this is an Import only MA so I’m not providing an Export Script and the Password is redundant. The script files need to be present but will be empty

Schema Script

The Schema Script below covers the core attributes associated with IdentityNow Governance Groups.

Import Script

The Import Script unlike the Roles Management Agent can use v2 Authentication. As such we don’t need to perform additional effort to provide the necessary credentials.

Your v2 IdentityNow credentials need to be provided on the Management Agent Connectivity Configuration page. The Username and Password Authentication options take the v2 API Client ID and API Client Secret respectively.

IdentityNow Governance Groups MA Connectivity Username Password

NOTE: The Import Script is also configured to page the import of Governance Groups. The Page Size is configured in your Run Profile.

Make the following update for your implementation;

  • Line 24 for your IdentityNow Orgname

Customisation

Depending on what you want to do with it, will depend on how you want Identity Manger to consume the data. You will likely want to;

  • Create a new ObjectType in the Metaverse along with the attributes associated with IdentityNow Governance Groups
  • Flow the information in and perform any logic
  • Create an Export Script that will;
    • create Governance Groups in IdentityNow
    • update Governance Groups in IdentityNow

Summary

Using this base management we can get connectivity and visibility of IdentityNow Governance Groups in Microsoft Identity Manager.

SailPoint IdentityNow Roles Management Agent for Microsoft Identity Manager

This is the first post in a series where I will provide a number of base-level Management Agents for Microsoft Identity Manager to integrate with SailPoint IdentityNow. Whilst the two products have areas of competing/equivalent functionality there are other aspects where integration of the two compliment each other. Whilst that is not the purpose of this post, through the series of upcoming posts it will be relatively easy to extrapolate how the two products can happy co-exist and orchestrate each other for certain functions.

This Management Agent is for Microsoft Identity Manager to have visibility of IdentityNow Roles (see customisation at the end for me functionality).

For more information on IdentityNow Roles see this post where I detailed Creating Roles as well as updating/managing them via API. The MA also consumes whether the Role is requestable that I covered in this post.

Notes

  • The Management Agent is a Full Sync only Management Agent. This is because the IdentityNow API doesn’t expose differential style requests. That is also why this is a single function Management Agent (just for Roles).
  • The Management Agent is configured for Paging the results back into Identity Manger. For more details on that see this post.

Prerequisites

  • On your MIM Sync Server you will need the PowerShell Community Extensions (PSCX)  for the Get-Hash cmdlet
  • The Management Agent uses IdentityNow v3 Authentication. You will need to request the API Keys from your SailPoint Customer Success Manager. Details on v3 Authentication can be found in this post
  • The Management Agent leverages the Granfeldt PowerShell Management Agent. Start here to get up to speed with that. As detailed above this is an Import only MA so I’m not providing an Export Script and the Password is redundant. The script files need to be present but will be empty

Schema Script

The Schema Script below covers the core attributes associated with IdentityNow Roles.

Import Script

As IdentityNow v3 API Authentication requires a number of artifacts, we need to make sure we secure them all appropriately.

For the Admin Username and Password we will do that by exporting them to an XML file using Export-CLIXML and then in the Import Script, import them using Import-CLIXML. Those cmdlets respect the context by which the credentials were exported and will only be able to access them when imported under that same context. As our Management Agent will be run by the MIM Sync Server Service Account we need to create the credentials file using that login. To do that;

  • temporarily reconfigure the MIM Sync Service Account so that it can logon locally
    • On the MIM Sync Server open Local Security Policy = > Local Policies => User Rights Assignment => Deny log on locally and remove the MIM Sync Server Service Account
    • repeat for Deny access to this computer from the network
  • Logon to the MIM Sync Server using the MIM Sync Server Service Account
  • Run the following to create the credential file and put the credential file in the Extensions\yourRolesMA directory
$adminUSR = [string]"Partner_Admin".ToLower()
$adminPWDClear = 'myStr0ngP@$$w0rd'
$adminPWD = ConvertTo-SecureString $adminPWDClear -AsPlainText -Force
$Credentials = New-Object System.Management.Automation.PSCredential $adminUSR,$adminPWD
$Credentials | export-clixml c:\temp\RoleAdminCred.xml
  • IMPORTANT: Add the MIM Sync Server Service Account back  into the Deny access to this computer from the network and Deny Logon Locally policies

The IdentityNow v3 API Credentials are stored on the Management Agent Connectivity Configuration page. The Username and Password Authentication options take the v3 API Client ID and API Client Secret respectively.

MA Configuration Username Password ClientID Client Secret.PNG

Make the following updates for your implementation:

  • Line 24 for your IdentityNow Organisation name
  • Line 27 for the location and name of the credentials file created above

Customisation

Depending on what you want to do with it, will depend on how you want Identity Manger to consume the data. You will likely want to;

  • Create a new ObjectType in the Metaverse along with the attributes associated with the Roles
  • Flow the information in and perform any logic
  • Create Roles in IdentityNow
  • Update Roles in IdentityNow

Summary

Using this base management we can get connectivity and visibility of IdentityNow Roles in Microsoft Identity Manager.

Granfeldt PowerShell Management Agent Schema HRESULT: 0x80231343 Error

Yesterday I was modifying the Schema configuration on a Granfeldt PowerShell Management Agent on a Microsoft Identity Manager 2016 SP1 Server.

I was changing the Anchor attribute for a different attribute and on attempting to refresh the schema or view the configuration I got the following error;

Unable to retrieve schema. Error: Exception from HRESULT 0x80231343

Unable to retreive Schema.PNG

I knew I’d seen this before, but nothing was jumping to mind. And this was a particular large Schema script.

After some debugging I realized it was because the attribute I had changed the Anchor attribute too, was also listed in the Schema script. It wasn’t obvious as the attribute entry was multiple pages deep in the script.

Essentially if you are seeing the error Unable to retrieve schema. Error: Exception from HRESULT 0x80231343 there are two likely causes;

  • you haven’t declared an Object Class e.g User
    • $obj | Add-Member -Type NoteProperty -Name “objectClass|String” -Value “User”
  • the attribute you have as your anchor is also listed as an attribute in the schema script e.g
    • $obj | Add-Member -Type NoteProperty -Name “Anchor-ObjectId|String” -Value “333a7e07-e321-42ea-b0a5-820598f2adee”
    • $obj | Add-Member -Type NoteProperty -Name “ObjectId|String” -Value “333a7e07-e321-42ea-b0a5-820598f2adee”
      • you don’t need this entry, just the Anchor entry

Hopefully this helps me quickly find the reason next time I make a simple mistake like this in the Schema script.

 

Using Invoke-WebRequest calls within a Granfeldt PowerShell MA for Microsoft Identity Manager

MIM Sync Service Account IE Security Settings

If you use PowerShell extensively you should be familiar with the Invoke-RestMethod cmdlet and the ability for PowerShell to call API’s and receive information. The great thing about Invoke-RestMethod is the inbuilt conversion of the results to PowerShell Objects. However there are times when you need the raw response (probably because you are trying to bend things in directions they aren’t supposed to be; story of many of my integrations).

From within Granfeldt PowerShell Management Agent script(s) that use Invoke-WebRequest calls, these will in turn leverage the Internet Explorer COM API on the local machine. That means the account that is performing those tasks will need to have the necessary permissions / Internet Explorer configuration to do so.

Enabling Invoke-WebRequest for the FIM/MIM Synchronization Server Service Account

Logon to your Microsoft Identity Manager Synchronization Server using the Service Account associated with the Forefront Identity Manager Synchronization Service. If you’ve secured the service account properly you will need to temporarily allow that service account to Log on Locally.

FIM Sync Service Account.PNG

Open Internet Explorer and open Internet Options. Select the Security Tab, the Internet zone and select Custom Level.

Locate the Scripting section and set Active scripting to Enable. Set the Allow websites to prompt for information using scripted windows to Disable. Select Ok and Ok.

MIM Sync Service Account IE Security Settings.PNG

With the configuration completed, go back and change back the Forefront Identity Manager Service Accounts’ local permissions so it can’t logon locally.

Your Import / Export Granfeldt PowerShell Management Agent Scripts can now use Invoke-WebRequest where the requests/responses use the Internet Explorer COM API and respect the Internet Explorer security settings for the user profile that the requests are being made by.

Hopefully this helps someone else that is wondering why the scripts that work standalone fail when operating under the FIM/MIM Sync Service Account by the Granfeldt PowerShell Management Agent.

Adding Delta Sync Support to the Microsoft Identity Manager PowerShell Management Agent for Workday HR

Recently I posted a sample Microsoft Identity Manager Management Agent for Workday HR. Subsequently I also posted about some updates I made to the WorkdayAPI PowerShell Module to enable functionality to specify the time period to return changes for. This post details updating  my sample Workday Management Agent to support Delta Synchronisation.

WorkdayAPI PowerShell Module

First up you will need the updated WorkdayAPI PowerShell Module that provides the Get-WorkdayWorkerAdv cmdlet and can take a time period to return information for. Get the updated WorkdayAPI PowerShell Module from here

Update the PowerShell Module on the MIM Sync Server. The module by default will be in the  C:\Program Files\WindowsPowerShell\Modules\WorkdayApi folder.

You will need to unblock the new files.

Get-ChildItem 'C:\Program Files\WindowsPowerShell\Modules\WorkdayApi' | Unblock-File
Get-ChildItem 'C:\Program Files\WindowsPowerShell\Modules\WorkdayApi\scripts' | Unblock-File

Updated Schema

In the updated Management Agent I’m also bringing into MIM additional attributes from the other enhancements I made to the PowerShell Module for HireDate, StartDate, EndDate, Supplier and WorkdayActive. The updates to the Schema.ps1 are shown below.

$obj | Add-Member -Type NoteProperty -Name "HireDate|string" -Value "string"
$obj | Add-Member -Type NoteProperty -Name "StartDate|string" -Value "string"
$obj | Add-Member -Type NoteProperty -Name "EndDate|string" -Value "string"
$obj | Add-Member -Type NoteProperty -Name "Supplier|string" -Value "string"
$obj | Add-Member -Type NoteProperty -Name "WorkdayActive|Boolean" -Value $True

The full updated Schema Script is below;

With the Schema Script updated, refresh the Management Agent Schema.

Update Schema

You can then select the new attributes in the Workday MA under Select Attributes.

Select New Attributes.PNG

Then select Ok.

Attributes Selected.PNG

Updated Import Script

The Import Script has a number of changes to handle creating and updating a WaterMark File that is used to store the date stamp of the last run. Also updated in the Import Script is the change to use the Get-WorkdayWorkerAdv cmdlet over the Get-WorkdayWorker cmdlet so that a time period can be specified, and to retrieve the additional attributes we just added to the schema.

Update:

  • Line 11 for the path and name of the Watermark File you wish to use
  • Line 31 for the URI of your Workday Tenant

Executing the Management Agent using a Delta Import Delta Sync Run Profile

After creating a Delta Import Delta Sync Run Profile we can now run a Delta Sync. The following graphic is after seeding the WaterMark file (with the last run time in a format like this 2018-10-29T22:09:08.3628953+00:00), as by default without the WaterMark file being present a Full Import is performed by the MA as it doesn’t have a watermark to base the import time period on.

The changed records in Workday HR are then identified and those records obtained, imported and synchronised via the Management Agent.

Delta Sync.PNG

Summary

Using Delta Synchronisation functionality from Workday HR allows for much quicker synchronsiation from Workday HR to Microsoft Identity Manager.