Colin, Inactivity timeout is a system wide setting. The only workaround I could come up with is this: If your system is like mine, it is a lot of linux guests, a few batchlike system userids, and a few system programmers. See if they will allow you to change the interval to the maximum, 254, and NOT revoke. Then, you can do the revoke manually. By that I mean, write and run a nightly exec that checks those three or four system programmers, see when their 'last-access' is from a RAC LU, and if it's beyond 30 days, issue a RAC ALU userid REVOKE. I think it's a nice idea, so I'm going to write one. I'll email it to you if you want it. MA
On Tue, Oct 21, 2008 at 4:00 AM, Colin Allinson <[EMAIL PROTECTED]> wrote: > > I know this has been the subject of recent discussion & I said that we have > a process to override this for defined virtual machines. However, for a > number of reasons, (mainly keeping up with identifying them), this is giving > us some difficulty. > > Our VM systems are now very different beasts to when the original rules were > defined so I am talking to our internal security about lengthening the > period of inactivity before automatic revoke. They are sympathetic but asked > me to investigate if the inactivity time-out can be different dependant on > RACF group or if it is a system wide limit. > > As far as I know, it is a system wide limit but I would be pleased if > someone can confirm or deny this. > > > Colin Allinson > > Amadeus Data Processing GmbH >
