1dent1ty cHa0s

Security Squared has a nice four part article on how Identity and Access Management is rapidly converging with Logical-Physical access control systems (PACS). Think about tying your badge access control (perimeter, interior, etc) to your AD account; AD account is disabled and your badge is immediately cut off. These are capabilities Ensynch has recently acquired through a partnership that I hope to see announced very soon. Now you'll be able to completely tie-in access control across all aspects of IT and if you factor in the request management capabilities of FIM 2010 then you can begin to conceptualize a solution that would allow for complete paperless automation (with approvals) of physical access control requests! Combine that with PKI and data protection initiatives (like RMS) and you can begin to realize solutions within everyone's budget – not just the big enterprises.

This isn't some emerging technology, the software and hardware exists today and is fully available, we are only just recently bridging the gulf between IAM and PACS solutions providers to offer a unified and converged solution. Contact me if this interests you.

One Person, One Identity, One Credential: Converging Logical-Physical Identity and Access Management -- Part 1

Just a reminder when you are building your own custom Delta processing rig for your XMAs and you're using LDIF – the order in which you list the updates in your LDIF file is important. Consider this, you get a MODIFY request for record 10 but you don't have the ADD entry until farther down in the file. What you get is the 'need-full-object' exception during the discovery (Import) phase.

So, when building your own custom delta processing rig, make sure you group the records prior to writing them to the LDIF file like so:

1. Adds
2. Deletes
3. Modifies or Attribute Modifies (for ALCN)

My colleague Jerry Camel had already done this properly in some of our LDIF conversion libraries but this cropped up again when we were generating the LDIF from a table where the deltas had already been calculated for us by the data owners (good data owners!). A quick 'group by' clause in the SQL and you should be good to go! It just so happens that if you're using "ADD", "DELETE", "MODIFY", and "MOD-ATTR" as your delta status values then a straight ORDER BY clause will put them in the correct order since they are already ordered properly alphabetically.

Rebecca and I were able to troubleshoot this error after a bit of head scratching:

The extensible extension returned an unsupported error in MIIS.
The stack trace is:
"System.Threading.ThreadAbortException: Thread was being aborted.
   at SNINativeMethodWrapper.SNIPacketGetConnection(IntPtr packet)
   at System.Data.SqlClient.TdsParserStateObject.ProcessSniPacket(IntPtr packet, UInt32 error)
   at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()
   at System.Data.SqlClient.TdsParserStateObject.ReadBuffer()
   at System.Data.SqlClient.TdsParserStateObject.ReadByte()
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at XMA_HR.XMA_HR.Microsoft.MetadirectoryServices.IMAExtensibleFileImport.GenerateImportFile(String fileName, String connectTo, String user, String password, ConfigParameterCollection configParameters, Boolean fFullImport, TypeDescriptionCollection types, String& customData) in D:\ILM.Extensions\XMA_HR\XMA_HR.cs:line 102
Microsoft Identity Integration Server 3.3.1106.2"

This error hadn't manifested in development but popped up immediately after transitioning to our integration/QA environment. There were no timeouts that we could find anywhere in our connect strings or XMA code and the stored procedures the XMA was calling ran perfectly fine on their own but when called from the XMA it would bomb after several minutes. The culprit turned out to be a timeout masquerading as something else:

In the Run Profile UI for the Full Import step, the Timeout setting here looks like it is associated with the input file generation process and the successful processing of a full import. My take on this just from looking at the UI is that 90 seconds after my Full Import process has successfully completed the ldif file will be deleted.  However, this setting seems to have other subtle effects on the timing of the import file generation process beyond what is advertised and does not appear to be related to when the file gets deleted at all.

To get around this issue, set the timeout to zero (0) – the file is still deleted after the successful import but there is just no timeout for the process.

Sage advice from one Mrs. Laura Hunter…back during prep for TEC 2009 I was playing devils advocate to a problem she was having with ADFS that turned out (on a hunch) to be an issue caused from using the version 3 templates in her 2008 CA.  Last week Rebecca Croft and I ran into a completely separate issue when trying to use a certificate to encrypt and decrypt data in an XML file that turned out to be related to the same root cause.

Reb talks about the problem she encountered in more detail in her blog:

http://www.apollojack.com/2009/06/invalid-provider-type-specified.html

If you are working on an ILM2/FIM TAP, RDP or just kicking it around in the lab, you will want to use this handy little tool to test queries against the web service! Joe also provides a link to the source code project on CodePlex!

Why am I the only one not working on a FIM project! :(

CShark: Introducing the FIM Query Tool

Paleoidentology - the study or practice of uncovering long dead fossilized identities stinking up your nice pristine directory

I am posting this here since we occasionally come across this error in ILM/FIM and may be new to ILM implementers if you are not experienced with installing SharePoint. This error occurs because the IIS WAMReg Admin DCOM Server doesn't have Local Activation permissions.

Log Name: System

Source: Microsoft-Windows-DistributedCOM

Date: 9/4/2008 9:14:44 AM

Event ID: 10016

Task Category: None

Level: Error

Keywords: Classic

User: INFO\svc.wssfarm

Computer: ens-ilm01.ENSYNCH.INFO

Description:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{61738644-F196-11D0-9953-00C04FD919C1}

to the user INFO\svc.wssfarm SID (S-1-5-21-4163591863-704607480-62112183-1115) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Add the Local WSS_ADMIN_WPG and WSS_WPG groups and make sure that the Local Activation permission is checked for both. If you are using separate accounts for the Farm and the main Site Collection then the Farm account (svc.wssfarm in my case) will only be in the WSS_ADMIN_WPG group.