NTAC:3NS-20 Our company is undergoing a project to 'protect privileged access' by using a password vaulting product. We have been doing this for quite some time for applications teams who require higher levels of access to production datasets for problem resolution, installs, etc. The way it works is that a pool of logonids is created, along with an AD group that allows the appropriate applications folks to be able to 'check out' one of these pooled logonids for 24 hours via a web interface. The web interface uses the users lan password plus their secure key passcode and phrase to validate their identity. The project has now included Windows and Unix server admins, but instead of a pooled logonid these users have separate logonids with admin access and they 'check out' their own individual administrator logonid. Now the project has moved into the mainframe systems programmer space. So far we have used the 'privileges' on the logonid records as defined by our security product to limit this vaulting. Users with 'security' access must check out logonids from the vault. Users with the non-cncl privilege are next. During project discussions it has been brought up that the systems programmers, with their access to SYS1 datasets and operator commands, are privileged users by nature, and that eventually they are going to want to vault this access. We (the systems programmers) are strongly against this. It looks like at some point we will lose our battle and our access to the mainframe will be vaulted, meaning my entire team will need to check a logonid out of the password vault every morning before starting work. Our main argument now is that we do not want these logonids to be generic, pooled logonids, we want them to be basically the same as our own logonids so that we can see who did what by using the mainframe's built in logging (SMF data, ISPF stats, etc...).
My questions are, are other companies using password vaulting or other multi-level authentication for mainframe systems programmer access? What else could we use in our argument against using generic, pooled logonids? Thanks in advance! Jim ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
