ILM (MIIS) and the Microsoft ERP Management Agent - Part 1

In my current project, I’ve had the opportunity to work with the Microsoft ERP Management Agent for SAP. As many already know, SAP is a huge applications and a common connected data source which in most (or some) cases acts as the authoritative source for HR related data. MIIS can be used to facilitate or broker identity data and identity management related tasks to and from this connected data source and to many others. In my opinion, MIIS and SAP integrate very well which I thought I’d write about how MIIS connects to SAP to synchronize identity data to and from the connector space. From here, I hope you can get a better understanding on how to integrate SAP into your existing MIIS environment.

Prior to the release of the ERP MA by Microsoft, MIIS developers connected to SAP systems by custom XMAs using the SAP .NET Connector. For example, Oxford Computer Group had developed a management agent for SAP which has been proven successfully in many environments way before the Microsoft ERP MA was even released. Regardless, here is how connectivity is accomplished using the ERP MA from Microsoft.

Before I start, the Microsoft ERP Management Agent can be downloaded from the following link or obtained within the ILM 2007 FR1 installation media.

Microsoft Enterprise Resource Planning Management Agent for SAP

The base requirements for this management agent are:

• Microsoft Identity Integration Server 2003 SP2 or ILM 2007
• The SAP .NET Connector 2.0
• Microsoft .NET Framework, version 1.1 or higher

In order to connect to SAP, you should first understand some concepts of SAP.

• BAPI (Business Application Programming Interface) – a function that performs a specific operation inside the SAP environment
• InfoTypes – structures used as parameters to BAPIs
• RFC (Remote Function Calls) – a method for accessing a BAPI from another computer via the network
• SAP Connector for Microsoft .NET 2.0 – a managed component from SAP that enables RFC to BAPIs in a SAP application server

It’s pretty late now, so in my next part I will write more details on how the SAP .NET Connector works and how it relates to MIIS and the ERP MA.

ERP MA bug in ILM 2007 FP1

Apparently there is a known bug in the ERP MA for SAP that comes with ILM 2007 FP1. This bug prevents you from configuring the outbound flow of an anchor attribute. When mapping an attribute to csobject.anchor, this prevents you from setting the flag which defines this attribute as an identity for the object and prevents you from exporting when invoking a BAPI that needs the reference.

Microsoft is aware of the bug which might be fixed next week; however the expectation should be assumed for mid-January.

So far, I’ve still using the version of the MA downloadable from the following link which is working fine.

Setting Terminal Service Properties in .NET

I recently had the requirement of managing Terminal Service properties in AD by means of MIIS. If you've ever been tasked with this, you may have noticed there are many VBScript and C++ snippets online with very few .NET examples. Therefore, I've decided to post how to accomplish this in .NET for those interested.

Initially, you'd think this is pretty easy...why couldn't I just flow any value through to AD using an advanced attribute flow within an MA rule extension? Well, not in this case. If you look into a user objectClass in AD through ADSIEdit, you'll notice these attributes are not directly exposed. Although I was able to populate some of the values through System.DirectoryServices, not all were accessible. Further research uncovered you can manage Terminal Service properties using the ADSI Extension for Terminal Services User Configuration. This extension is an assembly that allows you to manage Terminal Server user properties though the IADsTSUserEx Property Method. Below is sample code I used to test the functionality.

using TSUSEREXLib;
using System.DirectoryServices;
using System;
using System.Collections.Generic;
using System.Text;

namespace Set_Terminal_Service_Properties
{
class Program
{
static void Main(string[] args)
{
string acctName = "chrisca";
string tsHomeDrive = "H:";
string tsHomeDirectory = "\\\\servername\\tshomedirectory\\";
string tsProfilePath = "\\\\servername\\tsprofilepath\\";
int enableLogon = 1; // enable terminal service logins

DirectoryEntry entry = new DirectoryEntry
("LDAP://CN=Chris Calderon,CN=Users,DC=corp,DC=contoso,DC=com");
ADsTSUserEx oUser = (ADsTSUserEx)entry.NativeObject;
oUser.AllowLogon = enableLogon;
oUser.TerminalServicesHomeDirectory = tsHomeDirectory + acctName;
oUser.TerminalServicesHomeDrive = tsHomeDrive;
oUser.TerminalServicesProfilePath = tsProfilePath + acctName;
entry.CommitChanges();
entry.Close();
}
}
}

As you can see, you use the extension in the same manner as you would any ADSI statements. A key item to consider is, the properties that the Terminal Service User component exposes is not directly mapping individual AD attributes. Common with ADSI, when calling these methods to load the property values of the ADSI object, it stores this information into the property cache of the directory store. Only until the IADs::SetInfo method is called (or something equivalent), the property value changes are saved.

This component consists of one DLL (TSUSEREX.DLL), located within the %SystemRoot%\System32 directory. In order to use the IADsTSUserEx interface, you must reference this assembly within your project. The link below provides a table that lists the property methods of the IADsTSUserEx interface.

IADsTSUserEx Property Methods Details

My original goal is to eventually build an XMA for auxiliary attributes; however the core requirement to do that is to identify a method to access (read/write) these attributes.

Limitations of Office Integration in a Federated SharePoint Configuration

For the past year, I've worked on a few ADFS projects that have incorporated SharePoint 2007 and the number one issue that seems to always come up are the limitations in Office integration. This isn't something new; we actually experienced it in ADFSv1 and there is even a KB Article which describes which features are lost.

KB 912492 - Windows SharePoint Services and SharePoint Portal Server 2003 Support boundaries for Active Directory Federation Services

With ADFSv2, yes this KB article still applies; however you still get many of the features which operate exclusively through a web browser. Users can still download and upload files, search, and view or edit lists, etc. The problem is not within ADFS nor SharePoint; it's within the Office client which cannot process authentication cookies.

I guess the point I'm trying to make is, you have to re-evaluate the original initiative for exposing SharePoint 2007 as an Internet facing application; partner/customer integration.

From a business perspective, federating applications is much cheaper than managing VPN connections or external (partners) users not even under your domain. In many aspects, it can also be more secure. I mean, all the traffic is being communicated over SSL, right. In my experience, many ADFS customers are able to utilize SharePoint effectively just using the browser with Web SSO.

Believe it or not, this does provide benefits. First of all, IT is able to maintain strict control over what parts of their network can be accessed by partners, therefore eliminating significant problems caused by common practices of managing local accounts/passwords for partners within the DMZ. Just that reason alone reduces the attack surface for Internet facing applications. More reasons would be to,

• Reduce or prevent IT overhead for password management of external users/partners.
• To prevent a bad user experience when they forget their password and call their local helpdesk for help instead of the partner site they are trying to access.
• Prevent the loss of user productivity when they have to request and wait for remote accounts to be created before they can start working with a federated partner.
• Severe security vulnerabilities when external users are terminated by their enterprise/organization and partners do not receive notification to remove their accounts.

At the end of the day, Information Security must measure what options are readily available to keep their customers productive while still honoring security.