Planning Your System Configuration for MIIS 2003

Applies To: Windows Server 2003 with SP1

Overview of Planning Your Configuration

The MIIS configuration plan consists of the following:

• The security plan for your deployment.

• A plan to access your connected data sources.

• A strategy for scheduling synchronization.

• A plan for error handling, log handling, and administrative notification.

• A backup plan.

The deployment team uses your configuration plan together with the previous design and planning documents (“Designing a System Dataflow Model for MIIS 2003,” “Planning the Metaverse for MIIS 2003,” and “Planning Synchronization Rules for MIIS 2003) to implement your MIIS 2003 deployment.

Before you write the configuration plan, review the worksheets from the previous design and planning documents, which describe the details of the design plan, the metaverse schema extensions, and the rules for this deployment.

Figure 1 shows where writing the configuration plan occurs in the MIIS 2003 design and planning process, and outlines the steps that are required to write the configuration plan.

Prerequisites

To complete the process described in this topic, you need:

• Completed worksheets from your project proposal.

• Completed worksheets from your system dataflow design specification.

• Completed Metaverse Attribute Design worksheet.

• Completed worksheets from your synchronization rules specification.

MIIS 2003 Configuration Concepts

Before configuration planning begins, review the following resources in order to better understand MIIS 2003 synchronization and some of the decisions you must make:

• Essential Concepts of Microsoft Identity Integration Server 2003 in the Technical Reference section of the Microsoft Identity Integration Server 2003 Technical Library at https://go.microsoft.com/fwlink/?LinkId=26499.

• MIIS 2003 Help. If you have not yet installed MIIS 2003, you can run MIIS 2003 Help from the Microsoft Identity Integration Server 2003 installation CD.

• Microsoft® Windows Server™ 2003, Enterprise Edition, Help and Support Center, including general security information.

• Microsoft Identity Integration Server 2003 Developer Reference. If you have not yet installed Microsoft Identity Integration Server 2003, you can run the MIIS 2003 Developer Reference from the MIIS 2003 installation CD.

Planning the Configuration of MIIS 2003

Compiling the configuration plan consists of recording the decisions that you make about MIIS 2003 configuration issues, including:

• Specific management agent and metaverse settings that result from your dataflow model.

• Environmental and system security for the MIIS 2003 deployment.

• Error handling.

• System backup plan.

As you plan your configuration, record your decisions in the sample worksheets that accompany this document. For more information, see “Design and Planning Sample Worksheets for MIIS 2003,” which are part of this collection. Together, these worksheets form the MIIS 2003 configuration plan.

Recording Configuration Options for Your Dataflow Model

The dataflow model, including mappings and rules, was determined and recorded in the system dataflow design document. Included in this document are the following specifications that form the basis for configuring your management agents:

• The solution proposal worksheets, which define the connected data sources, object-level policies, and included attributes.

• The system dataflow worksheets, which define metaverse objects and attribute flow.

• The metaverse attribute design worksheet, which defines all attributes in the metaverse.

• Synchronization rules worksheets, which define how your deployment will handle object creation, link management, and object deletion.

Management Agent Configuration Settings

Management agents (MAs) control the dataflow between a connected data source and the metadirectory. Some configuration settings are available to all management agent types; other configuration settings are only used with specific MAs.

Tables 1 and 2 describe both the common and specific configuration settings that you need for planning your configuration. If you are working through the Design and Planning collection in order, completing the worksheets as you go, you will already have planned your management agent rules when you read “Planning Synchronization Rules for MIIS 2003.” As you read this document, use the Management Agent Configurations worksheet in MIIS_Worksheet.doc to record configuration information about each management agent.

For more information about management agent configuration settings, see “Understanding Management Agent Rules” in MIIS 2003 Help.

Table 1: Agent Configuration Options Applicable to All MAs

Table 2: Agent Configuration Options Applicable to Specific MAs

Metaverse Rules Configuration Settings

The metaverse is a set of tables that contains the combined identity information for a person or resource. The metaverse is hosted by Microsoft® SQL Server 2000 in a database named MicrosoftIdentityIntegrationServer. Use the information contained in “Planning the Metaverse for MIIS 2003” to plan the naming conventions, object types, and attributes that will be used in the metaverse.

Two types of user-defined rules can be configured to process metaverse objects:

• Object deletion rules determine whether to delete a metaverse object when a linked connector space object is disconnected from the metaverse object.

• Provisioning rules determine the process of creating, renaming, connecting, and disconnecting objects in one or more connector spaces, based on changes to an object or objects in the metaverse.

Use the Metaverse Rules Configuration worksheet in MIIS_Worksheet.doc to record configuration information for each object and for your provisioning scheme. For more information about metaverse rules configuration, see “Understanding Metaverse Rules” in MIIS 2003 Help.

Planning Your Security Configuration

To provide an environment that is both secure and accessible, an identity management system must be configured to prevent access by malicious users and attackers. It is the responsibility of the configuration planner to evaluate the organization’s current security policies and determine what degree of compliance is necessary to deploy MIIS 2003.

Consider these questions as you evaluate and plan your security configuration:

• Access Control — Who has access to the MIIS 2003 rules extensions code and management agent data files?

• Authentication —Who is allowed to use MIIS 2003 to run administrative tasks, including password management Web applications?

• Database Security — Who has access to the SQL Server MIIS 2003 database?

• Necessary Security Exposures — Will your project require unique system configurations, such as unattended synchronizations, for which you must assign special administrator rights to minimize the security risk? For example, unattended synchronizations can involve scripts that contain authentication information necessary for the management agent to connect to the target data source.

Controlling Access to the MIIS 2003 Installation Files

As a general rule, assign users only the minimum permissions that they require to use directories, files, and database objects, and the information they can access through the MIIS 2003 adminstrative 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 use that data only.

During installation, MIIS 2003 creates five security groups (optionally, you can specify existing security groups that you are currently using in your connected data sources). MIIS 2003 also sets access rights to files and determines which MIIS 2003 tasks that users can perform. Except when you use existing security groups, MIIS 2003 creates the following groups:

• MIISAdmins

• MIISOperators

• MIISJoiners

• MIISBrowse

• MIISPasswordSet

You can control access to MIIS 2003 functions through membership in these security groups. When you need to grant or revoke a user’s access to MIIS 2003, these groups provide a simple, single point of administration.

Each of the MIIS 2003 security groups has predefined roles and specific permissions that determine which administrative tasks the members of that group can perform. You can control and secure authentication by assigning users to these groups. For more information, see “Using Security Groups” in MIIS 2003 Help.

Setup creates these groups as local computer groups rather than domain groups. Some scenarios — for example, configuring a warm standby server — require domain groups. For more information, see “Using security groups” in Microsoft Identity Integration Server 2003 Help.

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

If the information that is synchronized with MIIS 2003 is sensitive, then personnel must be chosen with care. Administrators, developers, and other personnel with access to MIIS 2003 files potentially have the ability to modify this data.

Table 3 lists the rights to the default MIIS 2003 folders that are granted to each group. Use the Roles and Responsibilities Rights Assignments worksheet in MIIS_Worksheet.doc to record rights assignments for users and groups.

Table 3: Rights to Default MIIS 2003 Folders

Controlling Authentication Security

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.

By default, MIIS 2003 transmits initial passwords as plaintext over the network. You need to verify the level of encryption between MIIS 2003 and the target data source. To set initial passwords, it is strongly recommended that you set up Secure Sockets Layer (SSL) and use Lightweight Directory Access Protocol (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).

Limiting Data Access

Make certain that no one can directly access the MicrosoftIdentityIntegrationServer database, which is hosted by SQL Server. Direct access can cause corruption of the database, failure of the server running MIIS 2003, and loss of data. When sensitive information is being synchronized, be sure to apply your company’s security standards to the SQL Server database.

If you decide to locate your MicrosoftIdentityIntegrationServer databaseon a server other than the one that contains the installation and data files, be sure that the policy for the SQL Server service account allows users access to that computer from the network. Although it is typically recommended that you locate the database on a different server, moving the database to a different server does require additional security considerations in order to reduce security exposure. The most secure method is to locate your SQL Server on the same server as MIIS 2003.

Securing Your Data Sources

The data sources that are connected to the MIIS 2003 metaverse require additional security as well. You probably already have security on these databases; however, additional security options must be reviewed because information about any connected database is theoretically open to read/write from the other connected data sources, depending on your exact configuration and who has authentication rights on each part of the system. It is the responsibility of your internal security planning team to carefully map this exposure and minimize the potential risks, in order to protect the data on each connected data source. Be sure to document your security plan and protect the information about security exposure.

If you are automating the synchronization of data between MIIS 2003 and your connected data sources, you may have necessary security exposures, such as an embedded user or password authentication within a script. Be sure to catalogue and analyze your security exposures so that risk is reduced.

Use the Security Configuration worksheet in MIIS_Worksheet.doc to record any data source or database security issues.

Controlling Server Access

Several servers can be involved in an MIIS 2003 deployment — for example, a primary server, a warm standby server, and a database server.

Primary Server

Create an account called MIIS Service account that you use to run MIIS 2003. The service account can be a local or domain account and does not need to be a local administrator account. If the server running SQL Server is a different computer from the server running MIIS 2003, you need to make the service account a domain account.

During MIIS 2003 setup, you must enter the name of the service account, the password, and the local computer or domain name. The credentials you provide in this step will have full control over the file structure that MIIS 2003 Setup creates, the registry keys that control how the MIIS 2003 service runs, and the component interface that runs server functions.

After you create the service account, you will need to set access policies for the service account. For more information, see “Change the Microsoft Identity Integration Server 2003 service account” in MIIS 2003 Help.

Warm Standby Server

You can configure a warm standby server anytime after you configure your primary server. If a primary server fails, the warm standby server can be activated to become the primary server. When the primary server is brought back online it then becomes the warm standby server. If necessary, you can restore the server to primary server status. A warm standby server is activated to primary server status by using MIISactivate.exe. For more information about this tool, see “MIISactivate: Server activation tool” in MIIS 2003 Help.

Set up the warm standby server with the same configuration options that you used for the primary server. Setup detects that you are trying to use a database that is already operational and requires the encryption key set. After you complete setup, you can activate your warm standby server whenever a primary server fails.

Configuring a warm standby server requires that you include the following tasks in your regular procedures:

• When changes are made to the MIIS 2003 installation path\MAdata folder on the primary server, you should make sure that changes are also reflected in the same folder on the standby server. In this way, the current audit files, drop files, or input files that are part of your regular MIIS 2003 processing are available in case of primary server failure.

• Always create a backup of your encryption key set when you create new keys or re-encrypt your data. If you do not back up your encryption key, you will be missing encryption keys when management agents run and credentials cannot be decrypted, or if MIIS 2003 is processing data that has been encrypted with a key that is not part of the current configuration. The only way to recover from this situation is to abandon the encryption keys.

Database Server

Both the primary and the warm standby servers must be able to access the MicrosoftIdentityIntegrationServer database. If you install SQL Server on a remote computer, that is, on a different computer than the one running MIIS 2003, be sure that the policy for the SQL Server service account allows users access to that computer from the network. If access is not allowed, MIIS 2003 Setup will fail.

Either the default instance SQL Server or a named instance can be used for the database. As long as the two computers running MIIS 2003 are configured to use the same TCP port, you can select the TCP port by using the SQL Server client network utility.

During setup, the default choice for authentication is the Local System service account. However, if required, you can use domain or computer credentials instead. If the database server will manage data for more than one application and an application requires SQL-mode authentication, you should use mixed-mode authentication. If the computer running SQL Server supports only MIIS 2003, you should select Integrated Windows authentication.

If you need to change the transport, protocol, or port that SQL Server will use for connections from other computers, use the Server Networking Utility tool that is installed with SQL Server. To use MIIS 2003, you do not need to change any of the configuration settings. If you decide to change these network settings later, provided that you do not change the instance name, MIIS 2003 will continue to operate as before. See the SQL Server documentation for more details on these configuration options.

To optimize performance, it is recommended that you configure SQL Server to store your data and log files on separate physical drives. For more information about optimizing performance, see “Move the database transaction log to another drive” in MIIS 2003 Help.

Use the Security Configuration worksheet in MIIS_Worksheet.doc to record your server configurations, including any data source or database security issues.

Assessing Hardware Requirements

Installation of MIIS 2003 requires at least the following hardware:

• Server with a Pentium III 500 MHz or faster processor; a Pentium 4 is recommended. A dual processor machine is recommended if you will run management agents concurrently.

• 512 megabytes (MB) of RAM; 1 gigabyte (GB) or more is recommended.

• 20 MB of hard disk space for typical installation of MIIS 2003 and rules extensions.

• Super VGA or higher resolution monitor.

• CD-ROM or DVD-ROM drive.

• Microsoft Mouse or compatible pointing device.

Configuring and Troubleshooting Synchronization

When you deploy MIIS 2003, you must be able to view and access the data on the connected data sources to configure and troubleshoot synchronization. To configure and troubleshoot data handling:

• Document access to connected data sources.

• Plan for evaluating the data for reliability.

• Prepare for handling problems with invalid data.

• Schedule data synchronization.

• Configure error handling.

Documenting Access to Connected Data Sources

It is important to document how the deployment engineer can access the connected data sources during the deployment. Either the deployment engineer should have minimum access rights to get data from the data sources, or someone who is an administrator should be available at all times during the deployment to examine the data sources.

Evaluating Data Reliability

After you extract the data from the synchronization, plan how to evaluate the data for reliability:

• Analyze the synchronization rules that you are planning.

• Decide whether to set up a script or use the Preview function in MIIS 2003 to determine if the extracted data fails any rule.

• If any rules fail, identify which ones and why.

It is important to determine at this stage whether it was the data or the configuration that caused the synchronization to fail.

Troubleshooting Invalid Data

When you are troubleshooting synchronization, the first emphasis is on the software or the configuration; however, sometimes the problem may be that the data in one or more connected data sources is not in the expected state. Part of troubleshooting synchronization issues includes checking the data at both ends of the synchronization to ensure data integrity.

Use the Data Handling worksheet in MIIS_Worksheet.doc to record your data handling scenarios.

Scheduling Data Synchronization

Consider these scheduling suggestions when you plan your synchronization schedules:

• Assess network bandwidth. Schedule lengthy synchronizations during periods of low network activity to avoid monopolizing bandwidth.

• Coordinate with system backup. Coordinate scheduled synchronizations with the system backup schedule so that you efficiently back up the most recent data.

• Monitor the frequency of data modifications. Base your synchronization schedules on how often your data is updated. Some data sources will require more frequent updates than others.

• Clean up periodically. As a best practice, schedule a full import at regular intervals. One of the tasks of a full import is to check the connector space and remove any object it finds that does not exist in the data source itself. Such objects typically represent corrupt data, links that went down, and other failed cases. If disconnected objects exist, running a full import cleans up the connector space by removing them. It is not possible to remove objects individually; so doing a full import periodically contributes to the health of the system. How frequently you perform a full import for each data source depends on how reliable the delta mechanism is for that data source.

• Synchronize in stages. You can retrieve data from a connected data source and process it after you validate the data. Synchronize objects from one connector space to another connector space and then export the objects after you validate them. Available identity information can be processed at any time and without having to retrieve the latest updates from the connected data source. You can independently push out pending exports to the connected data sources at any time.

• Plan how you will initiate synchronizations. You can run management agents manually from Identity Manager or start them from a Windows® or Visual Basic script. You can also use MASequencer, which is a tool that is available in the MIIS 2003 Resource Tool Kit, to automate the order in which management agents are run. MASequencer can also perform stop, resume, or pause operations interactively on management agents.

For more information about MASequencer, see the MIIS Resource Tool Kit, which is available from the Microsoft Download Center at https://go.microsoft.com/fwlink/?LinkId=22788.

• Plan timing of synchronizations. Plan for initial synchronizations and full imports because they may take a long time.

• Test before deploying. Fully test synchronization schedules, scripts, and tools in your test lab before deployment.

Configuring Error Handling

During normal processing, MIIS 2003 produces a large number of informational event messages that report system errors, synchronization errors, and exceptions. You can configure event messages to provide the following types of notifications:

• Exceptions. Use the Microsoft Visual Studio® development system to send user-defined event messages based on exceptions that you catch in code. See “Creating Clear Error Messages from Exceptions” in the MIIS 2003 Developer Reference.

• Log entries. Use data from log entries to obtain typical status updates. You can configure the log level so that only critical errors are recorded. Some situations, such as failure to create an object, are not always critical errors and can be suppressed to informational logs by using a logging .dll that sends some of the log entries to a separate file.

• Logging .dll. Use Visual Studio to create log entries in a file. For information about using the logging .dll, see “Setting Log Level” in the MIIS 2003 Developer Reference.

• E-mails. Use a script or the Visual Studio development system to send an e-mail to administrators and others. Use this tool sparingly. It may be appropriate to send an e-mail if a server is in trouble; however, sending e-mail in less serious situations may flood the administrator’s mailbox and more important e-mail may be overlooked. Ensure that errors of greater severity are distinct and directed to the right people.

• Microsoft Operations Manager 2000 (MOM). Use the MIIS 2003 Management Pack for MOM to monitor MIIS 2003 components and obtain information necessary to ensure that all necessary services that support MIIS 2003 are running. MOM collects and analyzes MIIS 2003 events from the event log and can alert you to management agent errors, service outages, and configuration changes.

• If failed objects are to be handled over a longer period of time by someone other than the usual administrator, you may want to send the information to the log file so it can be analyzed at an appropriate time.

Creating Clear Error Messages from Exceptions

When errors occur during synchronization, exceptionsare often thrown. Exceptions are error messages in the format prescribed by Visual Studio. Sometimes informational errors cause exceptions that are similar in format to much more serious errors.

Use Visual Studio to create clearer, user-defined error messages from the exceptions that MIIS 2003 throws. Do this by catching the exceptions. The following code example shows how you catch the exception and handle it. In the code example, the comments need to be replaced by code that will do the appropriate task and display or log an appropriate message.

Try
'Try to execute this instruction but if an exception is thrown, go to the  
      Catch clause for that extension'
        ' Determine the container and relative distinguished name
…

    Catch ex As ObjectAlreadyExistsException
        ' If the ObjectAlreadyExistsException is thrown, ignore if the object
        ' already exists, join rules will join the existing object later'

    Catch ex As NoSuchAttributeException
        ' If the NoSuchAttributeException is thrown, ignore if the attribute on
        ' the mventry object is not available at this time

    Catch ex As Exception
        ' If the ex exception is thrown, log the exception, with timestamp, at
        ' level 1,
        ' Microsoft.MetadirectoryServices.Logging.Logging.Log("Caught exception
        ' " & ex.Message, True, 1)

    ' If any other exception is thrown, re-throw to rollback the object
    ' synchronization transaction and 
    ' report the error to the run history
        Throw

    End Try

The MIIS 2003 Developer Reference provides information about exceptions that are thrown by the Microsoft Metadirectory Services namespace and by the Windows Management Instrumentation (WMI) provider objects. It also provides examples of catching exceptions and handling them.

Setting Log Levels

Without configuration of error handling, the exception for a system failure, for example, may look very similar to a failure to create an object, which may not even be an error but strictly serve as information. MIIS 2003 contains a logging .dll that can be used to create appropriate logs for many situations and to set a log level on each message so that only the most important log entries appear.

If too many log entries exist, important information may go unnoticed in the clutter of surrounding non-critical entries. Develop a strategy on how to deal with log entries so that system-critical messages are higher priority than less critical log entries.

You may want to set up a hierarchy of error notifications. For example, for events that threaten system stability, set an event log to the highest level. Set less critical informational messages to a lower level.

Using WMI with MIIS 2003

Microsoft Identity Integration Server 2003 includes a WMI provider that you can use to perform administrative tasks like running management agents, producing customized reports on management agent runs, and getting statistical information about the metaverse. You can also use the WMI provider to extract information about the health of the system and whether your synchronizations are working as expected.

For example, to ensure that you are importing the correct objects into the metaverse, use the classes in the WMI provider to check the results of a management agent that is run before importing objects into the metaverse. You can check that you are changing metaverse objects according to your business rules. Examples can be found in the MIIS 2003 Developer Reference. One such example, “Example: Preventing Metaverse Damage,” shows a way of checking your results by using a VBScript script.

WMI provides the following classes for MIIS 2003:

• MMSCSObject. Represents objects in the connector space. Use to check data in the connector space or to set passwords.

• MMSManagementAgent. Represents a management agent. Use to automate a management agent run, including stopping and starting a management agent based on conditions.

• MMSRunHistory. Represents the results of a management agent run. Use to get statistical information about management agent runs.

• MMSServer. Represents the metadirectory server. Use to obtain information about the number of objects in the metaverse or to clear run histories from the server.

For more information about using WMI to configure MIIS 2003, see the MIIS 2003 Developer Reference.

Planning for MIIS 2003 Backups

Regular backup procedures are essential for protecting your data from accidental loss. Critical data for MIIS 2003 is stored on the server running Windows Server 2003, Enterprise Edition, that hosts MIIS 2003 and on the server running SQL Server 2000 that hosts the MicrosoftIdentityIntegrationServer database.

A backup process should include the following:

• The MIIS 2003 encryption key.

• The MicrosoftIdentityIntegrationServer database.

• All log files or file-based management agent import and export files that are located in MIIS 2003 installation path\MAData.

• The local Security Accounts Manager (SAM) database if the server is a stand-alone server.

Determine how often to perform backups and set up a comprehensive schedule. If you already have scheduled system backups of the systems that are associated with your MIIS 2003 deployment, you can add MIIS 2003 to the system backup schedule. For more information about backing up MIIS 2003, see “Backing up Microsoft Identity Integration Server 2003” in Microsoft Identity Integration Server 2003 Help.

Obtaining Approval for Your Configuration Plan

Ensure that your design and deployment teams become familiar with the contents of the configuration plan. All members of the project team should provide feedback for the plan, consider its provisions, and agree with the strategies and schedules. After the configuration plan is complete, obtain sign off from representatives of the design and deployment teams.

Summary

Your compiled configuration plan should include the following:

• Security initiatives that assist in developing a clear and concise security strategy for your MIIS 2003 system.

• How to access your connected data sources and how to ensure that they are synchronized without damaging any data.

• Synchronization schedule analysis and a comprehensive schedule for synchronizations.

• How system event messages are logged and sent to system administrators as synchronizations are processed. You should have a documented strategy for reviewing and archiving logs, as well as notification alerts

After the configuration plan is approved, the basic design and planning for your MIIS 2003 installation on a local level is complete.