So here's the quick and dirty version for those interested.
/* Rexx */
erase racf data a
GLOBALV SELECT $RACGRP SET $RAC_APN Y
GLOBALV SELECT $RACGRP SET $RAC_ISPF Y
'RAC LU MATYAZ'
GLOBALV SELECT $RACGRP SET $RAC_APN N
GLOBALV SELECT $RACGRP SET $RAC_ISPF N
Daybase = date('Julian')
D30ago = Daybase - 30
'PIPE < RACF DATA | STRIP | LOCATE /LAST-ACCESS/ | STEM xracf.'
If rc <> 0 then exit rc
Do i = 1 to xracf.0
parse var xracf.i xlast '-' xaccess '=' xyr '.' xday '/' xrest
xlastacc = xyr || xday
If xlastacc < D30ago then do
'rac alu MATYAZ revoke'
say 'Revoking userid MATYAZ due to last access ' xlastacc
end
End
On Wed, Oct 22, 2008 at 6:56 AM, Mary Anne Matyaz <[EMAIL PROTECTED]>
wrote:
> 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
>>
>
