×

IDMWORKS Blog

MicroFocus/NetIQ Identity Manager 4.7 Upgrade Considerations


In performing upgrades to MicroFocus/NetIQ Identity Manager 4.7, there are a few key items that one should be aware of prior to starting the process.

Key Considerations:

• The install uses a new script based install for Linux. This is great as we have more flexibility with the silent install and one can review the scripts to see how the install is performed. Windows scripted install may be coming in the future.

• The install of Identity Application defaults to a SSL install by default using port 8543 for the Identity Application. To use 8180/http you must modify the server.xml file.

• The Identity Application install lays down binary for SSO, SSPR, postgres and common files, such as the jre.

• The path for the jre and a few of the other components are a little different.

• The configupdate.sh script is no longer in the User Application directory, but in its own directory.

• The scripted install does not allow for custom paths. If your current configuration uses a custom path, the install on the new servers will utilize the default paths.

• Postgres upgrade won’t go smoothly if on a RHEL 6.10 box. However, with a little messaging it will run just fine. This was an isolated database running a NetIQ postgres from the 4.5 install. NetIQ tested on SLES 12 and RHEL 7.

• RedHat 7.5 is supported even though the install will state it is not. Just make sure to go to 4.7.1 patch as soon as possible.

• The ISO 4.7 install may change periodically. Do not use old ISO downloads. Always check your md5sum of your ISO against the md5sum of the one currently ready for install. As it is a scripted based install, it’s likely improvements will be made and the ISO updated periodically.

• There is Reported bug with the Identity Application Server and driver sets. If you choose to add the User Application and Role and Resource Driver as part of the install, but you already have a driver set configured, it will remove servers from the driver set. I recommend using this setting only if this is a new driver set and you don’t have more than one server associated to the driver set. As of today, there is no ETA on a fix for this.

• If you are using or will be using Identity Governance, know that currently the Identity Governance OSP and Reporting servers may share the 4.7 install servers, but not prior versions. Depending on the size of your environment, it may be wise to consider a separate reporting and sso server for IDM and IGA. We’re unsure whether future versions will have compatibility with different versions of IGA or Identity Manager — there are rumors that the services will become increasingly integrated.

• The CX MicroFocus github provides OSP and eDirectory integration with custom code you may need specific to your environment.

• HTTPS integration with Identity Application, the default implementation, may cause issues with current configurations where a driver is calling the actions of adding a role or resource. Make sure to export your tomcat.ks certificates and import them into the cacerts jre path local to the Identity Vault servers. Then you can use https for the URL for these actions as port 8180 wouldn’t be used.

• IDMProv is no longer used with IDM 4.7.1. A web browser won’t hit it, however the client applications such as a driver adding a resource or role would still point to /IDMProv as it has done in the past.

• The UI in 4.7 is a huge improvement. Make sure end users/help desk are familiar with the new look and feel.

• When patching the Identity Application, if you had removed the SSPR and sspr.war file in the webaccess container, note that the patch will put it back into place.

• If not using SSPR on the Identity Application server, to remove the redirect to the SSPR osp login url, modify the ism-configuration file in the tomcat/conf directory. Search for redirect. I appreciate the integrated components, however some want their sspr server in the DMZ.

• Custom JSP files may be affected with SSPR being upgraded. Custom JSP files are not supported by NetIQ and the libraries have changed with the upgrade that may affect current customization. Test first.

Conclusion:
There are significant enough changes in the product to make the upgrade worth the effort. I highly recommend testing with an environment that is as closely configured to production as possible. The scripted install speeds up the installation, especially if using the silent install. The patch is a breeze compared to past patching of the Identity Application.

The longest amount of time spent in the upgrade was in testing the drivers and copying over the server configuration to the new servers. With 20ish  drivers, we spent a good 8 hours of prep work, for the drivers alone. Do as much prep work as you can ahead of time. Be cautious that driver package updates don’t overwrite current custom code. Estimate a minimum of 80 hours for the upgrade: 40 hours testing an existing development environment that is already configured closely to production, 20-30 hours prep work, and another 10 for the actual upgrade. This estimate is based on a fairly vanilla environment where there isn’t a lot of custom code; you may need a longer black out period than 10 hours if you run into issues and need assistance from NetIQ.

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *