Friday, December 14, 2007

Understanding the inner workings of SAP from MIIS (ILM) Perspective

The past few posts, I’ve really concentrated on the Microsoft ERP MA for SAP integration. Although my world revolves around identity management, a huge piece of that I spend on integration of systems throughout the enterprise that do not share a common platform. One of which is SAP. By no means would I consider myself an SAP Consultant; however the need to understand the inner-workings of foreign systems only makes my job that much easier. Surprisingly, SAP is one of those systems we find customers having difficulties integrating into different connected data sources all around the enterprise.

This post will further concentrate on key components of SAP; most typically how SAP communicates to the outside world. From here, you can better understand how to achieve proper integration.

The first thing is to understand some key concepts of SAP. SAP talks through various Business Application Programming Interfaces also known as BAPIs. These interfaces are object-oriented methods which are the data-handling mechanisms used in SAP Systems. Knowledge of how to instantiate these objects are the most powerful tool in an SAP consultant’s arsenal. BAPIs are business objects similar to transactional records, master records, or datasets. They are most used when calling data in and out of SAP. Although out of the box, there are several hundred BAPIs available for use; they can also be customized to fit any business need required.

Another key concept to BAPIs and most often confused are IDocs. IDocs are data transports and are about moving data between systems and modules within SAP. Ultimately, BAPIs are the mechanisms for getting data in and out of SAP; therefore when integrating SAP with MIIS, you will be invoking or passing parameters to BAPIs to retrieve any type of data.

Remote Function Calls (or RFCs) are function modules that are called within a BAPI. They relate to each other as a BAPI is a business object; whereas an RFC is the functional code.

A perfect example of what happens is, (A) you call a BAPI, then (B) pass parameters to invoke RFCs.

Thursday, December 6, 2007

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

In my previous post, I provided an overview of how we communicate within .NET to SAP Systems. Now, let’s take a look at how this relates to ILM (MIIS). The ERP MA provides a tool called to build the connector space. (Yes, you must build out your connector space by (1) defining the schema of attributes and (2) declaring what BAPIs to invoke and where (add, replace, delete, setpassword). This is accomplished through the ERP Configuration Tool. The document recommends using the provided template files to get started; however in my experience they were much harder to customize. IMHO it was much easier to build my connector space from scratch.

Once you’ve completed, you can create the SAP MA which to do so, you need to input the XML configuration file that is created by the ECT. You should then be able to see the entire attribute list with all the normal functions of any other management agent.

How do my previous posts relate to where we are now; well here is how the MA works.
  1. Building the ERP MA configuration file using the ECT; the configuration of the MA is performed by discovering the SAP environment using the SAP connector for Microsoft .NET 2.0 and generating an XML. This essentially discovers all the BAPIs and stores them in a local cache file.
  2. Configuration UI communicates with SAP to discover the BAPIs and other configuration for display.
  3. XML configuration, proxy assemblies and schema definition file generated by the UI. You are building out your connector space.
  4. Creation of the MA happens in MIIS and consumes schema file which MIIS uses to synchronize with SAP.
  5. ERP MA SAP assembly consumes XML configuration and proxy assemblies at run time provides wrapper to RFC calls directly to SAP Server
    The diagram below (provided from the CHM) details what happens under the covers.

Now that you understand the process for communication, you can now proceed to determine what to do with the data you import/export. Key things to understand when using the Microsoft ERP MA are the following:

***Understand the process of Alias and Alias-referencing. That is the core of how the MA works.

Tuesday, December 4, 2007

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

In part of my last post, here we should do an overview of the SAP .NET Connector. Essentially, it is a programming environment inside of Visual Studio that enables us to communicate between the .NET platform and SAP Systems. Communication is facilitated through proxy classes which call and/or invoke BAPI functions in SAP. The connector support both SAP RFCs and Web Services which allow you to write various applications using any .NET language. Pretty straight forward, huh?

Anyhow, the connector is made up of several parts. As I mentioned, first it’s pretty tightly integrated with Visual Studio for generating SAP proxies. The proxies are used to call BAPI functions through either the SAP RFC protocol (librfc32.dll) or via SOAP. Do note, per the documentation...Release 4.6D does not have SOAP support while systems starting from 6.20 can use either. At the moment, the most current version of the connector is built for .NET 2.0 (SAP Connector for Microsoft .NET 2.0). Additional dlls that are part of the assembly is the SAP.Connector.Rfc.dll and LibRfc.dll. (LIBRFC32.dll, is in Release 6.20 and higher). The diagram below, details the runtime architecture and how communication is facilitated using the .NET Connector.




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.

Tuesday, November 27, 2007

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.

Thursday, September 13, 2007

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.

Saturday, August 11, 2007

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.

Monday, June 4, 2007

Learning Microsoft Identity Management

The world of identity management (IdM) is very broad with many angles for misinterpretation. For those who know me, I frequently refer to identity management NOT as a product but a framework. For the past 3 years, the world of identity has been my home which has allowed me to work on some very challenging projects and do some very cool things with a variety of clients across all industries. As with many like me that enjoy the intoxication for managing the digital identity, my journey started with learning Microsoft Identity Integration Server 2003 (MIIS 2003). To this day, I get asked and I still see many questions on the forums looking for guidance on where to start researching….although there is much more documentation and resources out now, it is still kind of all scattered which can definitely frustrate the new comers. I'm going to attempt to list the key documents that provide the best details for starting off an identity and access management career. BTW – If you find this article of interest and find other documents which should be included that I may have missed, please email me and let me know.

The first step is to get a generalization of what identity management is. There are many web casts out now which may ignite the curiosity, however many are in the mists of identity chaos without even realizing it. A very good 15 page document which provides a quick and neutral introduction to IdM is, Spencer Lee's "An introduction to Identity Management."

Additionally, there are many key sites that speak on MIIS and Identity Management. Just googling "MIIS 2003," you're bound to come up on MIISExperts.org which can be considered the "Holy Grail" of MIIS sites. This site probably provides the most information next to MSDN.

The FAQs on MIISExperts.org answers the question of how do I learn IdM by doing 3 things:

  1. Take the time to get trained.
  2. Read the FAQs
  3. Join the newsgroups and start lurking, or jump right in and start posting questions.

In the old days, all we had was the MMSUG newsgroup and a few technical documents; today the online resources unlock a treasure of information and it's just a matter of investing the time in learning the technology and understanding how and where to apply it. For many, the best way is attending the official course provided the by the boys from OCG. These courses are worth every penny because not only do you learn from experts in the field of IdM; they are the authors of the official curriculum and active implementers in the field. There are more course offered, however the

For on-line resources, obviously you can look to the product's homepage; however most of the key documentation probably of value to you would be in the Microsoft Identity Integration Server Technical Library. Here you'll find guidance in properly planning, designing, deploying and maintaining an MIIS implementation.

  • Planning and Architecture (Use this documentation set as you plan your MIIS 2003 deployment to help you design the most secure and optimal MIIS solution for your needs, initiate your project, design the system data flow, plan synchronization rules, and address configuration settings.)
  • Deployment (Includes information about recommended deployment scenarios for MIIS 2003 including how to upgrade from the previous versions and also solution guides that provide deployment information for uncommon scenarios)
  • Operations (This documentation set includes "How To" guides and other documents that provide discussions and recommended solutions for specific challenges that you encounter when using MIIS 2003.)
  • Technical Reference (This documentation set provides in-depth information about MIIS 2003 components, architecture, identity management process, synchronization rules, run profiles, and details about event-based and state-based identity management architectures.)
  • Development (Administrators and developers can create rules extensions that use the Microsoft .NET Framework. To understand the information in this Developer Reference, you must be well familiar with MIIS 2003. )

Once the foundation is set, you'll probably be extremely anxious to get this thing running to cure all your pains from the sickness of identity chaos. Well, the best way is to use the walk-troughs. This collection of documents is really good because it allows you to install and configure each function of MIIS from general identity synchronization to password management topic. After completing the scenario walkthroughs, you can proceed with the more advanced Microsoft Identity and Access Management Series 1.4. This collection provides a very true configuration for and enterprise implementation of MIIS. Additionally the sample code can be used as a reference to build your own solutions.

MIIS 2003 Scenario Walkthroughs (Download from source)

Microsoft Identity and Access Management Series 1.4

Note: For a more technical collection of documents for techniques, you should review the following functional and design documentation. This set details the essential concepts of event- and state-based architectures and the core components, architecture, identity management process, synchronization rules, and run profiles featured in MIIS 2003

Microsoft Identity Integration Server 2003 Functional and Operational Reference

MIIS 2003 Design Concepts

A summary of the design concepts typical in any MIIS implementation is addressed in these documents.

  • MIIS 2003 Design Concepts for Reference Attributes

    This document explains how reference attributes are processed by MIIS 2003 for direct attribute mapping scenarios and provides a conceptual explanation of a custom solution for advanced mapped reference attributes. It also includes design recommendations for both direct and advanced mapped attributes.
  • MIIS 2003 Design Concepts for Correlating Digital Identities

    This document discusses considerations for mapping attributes across different identities and configuring joins based on your business requirements. It introduces the concept of Correlation ID and explains how you can deploy a Correlation ID to establish strong object relationships in your identity integration solution.
  • MIIS 2003 Design Concepts for Implementing IFunctions

    This document introduces the concept of object-level identity functions (IFunctions) in an identity integration scenario, discusses possible implementation options, and also provides implementation recommendations.
  • MIIS 2003 Design Concepts for Implementing Reverse Joins

    This document discusses some of the common reverse join implementation approaches for synchronizing identity objects in MIIS 2003. It provides two solutions for implementing reverse joins- reverse joins based on Transient management agents and reverse joins based on Auxiliary management agents.
  • MIIS 2003 Design Concepts for Advanced Solution Components

    In this document, you will learn about "process-level attributes" and "conditional metaverse objects" to improve the convergence efficiency of the identity integration process, and how you can use "operational management agents" to isolate metaverse objects requiring special attention. The "auxiliary management agents" section discusses how you can implement a custom reprocessing solution.

Once you've become proficient in MIIS, of course there's a learning path for this profession. It's always been my belief that although Identity Management is typically used to support application authentication and authorization, it's heavily influences and complements the security of any infrastructure. Microsoft recently published the learning paths for each practice as seen in the attached link. Additionally, this link contains all the on-demand web casts published for Identity and Access Management.

Now that you're a pro at identity management, join the newsgroups and start contributing to the communities!

Because the identity management is still evolving, there is still a lot of information to learn. This technology is like a living creature that grows as fast as innovations permits it. The upcoming versions ILM 2007 and ILM"2" are the future. Jump on board and train of evolution and hang on, because you're going to be in for a ride!

Evolving further into Identity Lifecycle Management (Automated Identity and Access Management)

Identity Lifecycle Management Information Protection Federated Identity Strong Authentication Directory Services