1dent1ty cHa0s

In case you missed the original announcement on the MIIS TechNet forums the is now available for download. Here is a sneak peek at the Disconnector report:

Link to original posting: MIIS Reporting Pack Announced for DEC 2007 Attendees

Here is a great example of what happens when you don't have a solid backup and recovery process for your databases and your identity information is not being enforced through an IdM application which enforces authority and ownership. Presumably, if the data weren't input by a person and it was fed from whatever system that stores the "federal hold" process then even if the database had been restored to a previous state, the state of the object would have been updated based on the policy.

This situation also speaks to a larger trend of pushing the responsibility back to the data owners. Sure, it's the prison's responsibility to manage the restoration of a failed database, but the federal system owns the "hold" process so their system would be held responsible in a mature implementation if the data was not found to be in the proper state.

Viva la IDM!

Link to TG Daily - Federal prison inmate accidentally released due to computer glitch

For several days my colleague Jerry Camel and I (keep your eye on Jerry's new blog) and I suffered from very odd behavior on an MIIS server we were building. Symptoms included the following:

• SQL 2005 Management Studio - the app would take forever to launch and present the connect dialog; while this was happening there was no activity in SQL Profiler and little to no CPU utilization
• Identity Manager -
  • Clicking tabs in IM would cause the cursor to hourglass and it would take several seconds at least to see a result
  • Starting a Synchronization would cause several records to throw extension-dll-timeouts (my timeout was set to 10 seconds) and then the rest of the run would seemingly run ok until Reference Reprocessing kicked in...
  • Reference Reprocessing would throw out of memory errors during every Identity Manager screen refresh cycle complaining that the step object details table could not be read

A look at the Application Event Log revealed the following MIIServer related error:

Event Type: Error
Event Source: MIIServer
Event Category: Server
Event ID: 6306
Date: 5/16/2007
Time: 3:04:51 PM
User: N/A
Computer: xxxx
Description:
The server encountered an unexpected error while performing an operation for the client.
"BAIL: MMS(432): mastate.cpp(8694): 0x8007000e (Not enough storage is available to complete this operation.): Error allocating memory
BAIL: MMS(432): server.cpp(5381): 0x8007000e (Not enough storage is available to complete this operation.)
BAIL: MMS(432): server.cpp(4275): 0x8007000e (Not enough storage is available to complete this operation.)
Microsoft Identity Integration Server 3.2.0559.0"

After much head bashing and hair pulling we found ourselves staring at the results of a 'netstat -a' query and trying to understand why the box was trying to reach a particular URL - http://crl.microsoft.com. A few searches later and we happened upon this posting:

Dan's Blog: SQL Server Management Studio Startup Time

As it turns out, this server had never been connected to a network that had internet access and therefore had never downloaded the Root Certificate updates from Microsoft. Further analysis of the Event Logs revealed many 'crypt32' errors indicating that the CRL could not be updated from Microsoft. While there may have been another method of forcing this update through other means, we opted for the quick and easy test on Dan's Blog which was to disable the "Check for publisher's certificate revocation" Advanced option in Internet Explorer. Disabling this option had an immediate effect - SQL Management Studio started immediately and MIIS Syncs processed error free - go figure.

Thanks to Dan for posting the original solution.