What Should a FIM Lab Environment Look Like?

This question always brings about a lively discussion during FIM design sessions, as this topic has many different vantage points.

A FIM project is significantly different from most IT projects in that it is a “typical infrastructure” and a “typical development” project merged together that also happens to integrate with a bunch of other systems. This statement taken at face value may not seem to indicate that a FIM lab would be radically different than a typical project’s lab, until you start to think of the underlying meaning of what is needed to achieve your development and testing goals.

While there is not a single approach to building a good lab environment, I have noticed that the more closely the development environment mirrors the production environment; the more successful the FIM development and implementation are. The adherence of the lab configuration to production configuration helps reduce risk and drive towards a successful implementation for the following reasons:

• Validates design assumptions
• Validates hardware and server configurations
• Increases the accuracy of the development effort
• Increases ability to perform accurate testing
• Allows for the identification and mitigation of issues that one will encounter with production data prior to rollout
• Can reduce the number of issues that one will encounter when porting code and product configurations between environments
• Easier to port configuration changes from development to production

I use the following series of questions to guide the discussion and identify what the lab’s high level objectives are:

• What is the risk profile (tolerance level) of the organization?
• What is the purpose of the lab?
  • One time development
  • Ongoing development after the initial deployment
  • Preproduction integration testing (e.g. hotfixes, service packs, configuration changes, load balancer configuration, etc…)
  • Preproduction performance testing

• Which systems need to be added to the lab?
  • Each system FIM needs to connect to should be part of the lab
  • Can we make a copy of production data to use in the lab? (Physical to Virtual (P2V) or VM export)

• What type of information will FIM manage in the design? (e.g. Object Types – AD users, AD groups, AD contacts, HR record, Sun user, etc…)

• What equipment is available to stand up the development environment?
  • What virtualization platform does the organization run?
  • Can all of the data sources be isolated to the lab? (e.g. Some systems can’t be added to lab such as: midrange or mainframe systems) Can a TMG server be setup to allow traffic from an isolated lab to a production system?

• What types of testing do you want to do?
  • Unit testing
  • Integration testing
  • System testing
  • Performance testing
  • Acceptance testing

• What components of the design do you want to develop and test prior to production?
  • There are a number of different tests that should be considered as part of the project. Below are some of the testing areas for consideration:

• What skills are needed to setup and maintain the environment?
  • Internal administration skills
  • Are there new technologies that are being introduced such as clustering or SCSM?

Best Practices around a FIM lab:

Once it is understood what objectives the lab is meant to fulfill, it is important to review and apply the following best practices to the lab design:

1. Gather all of the requirements before building the lab

• Changing lab requirements after the lab is built may require a complete rebuild of the lab

2. Lab systems should be separated from the production systems

• Mistakes in development can lead to production issues
• Ability to test changes to the configuration prior to production deployment is limited

3. If there is not enough hardware to build a proper lab, consider the use of virtualization technologies such as Hyper-V

• Less hardware required
• Easier to create point in time configuration backups and revert to previous configurations

4. The lab environment should have a representation of each system that FIM will connect to

• A representation of each system that FIM will be managing
  • Systems should be of the same platform
    • Identify the version level of OS (hotfixes, service packs) and installed products
    • Systems should be of the same version and patch levels
    • Schema for each system should mirror the production system (e.g. SQL DB schema, AD schema, etc…)
    • Maintain the configuration of existing systems (e.g. Windows Trust configurations, DNS configuration, AD Site configuration, etc…)

• In a multi-domain forest, Active Directory should have the same number/placement of directory partition(s) as production

• All systems that FIM may provision objects for should exist in the lab. Some examples of additional systems that FIM can manage are:
  • Exchange
  • LYNC
  • Home Directory servers

5. In addition to the systems FIM will be managing, additional infrastructure services are also needed to support a functional network. The following services should also be considered for placement into the lab:

• DNS
• Backup system
• Certificate Authority
• E-mail system for workflow notification activities
• Code Repository (e.g. Team Foundation Server)
• DHCP
• Software Deployment (SCCM)
• Firewalls (TMG/UAG) – for application publishing

6. Depending on the designed solution and testing requirements, the following systems should also be considered for completeness:

• Hardware load balancer
• UAG/TMG/Firewalls
• Client Devices (IPADs/IPhones/Smart Phones)
• Ability to connect to external email server for OTP
• Ability to connect to SMS Gateway for OTP
• Two factor authentication (RSA/Smart cards)

7. All client operating systems that need to be tested prior to FIM client deployment

• Supported OS
  • OS
  • Version(x86 or x64)
  • Service pack levels
  • Microsoft Office versions and patch levels
• Various builds of the supported OS(s)

8. Data representation – When building an IDM lab, I like to export the production data and import that data into my lab environment so that I can see all of the changes that will occur to the existing data.

• Data should be current and relevant
• Data should exist from a point in time snapshot across all systems to enable data alignment (e.g. the HR system to have records that can be matched to an AD account)
• Data should contain a representation of all data that will be imported/exported in each system
  • Different classes of objects should be present (e.g. users, groups, contacts)
  • Objects should be placed in the same location as production (e.g. relative to the environment’s directory partition)
    • The OU production location of objects: ou=Company Users, dc=prod, dc=company, dc=com would translate to ou=Company Users, dc=dev, dc=company, dc=com in development
    • Attributes should be populated with production values (givenName, SN, DisplayName, etc…). This allows testing to see how the attributes will be modified
• User accounts should be mailbox enabled to facilitate workflow processes

9. Data quality – After the initial lab is built and populated with data, there are a number of decisions made in the design which will require you to examine the current data to determine if the current data is sufficient to meet the design decisions.

• What will be the linker attribute between the various systems? A linker attribute should be available in each system to facilitate the process of joining the objects in the various systems (HR record, AD account) to a FIM identity (MV object).
• If the data isn’t available in one system, is there another system or systems that can contribute the attribute data that I need?
• Is the data consistently formatted? Poorly formatted data can be a challenge to decision logic
• What attribute data is needed for to determine entitlements?
  • Who is allowed to have an account?
  • Who is allowed to have a mailbox?
• What attribute data is needed for provisioning rules?
  • How is the DN determined?
  • How is the Account Name calculated?
  • Who gets a mailbox?
  • Which database are they assigned to?
  • Will they be provisioned for LYNC?
• What attribute data is needed for attribute transformations?
  • For a display name transformations, does the attribute data exist to build a valid display name?
• What attribute data is needed for application personalization?
  • Where does it need to exist?
  • What format does the data need to exist in?
• What attribute data is needed for creation of criteria based groups?
• What attribute data is needed to make delegated authorizations?
  • MPRs that delegate rights using a relationship to object. (e.g. A manager that is allowed to update the user accounts of his reports in the FIM Portal, requires that the manager attribute be populated on each of his reports)
  • MPRs that delegate administrative rights will require that the objects have an attribute(s) populated that will allow FIM identify them into sets. For example, all users in a particular business unit and location would need to have the attributes populated with the user’s business unit and location.
  • Workflow activities such as Owner Approval workflows, must have the displayed owner attribute populated with the group’s owner

10. Data confidentiality

• Is there sensitive data in any of the systems that will need to be protected or masked?
  • Payroll
  • SSN
  • Birthdate

11. Testing

• As in all development projects, it is helpful to separate the role of the developer from the tester. Testers often find ways of breaking the code that was not envisioned by the developer.
• Building a great lab, while important, is only the first part of the project. A thorough test plan is needed to validate the implemented design is doing what you want.