Way to track web console & DS admin activities?

kandyshandy · Post by **kandyshandy** » Mon Jul 13, 2015 9:23 pm

We have arrived at a situation like this. "Admin team" will hold dsadm, isadmin & wasadmin IDs. Another team "ID Management team" will have named IDs with role as suite admin who are expected to manage JUST creation/deletion of User IDs, assigning roles, in the near future (proposal). Admin team is asking a question "How do we know if ID Management team screws up something apart from creating/deleting IDs?"... like deleting ID by mistake in web console, deleting project by mistake in administrator etc

Immediate answer in my mind was to enable audit in the environment but unfortunately it may not be possible immediately. I looked at web console for reports related to this tracking but none. Would like to know if anyone of you got better idea on this?

PaulVL · Post by **PaulVL** » Tue Jul 14, 2015 12:47 pm

Are you doing LDAP authentication?

You should seek to push the user id management into LDAP land and not assigne users directly to projects. Assign GROUPS to projects. Access to the LDAP groups are assigned outside datastage.

A lot better in terms of auditing and security.

You (DS ADMINS) assign authority to the group once.

rkashyap · Post by **rkashyap** » Tue Jul 14, 2015 3:03 pm

If DataStage admin team wants to delegate responsibilities for some of the routine activities to a secondary team and minimize possibilities of screw-ups, then they can build canned scripts using commands for administering projects for those routine activities.

Necessary validation, logging etc can be build in the script. Authentication can be managed without sharing admin credentials thru an authfile.

PaulVL · Post by **PaulVL** » Tue Jul 14, 2015 3:15 pm

So I think that we can all agree that giving admin rights to a large group of folks is a very bad idea. It's the keys to the kingdom litterally.

An admin can modify any job, compile, execute, etc... accross all projects. Huge security risk.

You do not want to open that can of worms.

rkashyap · Post by **rkashyap** » Tue Jul 14, 2015 3:31 pm

Yes.

priyadarshikunal · Post by **priyadarshikunal** » Tue Jul 14, 2015 4:33 pm

Enable CDC on XMETA on tables which stores the credentials (I does show who created it or updated it, but not who deleted it - LDAP may come to rescue), and/or change the logging on WAS to log all events.
Please note that SystemOut.log will be big in that case and you will have to do some digging up to find events.
But those screw-ups mentioned by Paul, on a project, like unauthorized changes in a job, you will have to restrict using file permissions of RT_ files.

Only providing access to pre-defined scripts may be good idea to restrict screw-ups.

kandyshandy · Post by **kandyshandy** » Tue Jul 14, 2015 11:17 pm

Thank you friends for your response.

We use internal registry in this department.

As mentioned earlier, DS Admin team will continue to do all admin/maintenance activities like installing patch, rebooting as needed, upgrade etc. The "ID management team will JUST create user in web console and assign role in web console & DS admin". This team is expected to manage ID creation across all tools in this organization

I see something interesting from 9.1 onwards. Auditing in Information Server itself. I looked at the audit log created and it has good info along with session ID. For e.g. X logged in to web console, created an user, assigned role, logout etc. For OS level login, there is not much info except "client command", but I guess SESSION ID will be helpful to find more at OS level. Not sure if Priyadarshi Kunal is talking something similar. Here is the link to know more.

http://www-01.ibm.com/support/knowledge ... tings.html

priyadarshikunal · Post by **priyadarshikunal** » Wed Jul 15, 2015 6:09 am

I believe, I have seen ISAudit.log in earlier versions as well like in 8.5. However as you have already mentioned for OS logging, its not kind of one stop shop.

Along with setting up this ISAudit logging, If you login to WAS admin and change the logging to * i.e. log everything, but will have some additional info as well but then the logs will be huge and need to be archived/moved frequently.

XMETA user/credential tables also has the info on who has made the last change to that particular user and when (like last updated time and last updated by).

But since, you are using internal registry, I think you have a workable solution.