Dela via

MIIS 2003 Security Considerations

  • Artikel

Applies To: Windows Server 2003 with SP1

This document describes the recommendations for creating and operating a secure Microsoft® Identity Integration Server (MIIS) 2003 environment. Specifically, it discusses potential threats to each component of an MIIS 2003 infrastructure and makes recommendations on how to mitigate those threats or refers the reader to additional documentation detailing the specific solutions available.

Executive Summary

Your MIIS 2003 deployment is only as secure as the least secure component of its infrastructure. MIIS collects identity-related data from a variety of data sources and aggregates that data into a single data store. This MIIS data store is a single, authoritative source for the data and is a central point of administration. While this centralized collection and aggregation makes it possible for MIIS to present a single, complete, and authoritative view of each identity, it also concentrates some of the most sensitive data on your network into a single location. The broad, authoritative reach of MIIS and the sensitive nature of the data being managed make it imperative that you understand the potential security issues that can arise when you deploy MIIS 2003 and have a good security plan in place to deal with those issues.

Audience

This document is intended for anyone who wishes to understand the potential security risks to data managed by MIIS 2003. These include:

  • Corporate executives responsible for implementing procedures related to system security.

  • IT professionals planning deployment of MIIS 2003.

  • Owners and administrators of any potential connected data sources who wish to have a better understanding of any possible security risk to which their data may be subjected.

Scope

This document provides recommendations for addressing potential security issues related to the different components that exist in an MIIS infrastructure. The components covered include the computer running MIIS, SQL Server, the MIIS database, and the network used to connect them. Also included is a brief discussion about securing data sources in general.

This document does not replace resources describing security for Microsoft® Windows® Server 2003, Microsoft .NET Framework, Microsoft® SQL Server® 2000, and Microsoft® Windows Server 2003 Active Directory™. Rather, it should be used in conjunction with these other resources when planning your MIIS 2003 deployment.

Out of Scope

This document does not address security vulnerabilities related to specific connected data sources. For specific guidance on securing those data sources, see security-related documentation provided by the manufacturer for the particular data source.

The items listed here summarize security issues addressed in this document. Review these recommendations with your security organization to make sure that they are in compliance with your current security policies. Additionally, it is likely that your environment has other security considerations that are not listed here. Make sure that you consult with your own security organization to ensure that your MIIS 2003 deployment complies with all established security guidelines.

Recommendations for Account Management

  • Lock down the MIIS 2003 service account.

  • Use domain accounts rather than local accounts if possible.

  • Plan to use a remote SQL server to host the MIIS database or you plan to maintain a warm standby MIIS server. Then, use domain accounts to manage access rather than local accounts.

  • Enforce strong password policies for all user accounts.

  • Periodically change the MIIS 2003 service account password.

  • Control access with MIIS 2003 security groups.

  • Implement user rights and permissions to restrict software access to trusted accounts through the use of groups.

Recommendations for Server Management

  • Restrict physical access to computers to trusted personnel.

  • Restrict network access to the MIIS server.

  • Strictly control and monitor access to folders used to store drop files, scripts, extensions, and extension code.

  • Perform rigorous code reviews on all extension code to ensure that the code produces the expected results.

  • Make sure you handle any crash dump files securely.

  • Control debug rights to the miiserver process.

  • Implement the security best practices for SQL Server 2000.

  • Backup and protect the encryption keys.

  • Open only the ports necessary for a management agent to communicate with its connected data source.

  • Use SSL if you are setting initial passwords.

  • Ensure that the network context in which the MIIS server runs is behind a firewall.

  • Make sure that all servers are running the most current service packs and that any available hotfixes are installed.

Recommendations for Data Source Management

  • Grant only the minimal permissions required for a management agent to interoperate with a connected data source.

  • Control access to data at the data sources.

  • Review any security-related best practice recommendations for each connected data source and integrate them into your security plan.

Other Recommendations

  • Monitor your MIIS 2003 environment to ensure that everything is functioning as expected.

  • Monitor the permissions set on the resources used by MIIS and other security settings on all servers to ensure that no unauthorized changes are made.

  • Periodically review your current security policies and compare them to the current environment to ensure that the deployment stays in compliance as growth occurs and security policies are updated.

Infrastructure Components to Consider

When securing an MIIS 2003 installation examine the individual components of the installation and determine the potential security risks associated with each one. A typical MIIS 2003 deployment consists of four components, each with its own associated risks, the MIIS server, the SQL server hosting the MIIS database, any connected data sources, and the network used to connect these components together.

MIIS Security Considerations

Figure 1: MIIS infrastructure components

The MIIS 2003 Server - The MIIS 2003 Server hosts the user interface that provides access to all the data managed by MIIS 2003. It is also the location of any rules extensions used to process that data. The MIIS server might also be the location used to store data files for file-based management agents such as the delimited text file management agent. Security measures should be in place to control access to the user interface and to protect the rules extensions and data files so that unauthorized code and data cannot be introduced into the synchronization process resulting in the theft of, loss, falsification, or damage to the data managed by MIIS 2003.

MIIS Security Considerations

Figure 2: Security considerations for the server hosting MIIS

The MIIS Database - All data managed by MIIS 2003 is stored in a central SQL Server database. This database may be located on the same server that is hosting MIIS or it may be located on a separate SQL server. Follow normal SQL Server security recommendations to secure the SQL database used by MIIS.

MIIS Security Considerations

Figure 3: Security considerations for the MIIS database

Connected Data Sources -Connected data sources act as the source of data for MIIS. During synchronization, MIIS propagates changes made in one data source to other connected data sources to ensure that the data remains consistent across all connected data sources. Since MIIS propagates these changes throughout the enterprise, security measures must be in place to ensure that only authorized changes are introduced to the data sources.

MIIS Security Considerations

Figure 4: Security considerations for the connected data source

The Network - Data flows between the connected data sources and the MIIS server. If the MIIS database is located on a separate server then the data also flows between the MIIS server and the SQL server hosting the MIIS database. Take steps to prevent the theft of data by someone monitoring and capturing network traffic.

Each of these components represents a potential point of entry for a malicious user intent on damaging or stealing data being managed by MIIS. This document provides the recommended practices for securing an MIIS 2003 environment and specifically addresses potential security issues related to the four components listed above.

MIIS SEcurity Considerations

Figure 5: Security considerations for the network

MIIS Threat Analysis

In order to plan an effective security strategy, you must first understand the potential threats to your environment. In an MIIS 2003 environment, the majority of the threats can be broken down into two categories of security issues, unauthorized access to the data managed by MIIS and unauthorized access to the processes used to manage that data.

Unauthorized Access to Data

MIIS collects data from multiple data sources and provides a centralized point of administration for that data. While this makes it possible to provide a complete and authoritative view of the data, it also represents a point of interest for anyone attempting to access the data whether they have authorization or not.

When planning for security around managing access to the data, there are three areas to consider:

  • Protecting the data that MIIS has already collected

  • Protecting the source data that MIIS imports into its database and data that MIIS exports to the data sources

  • Protecting the data on the network as it moves between MIIS and the data sources.

Protecting Data Already Collected

As MIIS collects data from its connected data sources, it stores that data in a SQL Server database. All data that is managed by MIIS is stored in this database. Therefore, this database represents a single location where all managed data can be found. If someone can gain access to the database directly, they can read, modify, and delete data resulting the theft or loss of data.

Based on the configuration of your synchronization options, any changes made to the database might also be propagated to the connected data sources resulting in any damaging changes in the database being spread to other systems.

Your security plan must clearly define the steps required to prevent unauthorized access to the database.

Protecting Source Data

All data managed by MIIS 2003 originates in external data sources that are connected to the MIIS server. This means you must ensure that security measures are in place so that only authorized users are allowed to make changes and introduce new data at each connected data source.

MIIS imports the data from each data source and assumes that the data is legitimate. MIIS does not perform any verification to determine the authenticity of the data it receives from a data source. The assumption is made that if a connection can be established using the credentials configured for the management agent then any data received through that connection is legitimate. If unauthorized changes have been made to data at the data source, those changes will be imported and processed by MIIS along with any valid updates.

Your security plan must include the steps necessary to control access to the data at the data sources. For the purpose of security there are two types of data sources that must be considered. Some management agents connect directly to their data source and transfer data via a network connection while other management agents require an intermediate step where the data is temporarily stored in a text file that is transferred between MIIS and the data source.

The Active Directory management agent is an example of the type that connects directly. It establishes a direct connection between the MIIS server and the domain controller and all data transfer occurs via that connection. Text file based management agents import their source data from text files and export data by writing to text files. The text files might be located on the MIIS server or they might be located remotely on the connected data source. Regardless of their location, steps must be taken to ensure that the text files are not tampered with between the time the files are created and the time they are imported into their destination.

Protecting Data on the Network

The normal operation of MIIS involves the flow of data between the MIIS server and the connected data sources. As data flows into MIIS, it is stored in the MIIS database which is hosted on a SQL server. If any of the data sources are located on remote servers or the SQL server hosting the MIIS database is located on a remote server, then steps should be taken such as encrypting the data to protect the data as it flows across the network between the data sources and MIIS, as well as MIIS and the database.

Unauthorized Access to Processes

It is just as critical to control access to the processes used to manage the data in MIIS as it is to control access to the data. Once again there are three main areas of concern:

  • Access to rules extension code used to process the data in MIIS.

  • Access to the MIIS user interface.

  • Access to scripts used to launch MIIS operations from the command line.

Access to Extensions

As data is collected by MIIS, it might be processed by rules extensions. Rule extensions are customized blocks of code that control how the data is aggregated and redistributed to the data sources. Extensions make it possible to read and modify data as it is imported into the MIIS database and exported out of the database.

Access to the rules extension code should be tightly controlled. If someone gains access to the rules extension code they can modify the code to make unauthorized changes to the data, make unauthorized copies of the data, or to insert invalid data into the database to be propagated to other connected data sources. Only developers who are responsible for maintaining the code should have sufficient permissions to make changes.

Access to the User Interface

Access to the extension code is not the only consideration, access to Identity Manager, the MIIS user interface, must also be managed. If someone has full access to the user interface they can create new run profiles, install new management agents, change the configuration of existing management agents and read data in both the connector space and the metaverse. Someone with full access to Identity Manager has full access to all the data that MIIS manages.

Access to Command Line Scripts

It is possible to launch many of the processes managed by the user interface through the use of command line scripts and the Scheduler service in Microsoft Windows Server 2003. This method is used by many organizations to initiate fully automated unattended synchronization operations. If you plan on using scripts in this manner, your security plan should include the steps necessary to control access to those scripts. Depending on the operations being performed, a malicious user can use the scripts for unauthorized access to MIIS or some of the data sources being managed by MIIS.

Managing MIIS Security

The main security considerations with respect to an MIIS 2003 deployment are centered on controlling access to the data managed by MIIS and controlling access to the processes MIIS uses to manage the data. These considerations need to be applied to each component in the MIIS infrastructure: the MIIS server, the MIIS database, any connected data sources and the network used to connect all of these components together. Additionally, a good security plan must also define a monitoring process to ensure that all security policies are being enforced and functioning as expected.

MIIS Server Security

The MIIS server is the central point of access to all data managed by MIIS, any code used by MIIS for rules extensions, and scripts used for unattended operations. You should control access to these resources by setting permissions on them that restrict access to only a few select user accounts.

During installation, MIIS is configured to use specific accounts for different tasks. These accounts are granted a default set of permissions within the MIIS environment that make it possible for the MIIS server to function once installation is complete. In addition to the default settings, you might need to set additional permissions on rules extension code, scripts for unattended operations, and any locations on the MIIS server that are used to store data imported from connected data sources or data waiting to be exported to connected data sources.

Managing the Server Hosting MIIS

It is recommended that you install MIIS on a server that is a member of a domain. Installing MIIS on a member server makes it possible to remotely manage the server along with all the other servers in your environment. Most enterprises utilize some type of centralized management scheme including:

  • Remote administration of all servers.

  • Group policies to enforce machine and account policies consistently across all domains.

  • Centralized management of security updates to ensure that all servers are kept up to date.

Using a member server to host MIIS 2003 makes it much easier to ensure that it will be properly managed in accordance with the established policies of your organization and not get overlooked.

If possible, the member server should be dedicated to MIIS. Try to avoid additional workloads on the server such as Microsoft Exchange or Microsoft Systems Management Server. Also, it is not recommended that MIIS be installed on a domain controller. While there is no technical reason why MIIS cannot be installed on a server and share these workloads, each workload has the potential to utilize the majority of the server's capacity. Without careful planning configuring a single server to host so many workloads can easily result in performance issues.

If possible, avoid installing Microsoft Visual Studio on the server hosting MIIS in your production environment. All development work should be done outside the production environment and tested and debugged in a lab prior to release in your production environment. Installing tools such as Microsoft Visual Studio on the server in your production environment is not necessary for MIIS to function and it increases the effort required to securely manage the server and increases the available attack surface.

Managing Account Access

If the information that is synchronized with MIIS is sensitive, then personnel must be chosen with care. Administrators, developers, and other personnel with access to MIIS files potentially have the ability to modify this data and get those modifications propagated to all connected data sources.

Unless it is absolutely necessary to have an administrator work directly on the server that is running MIIS, have administrators use Terminal Server to remotely access the server. By using Terminal Server, they do not require local administrator rights on the server.

As a general rule, assign users only the minimum permissions that they require to use the directories, files, and database objects, and the information they can access through the MIIS administrative tools. Assign administrators the minimum permissions that they require to do their jobs. When an administrator only works with a subset of the data in your system, assign the administrator permissions to that data only.

The MIIS Service Account

MIIS runs in the context of a specific account. During the MIIS Setup process, you are prompted for the name of the account that is to be used as the service account. Based on that account name, MIIS Setup configures permissions throughout the system on the MIIS-related folders and grants the necessary permissions to the service account.

Lock down the Service Account

The service account should not be used by any other services or users. The account must not be used to logon interactively and requires no access to any additional resources beyond those granted during setup. The service account is used to provide the security context for the MIIS service as it accesses resources on the MIIS server and the associated database. It also provides the security context for the execution of any rules extensions.

Lock down the service account to ensure no malicious user is able to sign in using its credentials and gain access to MIIS data. Configure Group Policies to lock down the account and restrict access to this account. Since the MIIS service only needs the account to run as a service, restrict the account as follows:

  • Deny logon as a batch job.

  • Deny logon locally.

  • Deny logon through Terminal Services.

  • Deny access to this computer from the network.

Use of Local and Domain Accounts

The service account can be a local account or a domain account. It is recommended that you use a domain account if possible. If the MIIS database is installed on the same server as MIIS, there are no resources the service account is required to access outside of the MIIS server, so an account that is local to the MIIS server can be used. Using a local account means the owner of the MIIS server handles the creation and maintenance of the account rather than relying on the organization's IT infrastructure or account management team to create, lock down, and maintain the account. This is the main disadvantage of using a local account. It will not be automatically managed by the domain. If a local account is used, steps must be taken to ensure that it is maintained within compliance of your organizations account management policies. You need to manually take care of issues like password management.

If MIIS and the SQL server hosting the MIIS database are installed on separate servers then a domain account is required to grant the necessary access. If there are plans to implement a warm standby for fault tolerance, a domain account is required. Domain accounts are easier to manage because account policies can be managed and enforced through the use of Group Policy throughout the domain. It is not a matter of domain accounts being more secure than local accounts. Rather, domain accounts can be centrally managed and are subject to established domain and forest-wide policies. This means that there is a better chance that the domain accounts will be properly managed thus reducing the chance of introducing new vulnerabilities to your infrastructure.

Passwords Policies

Make sure that you use strong passwords for all accounts used by MIIS. Strong passwords meet the following criteria:

  • At least seven characters long.

  • Does not contain the user's user name, real name or company name.

  • Does not contain a complete dictionary word.

  • Is significantly different from previous versions of the password.

  • Contains some of each: uppercase letters, lowercase letters, numbers, and symbols.

In addition to using strong passwords, periodically change the passwords for the credentials being used by MIIS, especially the password for the MIIS service account. If your organization does not already have an established policy regarding password age, you should change the passwords used by MIIS at least once every 42 days.

MIIS Group Accounts

User access to MIIS-related resources should be managed through the use of group memberships. During installation, MIIS configures the default access rights to files and determines which tasks users can perform by creating a default set of groups and granting access to those groups. When there is a need to grant or revoke a user’s access to MIIS, these groups provide a simple, single point of administration.

Five groups, based on typical user roles, are used to manage access in an MIIS environment. During setup, MIIS asks for the names of the five groups so it can configure permissions on the MIIS files and folders. You are given the choice of specifying your own group names or accepting a list of default names provided by MIIS Setup. The default group names and their intended purposes are:

  • MIISAdmins - Members of this group have full access to Identity Manager.

  • MIISBrowse - Members of this group are granted permission to gather user information through the use of Windows Management Instrumentation (WMI) queries.

  • MIISJoiners - Members of this group can perform metaverse search operations in Identity Manager and can perform join and disconnect operations.

  • MIISOperators - Members of this group can run management agents, view synchronization statistics and save run histories.

  • MIISPasswordSet - Members of this group can perform all operations using the password management interface with WMI. This group also inherits the permissions of MIISBrowse.

    Note

    During installation and setup, the user account that is running the installation is added to the MIISAdmins group, but only if the MIISAdmins group is also created during setup. During setup, if you replace MIISAdmins with a preexisting group, the user account that is running the installation is not added to that preexisting group.

During setup, these groups are granted various levels of access to the MIIS-related folders and the MIIS database. Table 1 lists the rights to the default MIIS 2003 folders that are granted to each group.

Table 1 Group Rights to Default MIIS 2003 Folders

Folder Group Rights Other Groups Rights

Program Files\Microsoft Identity Integration Server

MIISAdmins

Full

MIISJoiners

MIISOperators

MIISBrowse

MIISPasswordSet

Read and Execute

List Folder Contents

Read

Program Files\Microsoft Metadirectory Services\Bin

MIISAdmins

Full

MIISJoiners

MIISOperators

MIISBrowse

MIISPasswordSet

Read and Execute

List Folder Contents

Read

Program Files\Microsoft Identity Integration Server\Data

MIISAdmins

Full

MIISJoiners

MIISOperators

MIISBrowse

MIISPasswordSet

None

Program Files\Microsoft Identity Integration Server\Documentation

MIISAdmins

Full

MIISJoiners

MIISOperators

MIISBrowse

MIISPasswordSet

Read and Execute

List Folder Contents

Read

Program Files\Microsoft Identity Integration Server\Extensions

MIISAdmins

Full

MIISJoiners

MIISOperators

MIISBrowse

MIISPasswordSet

None

Program Files\Microsoft Identity Integration Server\MaData

MIISAdmins

Full

MIISJoiners

MIISOperators

MIISBrowse

MIISPasswordSet

None

Program Files\Microsoft Identity Integration Server\UIShell

MIISAdmins

Full

MIISJoiners

MIISOperators

MIISBrowse

MIISPasswordSet

Read and Execute

List Folder Contents

Read

You must control access to these MIIS folders by adding or removing user accounts to these groups, not by directly granting individual user accounts access.

MIIS Setup creates these groups as local groups rather than domain groups if possible. If MIIS is installed on a domain controller then the groups will be created as domain groups, provided that the user performing the installation has domain administrator privileges.

If two MIIS servers are to share a database for the purposes of hot standby, these groups need to be domain local groups. Domain local groups can include members of other domains and are available to multiple domain controllers within a domain. If MIIS management is distributed across the organization, the domain local groups let you grant access to the appropriate users within the entire organization. Also, if the MIIS configuration needs to be moved from one computer to another, the same group will be available, provided the new computer is in the same domain.

Note

If you need to control access to additional resources that are not automatically configured during setup, such as temporary storage locations for text files used by management agents, it is recommended that you grant permissions to local groups and add the groups created during setup to those local groups.

Limit memberships of security groups and the access control lists to make sure that access is restricted to the smallest possible set of users and groups.

MIIS Users

MIIS users are not required to be part of the local machine administrators group. Once MIIS setup is complete, users should logon with user accounts that are less privileged than administrators and are members of security groups used to control access to MIIS. The minimum privilege required, outside of the permissions set by MIIS, is the ability to logon to the computer. Access to folders and MIIS UI components is controlled by the user account’s membership in the MIIS security groups (discussed earlier in the MIIS Group Accounts section).

File and Folder Protection

During the installation of MIIS, you must provide the names of the group accounts that will be used to manage access to MIIS. The setup process creates the default folder structure and grants the default permissions based on the account names you provide. For the most part, users do not need access to any of the MIIS folders with the exception of the MaData and extension folders. It must be possible for users to place data files in the MaData folder and it must be possible to update the extensions folder. By default MIISAdmins, the MIIS service account, the local administrator account and the system account are granted full access to these folders.

Based on the configuration of your environment, MIIS might be dependant on a number of text files stored outside of the folders managed by MIIS. They might contain code for rules extensions, or they might be script files used for unattended operations. Steps should be taken to prevent these files from being scanned for sensitive data while they are waiting to be processed by MIIS.

The text files used for import and export operations, often referred to as drop files, must be placed in the MaData folder for the text file management agent to use them. Access to this location is restricted and default permissions are set on this folder during the installation of MIIS. However, many drop files will be stored in temporary locations throughout their lifetime between the time they are used by their data source and the time they are placed in the MaData folder. Access to those temporary locations should be limited to the user responsible for managing the drop files.

Custom Extensions

To provide the flexibility to customize MIIS so that it can be used in almost any environment, the MIIS architecture utilizes customized rules extension DLLs. When management agents are run, MIIS calls these DLLs to perform customized operations on the metaverse and connector space objects in the database. The extensions modify the stored data and affect how data flows throughout the MIIS environment.

Specific folders are created during setup to store these extensions. When MIIS 2003 is installed, full rights to the Extensions and ExtensionsCache folders are granted to the MIIS 2003 service account, the MIISAdmins group, and the account that was used to run Setup. To grant rights to these folders to someone else, you must set permissions on the folders manually.

If a malicious user can gain full access to these folders they can replace an existing extension with one of their own that is intended to steal, modify, or monitor existing data for sensitive information. Access to the source code for your extensions should be controlled as well. The files for your source code are text files that can be viewed with any text file viewer. If a malicious user can get access to the compiled rules extension it is possible that the user can decompile the rules extensions and expose sensitive data. Simply preventing write access to this directory is not sufficient to protect the data. Avoid putting credentials and any other type of security-relevant information in code if possible. If you find that your code needs access to security sensitive information, such as user credentials, utilize some type of secure external data store to maintain the credentials rather than including them in your code. Use secure API calls such as CryptProtectData to access the secure data store and retrieve the credentials when needed. This prevents direct access to security sensitive data by simply examining code.

It is recommended that you limit and monitor access to the Extensions and ExtensionsCache folders.

Note

The ExtensionsCache folder is hidden by default. However, because it contains the extension assemblies, it should have the same restricted access as the Extensions folder.

The locations for these critical assets should be secured as highly as a password database or administrator password. The process of adding extensions to the MIIS configuration must take into account the information that can potentially be in your code and the fact that the code can potentially be used to access all of the data in the metaverse.

Design Reviews for Extensions

Before adding extensions to the MIIS configuration, stakeholders representing the different groups within the organization whose data is being managed by the MIIS environment should review the intended functionality of the proposed extensions. Each stakeholder should understand how these extensions will affect their data and sign off on the design. Once the extensions have been created and tested, someone needs to verify that they function according to the design specification and sign off on the extensions.

Scripts for Unattended Operations

Scripts can be used to launch processes, such as imports and synchronization, in MIIS. Many administrators write scripts to initiate processes like these and then schedule these scripts to be run periodically throughout the day. This type of automated, unattended operation makes it possible for MIIS to stay as up-to-date as possible without the need for an administrator to constantly be on hand to initiate the processes. This type of operation is common for time critical processes such as synchronizing password changes across multiple systems.

While this type of scripted operation is convenient for administrators, it also has the potential to expose sensitive information if proper security measures have not been put in place. The script files are plain text so credentials should not be stored inside the scripts themselves. Some scripts might require special credentials to function properly. If this is the case do not place those credentials inside the script code, instead design your scripts to use more secure methods of acquiring the credentials they need. Alternatives include using the Windows Task Scheduler service to launch the scripts within the context of the Windows System account rather than the user who is currently logged on. Another method is to have the script prompt the user for the proper credentials during run time, although this requires user interaction at the time the script is run so it may not be desirable behavior. As an alternative, you can store the credentials in some external secure location and design the script to access that location and retrieve the credentials as needed. Make sure that you set the proper permissions on any folders used to store the scripts and restrict access to those script files. The only account that needs access to those files is the account configured in the scheduler to launch the scripts or the user who is launching them manually.

Deletion Threshold

The identity integration process is capable of performing all basic operations on objects in the connected data sources. This means that the process can create, modify and delete objects in each data source if it is configured to do so. The identity management process can become quite complex, especially when multiple management agents are involved and customized rules extensions are created to control how data flows into and out of MIIS.

Even a carefully planned implementation does not guarantee protection from unwanted and accidental updates to objects. In most implementations, changes are pushed out of the identity management process to the connected data sources. If any unwanted or accidental changes occur they can spread to the connected data sources quite quickly and become a much larger issue before any problem is detected.

If objects are created or existing objects are modified as a result of an unwanted or accidental update, the process can be reversed to solve the problem. It might require extra work but the problem can eventually be undone. If objects are deleted as a result of the unwanted process then the problem is more serious and may not be able to be undone. The depth of the problem depends on the connected data source involved. For example if an object is deleted in Active Directory it cannot be recreated. When they are created, objects in Active Directory are assigned a globally unique identifier (GUID). The GUID is unique to that object and is destroyed when the object is deleted. If the object is recreated in the directory, the new instance of the object will have a different GUID and therefore be treated as a different identity. All permissions and group memberships must be reconfigured for the new object.

Performing object creation or update operations on large numbers of objects at a time are fairly common operations while performing bulk deletions are not. In some environments, however they do occur. One example would be to undo a bulk creation.

If you need to perform some type of destructive operation, such as deleting objects, and you need to perform this operation on a large number of objects, be extremely careful and test the process prior to implementing it in your production environment. When configuring the run profiles for management agents, limit the number of deletions that can occur during each run by specifying a deletion threshold. The deletion threshold makes it possible to limit the damage done should unwanted object deletions occur. If you are using scripts to run management agents you can further make sure that the script code monitors the number of objects being deleted and halts the process immediately if anything unusual occurs.

Standby Servers

From the standpoint of security, a warm standby MIIS server is just a copy of the original and you should configure the security-related settings on the standby the same as on the original MIIS server. This is why it is recommended that you use domain groups and accounts to manage access if your environment is going to maintain a warm standby MIIS server. Domain accounts will be available on both servers where local accounts are not

If you plan on using a warm standby server in your MIIS environment, you should create your security groups prior to running MIIS setup. During the installation of MIIS, you can provide the names of the groups you created so MIIS setup can set the appropriate permissions. You should create groups that you can use in place of the default groups normally created during the MIIS installation. Specifically, prior to installing MIIS, create groups that you can use in place of the following default groups:

  • MIISAdministrators

  • MIISOperators

  • MIISJoiners

  • MIISBrowse

  • MIISPasswordSet

During setup, provide the names of the groups you created so that setup grants permissions based on the new group names. Make sure you use the same group names when running Setup on both the original MIIS server and the warm standby. Since the same domain groups are used to set permissions on both MIIS servers, the ACLs contain the same security principals.

After installation is complete, if you need to grant permissions to specific users, do so by adding their user accounts to one of these groups.

Data Exposure During Troubleshooting

Make sure that you take precautions to avoid exposing sensitive data while performing troubleshooting operations such as sending crash dump files and running debuggers.

Crash Dump Files

It is possible that any crash dump files that you use to troubleshoot MIIS 2003 might contain sensitive data. If you need to transmit one of these crash dump files, make sure that you use a secure medium. If possible:

  • Enable users to upload the files to secured HTTPS sites utilizing SSL connections

  • Use a non-Microsoft SSL-enabled FTP application.

  • Use secure e-mail.

  • Encrypt the files.

Debugging

While it is not recommended to have the development environment installed on the same server that is hosting the production version of MIIS 2003 for your organizations MIIS 2003 deployment, some organizations might choose to do so for troubleshooting purposes. Be aware that sensitive data being managed by the miiserver process can be viewed in the debugger. Make sure that only authorized personnel are granted permission to debug the miiserver process.

MIIS Database Security

MIIS 2003 uses a Microsoft SQL Server 2000 database, named MicrosoftIdentityIntegrationServer, as its central data store. During the installation of MIIS, Setup configures the necessary permissions on this database automatically to make certain that no one can directly access the database. Direct access can cause corruption of the database, failure of the server running MIIS 2003, and loss of data. Apply your company’s security standards to the SQL Server database but make sure you do not change the privileges granted to the MIIS service account during MIIS installation.

Access to the Database

During installation of MIIS 2003, Setup creates the MIIS database and grants full access privileges to the MIIS service account and the user account used to run the installation process. This is accomplished by assigning ownership of the MIIS database to these accounts. By default, database owners have full access to their designated databases.

All access to the database takes place within the context of the service account so no additional accounts require access to the database for MIIS to run properly. Lock down the MIIS service account and make sure that only the MIIS server process uses the credentials. Lock down of the MIIS service account is discussed earlier in the section MIIS Server Security.

Remote database

The MIIS database can be located either on the same server that is hosting MIIS or on a separate SQL server. If the database is located on a separate sever there are two additional requirements. First, the MIIS service account must be a domain account. This makes it possible for the necessary privileges to be granted on both the MIIS server and the SQL server using the same account. Second, you must configure the polices on SQL server to allow the MIIS service account to access the server from the network.

Backup and Restore of Database

Regular backup procedures are essential for protecting your data from accidental loss. While the MIIS database does contain a copy of the identity-related data used on your network, you should not rely on MIIS to act as a backup solution for that data. There are two main reasons for this. First, it is likely that the MIIS database only contains a subset of the identity data from each data source used on your network. Second, in many organizations the data stored in the MIIS database is the result of many complex business rules that have collected and consolidated the data from many different data sources. The business rules used may only be designed to collect the data and consolidate it into the database. Additional work would be necessary to retrieve the appropriate data and send it back to a data source if a restore type operation is required. It would be much more efficient to use a normal backup system.

Establish regular backup procedures for the MIIS 2003 database. Some organizations feel that the MIIS database is a copy of existing data, and therefore there is no need to back up the database. The feeling being that if the MIIS database is lost, it can simply be recreated. It is important to remember that the data in the MIIS database is a consolidated collection from multiple data sources. If the entire database needs to be rebuilt, similar to a restore operation, the collection and consolidation process might be fairly time consuming and impact many data sources. While this is dependant on the amount of data stored and the number of data sources involved, it is likely that restoring the database from a normal backup would be much more efficient and have much less impact on the connected data sources than attempting to use MIIS to rebuild it to the current state.

Critical data for MIIS is stored on the server that hosts MIIS 2003 and on the server running SQL Server 2000 that hosts the MIIS database. The critical data hosted on the MIIS server is the encryption keys used by MIIS to access information stored in the MIIS database. The critical information located on the SQL server is the MIIS database itself. If you ever need to restore the database to a new server and access it from a new MIIS server, you need both the backup of the database and the backup of the encryption keys.

Note

Encryption key data is not stored in the MIIS database. Therefore, even if your installation is configured such that MIIS and the SQL server hosting the MIIS database are installed on the same server, you still need to backup both the MIIS database and the encryption keys. Simply backing up the MIIS database does not include the encryption key data.

All passwords related to MIIS 2003 data are accessed by using the encryption keys. It is possible to restore the database without a backup of the encryption keys. However, doing so requires additional steps during the restore process and might result in the temporary loss of some data. Specifically the data can be in the form of:

  • All passwords that are used by management agents to authenticate to connected data sources. These can be reentered manually.

  • All passwords for user objects that were in the process of being provisioned. You can view a list of these user objects by searching the connector space with a scope of Pending Export/Add. You can then disconnect and reprovision these user objects or continue to export them and set the passwords manually.

For more information about how to backup the MIIS database, see Backing up Microsoft Identity Integration Server 2003 in Microsoft Identity Integration Server 2003 Help.

For information on how to restore the MIIS server, see Restoring Microsoft Identity Integration Server 2003 in Microsoft Identity Integration Server 2003 Help.

Encryption Keys

Some data that is managed by MIIS 2003 is encrypted before being stored to prevent unauthorized use, should someone manage to gain access to it. For example, most management agents are configured to use sensitive data, such as the credentials used to access the associated data sources, which get encrypted before it is stored in the MIIS database.

For example, MIIS encrypts the passwords that it stores whether they are passwords used by management agents connecting to data sources or passwords that are part if identities being managed by MIIS. During installation, MIIS generates encryption keys that it uses to encrypt these passwords prior to storing them and stores these encryption keys in the registry of the server hosting MIIS. This means that each installation of MIIS has an associated set of encryption keys and those keys are necessary for that instance of MIIS to be able to access any passwords stored in its database. If a backup copy of an MIIS database is restored to a new installation of MIIS the encryption keys from the new installation will not match the keys used to encrypt the passwords stored in the backed up database. The new MIIS server will not be able to read any of the stored passwords.

There are two solutions to this problem. One is to maintain a backup copy of the encryption keys from the original MIIS server using the MIIS Key Management Utility, Miiskmu. The other is to reenter the passwords for the management agents and re-import any data that was encrypted using the previous keys. If there were any pending provisioning requests that involved password data they will be discarded.

The key management utility allows you to make a backup copy of the keys and to restore them to a new installation. If you use this utility to back up the keys make sure that you keep the backup copy of the keys in a separate location. In their backed up state, the keys are unprotected and vulnerable.

The MIIS Key Management Utility allows you to perform other administrative functions related to key management. It has two different user interfaces, a command line interface and a Windows wizard. The command line interface is sufficient for most encryption key backup and restore operations. The MIIS Key Management wizard can perform more advanced backup operations, such as adding or removing keys from the key set. To use the MIIS Key Management Utility and perform back up operations on the encryption keys, you must be logged on as a member of one of the MIIS security groups and have administrative credentials on the local computer.

If the previous versions of the keys are not available, for example, the original server is no longer available and the keys were never backed up, you can regenerate a new key set and reenter any existing management agent credentials so they can be encrypted using the new key set. If you select this course of action, any pending password synchronization events will be lost and you must initiate these synchronization events again.

The health and security of the encryption keys should be maintained at all times. They are stored in the registry in the service account's user profile. Permissions are set so that the service account is the only security principal that has access to them. It is not possible to monitor the ACLs set on the keys since the key ID is obscured for extra protection. Make sure that there is always a current backup of the encryption keys available.

For more information on how to backup the encryption key, see Backing up the Microsoft Identity Integration Server 2003 Encryption Key in Microsoft Identity Integration Server 2003 Help.

Database Size Restrictions

Databases that grow on small hard drives or hard drive partitions can eventually cause SQL Server to fail. In order to prevent SQL Server from failing in this circumstance, you can do two things. First, regularly back up and restore the database. This clears the log file and posts all pending transactions to the data file, which can reduce the amount of space the databases needs in the file system. Second, determine the maximum file size that you want for the database. This allows SQL to handle the condition gracefully, and prevents SQL Server, and therefore MIIS, from having unhandled exceptions.

The goal is to prevent a denial of service attack on the SQL Server where a malicious user might attempt to cause server failure by writing large quantities of data to the database until all available disk space is used up.

More Information about SQL Server

  • For more information about managing the SQL Server in an MIIS environment see Maintaining the MIIS 2003 Database at the Microsoft Web site (https://go.microsoft.com/fwlink/?linkid=31005).

  • For more information about managing the SQL Server, see SQL Server Books Online for SQL Server 7.0 on the Microsoft Web site (https://go.microsoft.com/fwlink/?linkid=16410).

  • For more information about data base ownership see Microsoft SQL Server 7.0 Help, Chapter 8 - Database Architecture.

  • For more information about backing up and restoring SQL databases see SQL Server 7.0 Product Documentation, Chapter 3 - Backing Up and Restoring Databases.

Data Source Security

MIIS 2003 manages the relationship of data that is stored across multiple data stores. If a change is made to data stored in one location, MIIS 2003 ensures that the change is propagated to any of the other data stores that are maintaining copies of the affected data. Security must be maintained on these data sources to ensure that only legitimate changes are made in order to prevent MIIS from being used to propagate unauthorized changes throughout the enterprise.

Examples of unauthorized changes could be the modification of existing data, such as renaming user accounts, or the deletion of data. Another possibility is the injection of false data such as fake usernames with the intent of provisioning false user accounts to one of the other data sources.

Controlling Access at the Source

Data source security should be looked at from two perspectives. First, managing the flow of data coming into the MIIS environment through the data source, and second, managing the flow of data from the MIIS environment into the data source. Access to the data source must be controlled to ensure that any data added at the data source or any changes made via the data source are made by authorized users. More sophisticated data sources, like directories and HR systems, most likely have integrated security features to prevent unauthorized access thus preventing the injection of bad data into the MIIS environment. The less sophisticated data sources, such as text files, have no native security and it is up to you to make sure that they are stored in a protected location.

Managing data flow from MIIS into the data source is not so much a matter of setting permissions as it is a matter of making sure that management agents are performing as expected. Once a management agent has been configured and a connection is established between the data source and the MIIS server, all data flow originating at the MIIS server is assumed to be legitimate. Managing the data flow is accomplished by changing the configuration of the management agent. This might mean changing attribute flow rules or changing the behavior of various rules extensions. Not really a matter of security. From the security perspective, managing the flow of data from MIIS into a data source includes having a monitoring solution in place to ensure that no unexpected changes are being made and also to alert the appropriate personnel if such an event occurs.

Another method of controlling access at the data source involves using specific containers to store data sent to and received from MIIS. This makes it easy to control the scope of influence that MIIS has over the data stored in a given data source. An example of this type of strategy can be demonstrated using Active Directory organizational units (OUs). Rather than granting the Active Directory management agent read and write access to the users container where it potentially can access all user accounts, create a separate OU to contain the account data managed by MIIS and grant the Active Directory management agent read and write access to that OU. Since this OU is the only container that the management agent has been granted access to, MIIS will only be able to affect the data stored in this single OU.

Another strategy to help maintain the scope of authority over specific data involves the creation of two separate containers on the data source, one for data that the data source is authoritative for and one for data from other authoritative sources. Once again this can be demonstrated using Active Directory OUs. Create two OUs in the directory. Grant the Active Directory management agent read only access to one OU and full access to the other. If the directory is the authoritative source for any of the data being managed, meaning that changes to the data can only be made in the directory and no other data source may make changes to the data, then that data is stored in the OU where the management agent only has read permissions. Since no other data source is allowed to make changes to this data there will never be a need for the management agent to write data to this OU. If updates are made to the data in the directory, the management agent can still read those changes and export them to other data sources if necessary.

In the case of any data for which the directory is not the authoritative source, if changes are made at one of the other data sources, those updates can be provisioned to the OU where the management agent has full access. This way the management agent can only write changes to the data where the directory is not the authoritative source. While all of this can be done using other methods, the separate containers make it easy to see which data is being managed by MIIS and which data is being managed by the directory.

Responsibilities of Data Source Ownership

Data source owners need to be aware of the data that flows into and out of their systems. While some data sources have their own natively integrated security systems and others do not, all data sources require a complete security review before being integrated into an MIIS environment. The owners need to be aware of the management policies of any other data sources that might be contributing data flowing into their systems through MIIS so they can be sure that the integrity of the data they manage will not be compromised through the import of data from another connected data source that might have more relaxed management policies.

It is important that data source owners understand the relationship between their system and the other data sources. Information about any connected data source is theoretically open to read and write operations from the other connected data sources. The exact access these data sources have to one another depends on the exact configuration and who has authentication rights on each part of the system. As more data sources are introduced into the environment the relationships between each of them become increasingly complex. To protect the data on each connected data source, the team responsible for internal security planning should carefully map and document these relationships to determine the security exposure and minimize the potential risks.

The document produced as a result of this process will identify potential security risks and the proposed steps needed to eliminate, or at least reduce the exposure of, those risks so it should be stored and protected accordingly. All data source owners should sign off on this document to indicate their understanding of any potential risks and their acceptance of the steps being taken to manage those risks.

This will be a living document. Each time a new data source is added to the MIIS environment this document should be updated and redistributed to the data source owners so they are aware of any impact by the new source.

Security Requirements for Management Agents

MIIS 2003 is capable of using many different data sources. Some of the management agents that are included in MIIS 2003 make it possible to connect to Microsoft Windows Server 2003 Active Directory, Active Directory Application Mode (ADAM), Microsoft Exchange Server 5.5, IBM® DB2®, Lotus Notes®, Oracle databases, miscellaneous LDAP servers, Microsoft SQL Servers and Sun directory servers. Each of these data sources has its own requirements with respects to the credentials needed to make it possible for MIIS 2003 to connect to them.

Detailed security requirements for some of the management agents included in MIIS 2003 have been documented in "MIIS 2003 Management Agent Communication Ports, Rights, and Permissions" that you can obtain from the Microsoft Web site (https://go.microsoft.com/fwlink/?linkid=38680).

Execution of extension code

The ability to extend the functionality of MIIS though customized DLLs is a powerful and flexible feature of MIIS. It also means that extra care must be taken to ensure that the customized code does not introduce any new vulnerabilities to your environment. When writing customized rules extensions you should avoid directly accessing any connected data sources or other external systems. Ensure that all access to a connected data source takes place though a management agent designed to communicate with that data source. This makes it possible for MIIS to manage the security involved in the communication without relying on code from an external source.

If your extension code must directly access an external data source, make sure that all the security policies you apply to the rest of your MIIS environment are also applied to that source so it cannot be used as a point of entry by a malicious user and all data from that source can be trusted. Make sure that the code includes robust exception handling around the communication with the external source. Extension code is processed during the synchronization process. If problems occur in the code, such as trouble communicating with an external data source, and the exceptions are not properly handled properly then the error can cause the synchronization process to fail. This situation could be leveraged by a malicious user to interfere with the operation of your MIIS environment.

Text File Management Agent

Some systems, such as HR systems, often have security policies that prohibit direct connection to other systems. To share data, the HR systems create drop files that are text files containing exported data for import into MIIS. These files might also be used to export data from MIIS and then import it back into the HR system. MIIS 2003 uses the text file management agent to import and export data to these files.

These files must be protected at all times. If they are tampered with prior to being imported, they can be used to introduce invalid data into the metaverse, which may end up being provisioned to other data sources. Whether they are intended for import or export, the files likely contain confidential information, so you must control the access to these files at all times.

To ensure the integrity of that data, it is vital that the permissions set on the folders containing these drop files be as restrictive as those on your MIIS folders. If the environment is set up so that these files are periodically downloaded from other systems to a centralized drop location, make sure that access to the files is strictly controlled both at the source and destination locations. In many instances, these files will be written to folders other than those utilized by MIIS 2003 management agents. MIIS Setup does not set the privileges on folders outside the scope of control of MIIS. In order to keep your environment secure, access to these folders at their remote locations should be just as secure as the MIIS management agent data folders on the server hosting MIIS.

The location of these data sources might also affect whether you want to use groups local to the server or domain local groups to control access. If at least one source location is on another computer, it is easiest to use domain local groups.

Network Security

During import and export attribute flow, data moves between the connected data sources and the MIIS server. In most deployments, the connected data sources and MIIS will be located on different servers and this movement of data will take place over network connections between the servers. These network connections represent another potential entry point for unauthorized access to the data being a managed in the MIIS environment.

The risk of unauthorized access can be reduced by closing unnecessary ports and using secure communication between the data sources, the MIIS server, and the SQL server hosting the MIIS database, if it is located on a server separate from the MIIS server.

Communication ports

Call-based management agents require open ports for each service and protocol being used to establish secure communication channels between MIIS 2003 and a connected data source. If password synchronization is enabled, ports must also be opened for RPC on both the server running MIIS 2003 and all Active Directory domain controllers.

If you configure SQL Server 2000 to use a communications port other than the default SQL Server port 1433, you are required to reconfigure the SQL Server client's communications port on the computer on which you run MIIS 2003. Use the SQL Server Client Network Utility to do this.

For a complete list of the ports used by the management agents included with MIIS 2003 and the SQL server hosting the MIIS database, see "Port Settings for Microsoft Identity Integration Server 2003" at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=30737).

Secure Communication

When possible, use secure communication to reduce the risk of unauthorized access to data by individuals monitoring network traffic. Various network data encryption technologies are available for Microsoft Windows Server 2003. Whether or not you can use these encryption technologies is based on whether the connected data source supports them and whether or not the corresponding management agent also supports them. Three common examples of network data encryption technologies are SSL, TLS, and IPSec.

SSL

Secure Socket Layer (SSL), can be used in an MIIS environment. If the connect data source supports the use of SSL and a management agent is included with MIIS 2003, then the use of SSL is supported for that particular data source.

Verify the level of encryption between MIIS 2003 and the target data source. When setting initial passwords set up SSL and use LDAP with SSL to communicate with Sun ONE™ Directory Server 5.1, Netscape Directory Server® 6.1, Novell® eDirectory™ 8.7, and directory servers running Active Directory Application Mode (ADAM).

TLS

The use of Transport Layer Security (TLS) is not supported in an MIIS 2003 environment.

IPSec

Internet Protocol Security (IPSec) is a tunneling protocol used within the TCP/IP protocol. Use of IPSec is completely transparent to MIIS and therefore can be used without any effect on the operation of MIIS 2003. If the SQL server hosting the MIIS database is located on a server separate from the MIIS server using IPSec is recommended to help make communication between the two servers more secure.

Place the MIIS Server behind a Firewall

If possible, place the server running MIIS 2003 behind a firewall. Use the information discussed in the Communication Ports section to open a tunnel from the MIIS server to connect to the other servers hosting data sources if they are not already on the same side of the firewall.

If your security policies prevent the opening of communication ports in your firewall, consider using text files to move data between an MIIS server on one side of the firewall and the data source on the other side of the firewall. That way no direct connection is required.

Security Monitoring

After the initial deployment you should continue to monitor your MIIS 2003 installation to ensure that all security measures remain in place and are functioning as expected. Having a monitoring solution in place can help detect potential threats before they have caused any serious problems. If a breach of security does occur, a monitoring solution can help detect the problem quickly so the issue can be resolved as soon as possible.

Key areas to monitor on the MIIS server include:

  • Group memberships

  • Access Control Lists

  • Unauthorized access attempts

Monitor Group Membership

Monitor membership in the groups you use to control access to MIIS files and folders. MIIS creates these groups during setup. Once installation is complete, any change to the membership of these groups is evidence of manual intervention. After setup, MIIS 2003 makes no additional changes to the group memberships. If any changes are made to these security groups after the initial setup and the source of those changes cannot be identified, then it is possible that your security measures have been compromised. You should immediately perform the following steps:

  • Back up the MIIS database and encryption keys.

  • Delete the security groups currently being used to manage MIIS privileges

  • Change the service account credentials.

  • Create new security groups for MIIS management (do not reuse the old group names).

  • Run MIIS 2003 Setup and use the new names for the security groups (the new service account and security groups).

MIIS 2003 Setup resets the access control lists on the folders where the MIIS 2003 program files, extensions, and data files are stored using the new names. Remember to update security settings on any other folders, such as temporary drop file locations, where you used the old security groups to manage access.

Monitor Access Control Lists

Regularly check the ACLs on the folders used to store MIIS data and extensions. Make sure that you include any remote folders that may be used for temporary storage of drop files or source code used for scripts or extensions. Check the ACLs to verify that no unauthorized users have been added. Also, make sure that no users have been granted any unauthorized elevation of permissions.

If discrepancies are found, reset the ACLs to the desired settings. If you are unable to determine the origin of the changes, enable auditing to track any future changes made to the ACLs.

Monitor Unauthorized Access Attempts

Being proactive with your monitoring can help eliminate problems before they start. Enable auditing on the folders used to store drop files, scripts and extensions. Specifically enable auditing on the MaData and Extensions folders and any folders used to store drop files. You might also want to include folders used to store source code for scripts and extensions. Watch for unauthorized users attempting to access these folders or change permissions on these folders.

Monitoring Options

When it comes to monitoring MIIS there are three aspects to consider, monitoring the MIIS server, monitoring at the object level and monitoring the connected data sources.

Monitoring the MIIS Server

Monitor the MIIS server to ensure that it is functioning as expected and that attempts are not being made to reconfigure security-related settings on the server itself. Watch for unauthorized attempts to gain access to the server. Microsoft Operations Manager (MOM) can be used for this purpose. The Microsoft Identity Integration Server 2003 Management Pack for MOM 2000 SP1 is available for Microsoft Operations Manager (MOM). This management pack monitors identity integration scenarios for MIIS 2003. Some examples are:

  • Management agent errors requiring administrative intervention.

  • Events indicating service outages.

  • Alerts indicating configuration issues and connected data source changes.

  • Verification that all dependant services are running.

  • Identity integration is performing normally and predictably.

  • Automation of identity integration does not result in data corruption or loss.

  • Notification if the password management is denying access to requests.

  • Notification when account provisioning does not occur correctly.

You can obtain the management pack from the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=58141). For more information about this management pack, see the Microsoft Identity Integration Server 2003 Management Pack Guide at the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=58142).

MIIS 2003 also writes events into the server's event log. Use Event Viewer to examine events being logged by MIIS 2003.

Monitoring Object Operations

The Operations screen in Identity Manager provides a summary listing of recent operations that have been performed on the MIIS server. Each entry also maintains the associated synchronization statistics so any changes made during that run operation can be examined. While this makes it possible to review individual changes that have been made to objects and is really intended to be used as a spot check to ensure that operations are functioning as expected, it is not really intended to provide a robust auditing solution to track the history of objects stored in the metaverse. Furthermore the run history can be, and most likely will be, periodically cleared. There is an option to save the information prior to being cleared but it is only an option. This means that it is possible to clear the operations summary information without saving a copy which results in the information being lost.

Currently there is no built in solution to track the complete life cycle of every object from creation through deletion in MIIS 2003. However, support for this type of functionality can be added by writing code to perform the desired type of auditing inside the rules extensions. One solution we see occasionally is to create a customized logging database on the SQL server being used to host the MIIS database and then writing extension code that logs every change to every object. This way the database contains the complete lifecycle of each object. Queries to the database make it possible to see what changes were made, when they were made and who made them. Using the flexibility of customized coding in the rules extensions means that you can create a completely customized monitoring solution that meets the specific needs of your environment.

Monitor the Connected Data Sources

One other option is to monitor the connected data sources and make sure that the changes coming from the MIIS server are within specification and nothing unusual seems to be happening. Also monitor any data stores used to send data to the MIIS server to be certain that nobody is attempting to access the data before it is sent. If the data source is a Microsoft platform check to see if there is a Microsoft Operations Manager management pack available. If the platform is based on another manufacturer, then see if there is a monitoring solution available to support that manufacturer.