The authentication process for the Reporting Module and all other Identity Applications has changed between IDM 4.0.x and IDM 4.5 so the old way of cleaning the Reporting database using REST won’t work anymore.

Here are the updated instructions for IDM 4.5.

Recently I performed some testing with about 1 million users and 40 000 groups and the same amount of resources that I then assigned to a subset of the test users.

This caused the reporting database to grow to a couple of GB and after deleting all those users, groups and resources I wanted to start with a clean Reporting database.

First before you start make sure you have the following information:

  • URL to your IDM 4.5 OSP server
  • URL to your IDM 4.5 Reporting module
  • One SSO Provider (OSP) OAuth client ID and OAuth client secret for the Reporting module. If you don’t remember run configupdate.sh and check the SSO clients tab.
  • Username and password of a Reporting Administrator user

rpt_45_sso

First perform the following:

  • Stop the DCS and MSGW drivers
  • Disable event collection in the Reporting Module (Data Collection->Identity Vaults)
Disable data collection in the reporting module.

Disable data collection in the reporting module. Make sure the checkbox is unchecked.

I’m using Firefox with the RESTClient add-on to perform this operation but any good REST client would work, such as curl for example.
You can read about the REST APIs by surfing to the

/rptdoc

page on your Reporting Module server.
First open a new RESTClient tab in Firefox and configure it to send a POST to your OSP URL which normally looks like this:

https://your.server.com:8443/osp/a/idm/auth/oauth2/grant

Add the following headers:

  • Content-Type: application/x-www-form-urlencoded

  • Accept: application/json

  • Accept-Charset: UTF-8

  • Authorization, use your OAuth client ID as the username and the OAuth client secret as the password. In a standard install the client ID is “rpt” and the client secret is “secret”.

Add the following body:

grant_type=password&username=REPORTADMINUSERNAME&password=REPORTADMINPASSWORD

Click on POST and you should get a response that contains a long access_token that looks like this:

"access_token": "eHwAIJ@RUjq@2z2.......

Copy the value, i.e. eHw….., you will need it later.

Here is a screenshot:

rpt_45_1

 

Next open a new RESTClient tab.

Send a DELETE to your Reporting Module REST interface URL that looks like this:

https://your.server.com:8443/IDMRPT-CORE/rpt/collectors/data

Add the following headers:

  • Accept: application/json
  • Accept-Charset: UTF-8
  • Content-Type: application/json
  • Authorization: bearer <VALUE OF access_token FROM PREVIOUS OPERATION>
    • bearer eHwAIJ@RUjq@2z2…….

Click SEND, if everything works OK you will not get a response back. Instead the RESTClient will wait forever.

If you have made a mistake you will get back a response with some error information.

rpt_45_2

You need to check your application server logfile, in my case catalina.out since I’m running the Reporting Module on Tomcat.

Example output from the logfile:

2014-11-19 19:21:35,095 [http-bio-443-exec-6] INFO com.novell.idm.rpt.core.server.logging.naudit.LogEvent- [RPT-CORE] [Data_Cleanup_Requested] Initiated by cn=uaadmin,o=System; Data Collector UUID ALL

You can also check the size of the database:

du /var/opt/novell/sentinel_eas/3rdparty/postgresql/ -h
  • Check the database with your favorite SQL browser.
  • Start the DCS driver.
  • Enable event collection in the Identity Reporting Module.
  • Start the MSGW driver.

All done!

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading...

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

One Comment

  • ybejarano says:

    Hi,

    i am making de process, but when i try get access_token i receive this message

    {
    “error”:”invalid_client”,
    “error_description”:”Unknown OAuth Client.”,
    “sub_error”:”wrongclient”
    }
    when i send the oauth i receive this message

    {
    “error”:”invalid_client”,
    “error_description”:”Authorization Header not of type BASIC.”,
    “sub_error”:”invauthhdr”
    }

    thak you for your support.

Nov 21, 2014
12:38 pm
Reads:
3,515
Score:
Unrated
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow