NetIQ has a new product called Identity Governance. This is a pretty neat tool that adds some important functionality.

If you are familiar with Micro Focus/NetIQ/Novell Identity Manager then you will be familiar with many of the features in Identity Governance. The focus of Identity Manager is to provision and manage users in multiple systems. Initially this was all automated, via HR data or the like. This expanded greatly with Roles and Resources so that users can both request, but also allow approvals/denials in the flow of those requests.

The main goal of Identity Governance is to 'govern' that system. That is, just because someone has certain access does not mean they really should. Perhaps they have permissions they got in a previous job role that was never removed. Perhaps there are some historical anomalies that led to this odd set of rights a user has acquired.

The initial versions of this product were called Access Review for just this reason. But there is much more to the product. Once you have collected all the data (users, accounts, permissions, access) from all the relevant systems, you can start to review it. At this point, how do you fix things that need to change? Well there is a whole fulfillment model. Perhaps it is manual and sends an email that stays unresolved until a link is clicked to confirm it is done. Perhaps you write straight to a data source to make the change. Perhaps you kick of an IDM Workflow. Lots of options.

Put all that together, review, fixing things, and then checking again for completion (Just because they said they fixed it does not mean they really did) and you have a cycle you call a Certification Campaign.

Then there are a bunch of fun frills like Business Roles and Role Mining, where you can determine that 90% of your users have the same basic set of permissions. This might consist of 10 different permissions. Reviewing all 10 every campaign can be painful and time consuming, whereas coalescing that set into a Business Role and approving or revoking just the Role can be much simpler. (One versus ten should be obvious why that is.)

Some of these Roles will be obvious and easy to define, but others will be harder to discover, so the product can Mine for them. That is, look for commonly occurring patterns of permission sets and allow you to examine, tweak, and then create appropriate Roles from them.

All that being said, here we have another product to manage and learn how it works at a level, that allows us to understand it and troubleshoot it.

Like the IDM Identity Apps, this is also a Web based application. It consists of two (at least) components, an IG-Server and IG-Client. The Web interface itself is the IG-Client and it makes REST calls to the IG-Server. There are some data and database level modules that I have yet to fully delve into and understand yet, more to come on that as I break things.

It all runs in Tomcat, as WAR files, just like the Identity Apps, and the front end authentication uses the newest builds of OSP. I think I will do a standalone article on interesting things about the new OSP in Identity Governance, since there really are some nice new features that I look forward showing up for IDM itself.

But in short, you get the same OSP features from the IDM Identity Apps world, where you can do Name/Password, Kerberos, or SAML federated logins. There is a new twist where one hidden authentication source is added, file based, that allows you to store a bootstrap administrator to login, even when the main source is broken. Which is really nice. It was clear this was part of OSP all along if you read my series on reading the OSP logs, but it was never supported before.

As usual for OSP, there is the standard configupdate.sh in the /opt/netiq/idm/apps/osp/bin directory, but it is only used for the pure OSP components of configuration. This gets a bit confusing since there is a new tool, configutil.sh that is used for more IDG specific configuration. To run the configutil, you need to provide the switch -password and the password for the DB user igops. If you changed the username during install, then you will need to edit the file to use the correct username.

This is because configupdate.sh is focused on managing the /opt/netiq/idm/apps/tomcat/conf/ism-configuration.properties but configutil.sh is focused on managing the configuration data stored in the database itself, in the table:
ISM_GLOBAL_CONFIG

Both can open an X windows session to load a GUI to configure it or do it command line based. Configupdate.sh in console mode uses a menuing system, whereas configutil.sh defines a bunch of commands that I need to track down and document one of these days, maybe a Wiki entry for that as well would help.

One neat new feature of the command line mode of configutil is that you can specify a script file and it will process the commands in the file. In fact during the install, the installer configures the global.properties file in the tomcat/conf directory, and then runs a script that loads all the key value pairs in that file into the database in the ISM_GLOBAL_CONFIG table.

There is a second script it runs that imports the ig-something file from the /opt/netiq/idm/apps/osp/conf directory into the database as well.

Lots of things in the configuration utilities but I think that is a topic for another day.

With any new product that you are working with, learning how to see its logs is critical. In this case, like the Identity Apps, logging is sent to the catalina.out style file. However there seems to be a central catalina.out file that gets one set of values that is not so useful (and does not have date stamps, making it even less useful) and a daily Catalina file like catalina.2018-08-01.log.

These are in the usual location on Linux of:
/opt/netiq/idm/apps/tomcat/logs

The configuration directory is:
/opt/netiq/idm/apps/tomcat/conf

The logging configuration is not in the GUI, like it was in User Application (login as a User App Administrator, Administration tab, and then Logging side tab), nor in the setenv.sh file in tomcat/bin as for OSP. Rather it is in the tomcat/conf directory in the file:
/opt/netiq/idm/apps/tomcat/conf/ig-server-logging.xml

Back that file up before working with it, since you probably want to be able to easily turn everything off once you get it working and copying back a default file is simplest.

Some example settings lines in the file that I initially enabled:

<logger additivity="true" level="DEBUG" name="com.novell.soa"/>
<logger additivity="true" level="INFO" name="com.netiq.iac.AuthPermissions"/>
<logger additivity="true" level="INFO" name="com.netiq.iac.server.admin"/>
<logger additivity="true" level="INFO" name="com.netiq.iac.server.rest"/>
<logger additivity="true" level="INFO" name="com.netiq.iac.server.security"/>
<logger additivity="true" level="INFO" name="com.netiq.iac.server.spi"/>
<logger additivity="true" level="DEBUG" name="com.netiq.persist"/>
<logger additivity="false" level="DEBUG" name="audit.com.netiq.iac.server.rest.CollectionService"/>
<logger additivity="false" level="DEBUG" name="audit.com.netiq.iac.server.rest.CollectorService"/>
<logger additivity="false" level="DEBUG" name="audit.com.netiq.iac.server.rest.IdentitySourceService"/>

I am thinking I should start a Wiki page to track what each log level is useful to log, like I have for the User application ( https://wiki.microfocus.com/index.php/User_App_Log_Levels ). I took a pause from writing here and went and created that Wiki page at:
https://wiki.microfocus.com/index.php/Access_Governance_Suite

If you are using Identity Governance and run into an issue and find that enabling a particular log level enabled you to figure it out, please edit the Wiki entry for that level, add in an explanation of your issue, what you saw in the trace, and how you fixed it. This way everyone gets a resource for troubleshooting that we can all share and contribute towards.

Like in the User Application case, there are parent classes, like com.netiq.iac that if you enable logging inherit down to the child classes and thus will fill your logs. Whereas there are more specific examples, like com.netiq.iac.server.rest which is more specific and perhaps more useful.

As always, there is sometimes (rarely) a valid use to turn on every logging option, reproduce the error and then look through the log for some hint. I remember doing this with eDirectory and ndstrace. Sometimes you just have to enable everything, and then spend the time searching through the logs to find some error. It is hard and slow, but sometimes your only choice.

The ism-configuration.properties is there in the same configuration and has much of the usual OSP configuration information you are probably used to seeing.

The database connection strings are stored in the /opt/netiq/idm/apps/tomcat/conf directories server.xml file, and look like this:

<Resource auth="Container" driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver" factory="com.netiq.tomcat.jdbc.pool.CustomBasicDataSourceFactory" initialSize="5" logAbandoned="true" maxIdle="5" maxTotal="20" maxWaitMillis="30000" minIdle="2" name="shared/jdbc/DcsDS" password="AHab4Btab4QahVU6nLiHDQ==:zab4SWMN1c/dab4/U6cB/Q==:4MCjCbYynqab4tVab41K w==" removeAbandonedOnBorrow="true" removeAbandonedOnMaintenance="true" removeAbandonedTimeout="900" testOnBorrow="true" type="javax.sql.DataSource" url="jdbc:sqlserver://mySQLServer.acme.com;instanceName=sql2016NPR;databaseName=igops" username="igops" validationQuery="select 1" validationQueryTimeout="10"/>

You will notice that the passwords are encrypted. Looking like this:

password="AHab4Btab4QahVU6nLiHDQ==:zab4SWMN1c/dab4/U6cB/Q==:4MCjCbYynqab4tVab41K w=="

If you need to change them, say your DBA changed the password in the database on you (Like that ever happens, right?) how do you get the new encrypted value?

Well the good news is there is a script (/opt/netiq/idm/apps/idgov/bin/encode-password.sh) that will generate the proper encrypted string. It also looks like configupdate.sh is using the same encryption method, so if you need to fix an issue in the file itself, without the GUI (like say you cannot get X Windows to run properly, like that ever happens, right?) it can be tricky. The regular string fields are easy. Just edit the file. But how to fix password changed issues? Use this script in the bin directory, pass it the new password value and it spits out the proper encrypted string.

This is great to know, and I am told was included in previous version of OSP/ID Apps but I never noticed it before, and thus if so, it is still great to know about this tool.

As I mentioned earlier, there is a bootstrap user in IDG that reads its data out of a config file. The path to the file is specified in configutil.sh and it is usually /opt/netiq/idm/apps/idgov/osp/adminusers.txt and contains a username and encrypted password.

So any bets on if it uses the same encryption method that Tomcat's server.xml and configupdate's ism-configuration.properties uses? Yes, you guessed it, different method.

In this case, there is a JAR in the osp/lib directory that allows you to generate the proper encrypted string using this format:
java -jar ig-pwtool.jar new-password

This one is actually in the docs and easy enough to find, but it would be nice to mention it close to the other password encrypting string method, to make it clear the two are different and not compatible. There fixed that for them.

Most of the Oauth secrets are managed by configutil tool, whereas the Identity Apps used configupdate.sh for those. OSP's configupdate.sh manages SSPR and one more OAuth secret in its config, the rest are in configutil.sh, which is mostly the internal IDG components that are used for internal communication between themselves.

Overall this new tool, has many things in common with the old tool, and new things learned here can sometimes help understand things on the Identity Apps side as well. I think there is a lot to write about this product since it has lots of functionality and as always it is impossible for documentation to cover everything, which leaves me a lot of room to add some articles. If you run across something interesting in the product, please consider writing it up so we all can share. This is a new product and there is lots to learn.