Re: RACF, setropts inactive() and long running guests
The way we handle this goes back a long way before the latest facilities to set NOPASSWORD were available. What we do is connect all users who are likely to be affected by this (long running servers etc.) to a specific RACF group. We then run a daily procedure in VMUTIL, that is authorised to list that group and issue an ALTUSER RESUME for each user in it. That is all that is needed. The user does not have to be revoked at the time and knowledge of the password is not needed. As we always use LOGONBY for any non-personal userid's, we should probably update our process to use NOPASSWORD, but this method may be useful for userids where you may, occasionally, need to know the password. Colin Allinson Amadeus Data Processing GmbH
Re: RACF, setropts inactive() and long running guests
Alan Altmark wrote: On Sunday, 09/28/2008 at 12:50 EDT, Leland Lucius [EMAIL PROTECTED] wrote: This would certainly make it easy and we wouldn't have to have any non-standard scheduled touching of the ID. I'll have to ponder it a little though since we do log onto a guest every so often to get to its console. But, that's so seldom, a call to the security group could temporarily add a password. You don't need to logon to get the console. From a class C user: CP SEND CP linuxuser CLOSE CONS TO whomever But, if the server can't be accessed via the network, we may need to access the console to play around...like maybe in single user mode. Mind you, we hardly ever have to do it, but... I've been playing around with your method (LOGONBY and NOPASS) and it looks like its going to work beautifully. And the best part is that it can all be controlled via DIRMAINT...no security group involvement. (They let us do DIRMAINT, but not RACF. :-)) Thanks, Leland
Re: RACF, setropts inactive() and long running guests
At my -former- customer's installation, we set the inactivity value to something around 6 months. This suited us as it was decided to IPL the z/VM systems at winter/summer time zone change. If that doesn't suit you: To take care of MAINT friends, you might use a server like VMUTIL to have those XAUTOLOGged every month or so. For other servers that cannot be XAUTOLOG this way, there may be a way to fool RACF, I didn't test, but maybe it can work. My first idea was to open an FTP session into z/VM, and use the userid password of the server whose last logon time you want to update. Further thought: use the CSL call to perform password validation. Obvious problem/drawback: you need to know the server's password. Can be easily tested by observing the last logon date with the RAC LISTUSER command. Other thoughts: maybe the RACROUTE macro can be used to update the last logon date. Or, also not checked:since z/VM 5.3, you get an LDAP server with z/VM, when properly set up, LDAP clients can then via LDAP update RACF user data. I don't know if last-logon date is one of the RACF fields exposed to LDAP. If it is, the CMS LDAP client could be used to issue a Q NAMES (e.g. weekly) and set the last logon date for every user that is found to be logged on. (As I'm currently in the team writing a redbook about a.o. password synchronisation between z/VM ad z/OS -what uses LDAP- I may be able next week to find this out). 2008/9/27 Leland Lucius [EMAIL PROTECTED] Just wondering what folks set INACTIVE() to a Linux only environment where guests stay up for long periods or where MAINT and the like aren't used for long periods. When we installed RACFVM, our security team set the same options as are being used on z/OS which we all thought was a good idea. But, we've been getting a lot of guests with revoked IDs. It wasn't until today when logging onto MAINT did we realize what we'd done since the logon seemed to hang and we didn't figure out what was going on until we looked at OPERATORs console: ICH303I INACTIVE INTERVAL EXCEEDED BY SPECIAL USER MAINT AT TERMINAL AC182D8F. 13ICH304D REPLY Y TO ACTIVATE USER OR N TO REVOKE USERID MAINT . So, we have the notion of simply change our INACTIVE(45) to NOINACTIVE (if we can get security to bite), but were wondering if there were other options. Thanks, Leland -- Kris Buelens, IBM Belgium, VM customer support
Re: RACF, setropts inactive() and long running guests
Kris Buelens wrote: If that doesn't suit you: To take care of MAINT friends, you might use a server like VMUTIL to have those XAUTOLOGged every month or so. Now I get what ppl were saying before about XAUTOLOGing things regularly. Didn't sink in before... For other servers that cannot be XAUTOLOG this way, there may be a way to fool RACF, I didn't test, but maybe it can work. My first idea was to open an FTP session into z/VM, and use the userid password of the server whose last logon time you want to update. Further thought: use the CSL call to perform password validation. Obvious problem/drawback: you need to know the server's password. Can be easily tested by observing the last logon date with the RAC LISTUSER command. Or precede the FTP/CSL call with a DIRM SETPW, so the password is known and, when done, do the DIRM SETPW again to some random value. That would work just dandy for us. Will give this a try if there's nobody mentions a RACF-way of doing it. Thanks, Leland
Re: RACF, setropts inactive() and long running guests
DIRM SETPW: that would need the the Dirmaint-RACF interfaces active. If you'd go that way, better use RAC ALTUSER userid PASSWORD(xyz) 2008/9/27 Leland Lucius [EMAIL PROTECTED] Kris Buelens wrote: If that doesn't suit you: To take care of MAINT friends, you might use a server like VMUTIL to have those XAUTOLOGged every month or so. Now I get what ppl were saying before about XAUTOLOGing things regularly. Didn't sink in before... For other servers that cannot be XAUTOLOG this way, there may be a way to fool RACF, I didn't test, but maybe it can work. My first idea was to open an FTP session into z/VM, and use the userid password of the server whose last logon time you want to update. Further thought: use the CSL call to perform password validation. Obvious problem/drawback: you need to know the server's password. Can be easily tested by observing the last logon date with the RAC LISTUSER command. Or precede the FTP/CSL call with a DIRM SETPW, so the password is known and, when done, do the DIRM SETPW again to some random value. That would work just dandy for us. Will give this a try if there's nobody mentions a RACF-way of doing it. Thanks, Leland -- Kris Buelens, IBM Belgium, VM customer support
Re: RACF, setropts inactive() and long running guests
On Saturday, 09/27/2008 at 12:26 EDT, Leland Lucius [EMAIL PROTECTED] wrote: Just wondering what folks set INACTIVE() to a Linux only environment where guests stay up for long periods or where MAINT and the like aren't used for long periods. When we installed RACFVM, our security team set the same options as are being used on z/OS which we all thought was a good idea. But, we've been getting a lot of guests with revoked IDs. : So, we have the notion of simply change our INACTIVE(45) to NOINACTIVE (if we can get security to bite), but were wondering if there were other options. A possible compromise could be: ALTUSER userid NOPHRASE NOPASSWORD will completely remove the password and phrase. - No one can logon directly to or use the id for authentication - The user can still be XAUTOLOGed - The user will never be revoked due to inactivity or too many logon attempts with a bad password Alan Altmark z/VM Development IBM Endicott
Re: RACF, setropts inactive() and long running guests
Could we still get onto that userid via LOGONBY? /Tom Kern Alan Altmark wrote: A possible compromise could be: ALTUSER userid NOPHRASE NOPASSWORD will completely remove the password and phrase. - No one can logon directly to or use the id for authentication - The user can still be XAUTOLOGed - The user will never be revoked due to inactivity or too many logon attempts with a bad password Alan Altmark z/VM Development IBM Endicott
Re: RACF, setropts inactive() and long running guests
Yes... Sent from my iPhone On Sep 27, 2008, at 5:48 PM, Thomas Kern [EMAIL PROTECTED] wrote: Could we still get onto that userid via LOGONBY? /Tom Kern Alan Altmark wrote: A possible compromise could be: ALTUSER userid NOPHRASE NOPASSWORD will completely remove the password and phrase. - No one can logon directly to or use the id for authentication - The user can still be XAUTOLOGed - The user will never be revoked due to inactivity or too many logon attempts with a bad password Alan Altmark z/VM Development IBM Endicott
Re: RACF, setropts inactive() and long running guests
Alan Altmark wrote: A possible compromise could be: ALTUSER userid NOPHRASE NOPASSWORD will completely remove the password and phrase. - No one can logon directly to or use the id for authentication - The user can still be XAUTOLOGed - The user will never be revoked due to inactivity or too many logon attempts with a bad password This would certainly make it easy and we wouldn't have to have any non-standard scheduled touching of the ID. I'll have to ponder it a little though since we do log onto a guest every so often to get to its console. But, that's so seldom, a call to the security group could temporarily add a password. Thanks much, Llenad
Re: RACF, setropts inactive() and long running guests
Scott Rohling wrote: Yes... Sent from my iPhone On Sep 27, 2008, at 5:48 PM, Thomas Kern [EMAIL PROTECTED] wrote: Could we still get onto that userid via LOGONBY? Awesome, then that sounds like the way to go. Thanks everyone! Leland
Re: RACF, setropts inactive() and long running guests
On Sunday, 09/28/2008 at 12:50 EDT, Leland Lucius [EMAIL PROTECTED] wrote: This would certainly make it easy and we wouldn't have to have any non-standard scheduled touching of the ID. I'll have to ponder it a little though since we do log onto a guest every so often to get to its console. But, that's so seldom, a call to the security group could temporarily add a password. You don't need to logon to get the console. From a class C user: CP SEND CP linuxuser CLOSE CONS TO whomever Of course, products like IBM Operations Manager for z/VM can obviate the need to manage console logs in this way. Alan Altmark z/VM Development IBM Endicott
RACF, setropts inactive() and long running guests
Just wondering what folks set INACTIVE() to a Linux only environment where guests stay up for long periods or where MAINT and the like aren't used for long periods. When we installed RACFVM, our security team set the same options as are being used on z/OS which we all thought was a good idea. But, we've been getting a lot of guests with revoked IDs. It wasn't until today when logging onto MAINT did we realize what we'd done since the logon seemed to hang and we didn't figure out what was going on until we looked at OPERATORs console: ICH303I INACTIVE INTERVAL EXCEEDED BY SPECIAL USER MAINT AT TERMINAL AC182D8F. 13ICH304D REPLY Y TO ACTIVATE USER OR N TO REVOKE USERID MAINT . So, we have the notion of simply change our INACTIVE(45) to NOINACTIVE (if we can get security to bite), but were wondering if there were other options. Thanks, Leland
