Re: Setting DIRM NEEDPASS NO in a LOGONBY user
Having been asked just last week, by a member of the system 'superuser' group, to increase his timeout-lockup in the session manager from 10 to 20 (!) minutes, I definitely agree with Brian! Original message Date: Thu, 12 Feb 2009 09:09:32 -0600 From: Brian Nielsen bniel...@sco.idaho.gov Subject: Re: Setting DIRM NEEDPASS NO in a LOGONBY user To: IBMVM@LISTSERV.UARK.EDU On Thu, 12 Feb 2009 09:21:59 -0500, Alan Altmark alan_altm...@us.ibm.com wrote: This leads me to ask: Is NEEDPASS YES still needed? I view it as an anachronism from an older time when we didn't have autolock screensavers and generally more stringent workstation security policies. No more always on terminals. Given the number of people who walk away and leave their PC's unlocked and unattended despite policy, it would be a poor assumption that the delay time it takes the autolock to kick in is sufficient security. Blech! Brian Nielsen
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
On Mon, Feb 16, 2009 at 6:51 AM, Shimon Lebowitz shim...@iname.com wrote: Having been asked just last week, by a member of the system 'superuser' group, to increase his timeout-lockup in the session manager from 10 to 20 (!) minutes, I definitely agree with Brian! Provided that the software is robust enough that it does not leave sessions open that could be picked up by someone else (yes, I've seen those) then I think closing unused hidden sessions does not add a lot to security. It does increase the irritation and eventually makes people feel less responsible for security themselves. When you push too hard with password rules and change schedules, people end up using the same password everywhere, even run programs to change it everywhere at the same time. At one installation where I worked, a short session time-out was in use. It was not uncommon for folks to have the password under a programmable key in their 3270 emulator. Or even program the entire VM logon in the emulator... And obviously it was also popular to run a program in your idle CMS session that would make it not appear idle. Clearly this does not achieve anything and increases the cost. Rob
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
So I'll revert to my old habits and make a local mod to the password column in 140/150CMDS DATADVH 2009/2/11 Alan Altmark alan_altm...@us.ibm.com: On Wednesday, 02/11/2009 at 11:40 EST, Kris Buelens kris.buel...@gmail.com wrote: I'm installing z/VM 5.4 with Dirmaint and RACF (and this time following the book as opposed to my own methods). I did copy the CONFIGRC SAMPDVH as DATADVH and DIRMAINT sees it. So, it should have all RACF enablements. MAINT is defined as a LOGONBY user and is logged on BY BUELENSC. When I issue DIRM NEEDPASS NO in MAINT, DIRMAINT prompts me for MAINT's password: - I'd say it should prompt for BUELENSC's password (I am not supposed to know MAINT's password when using LOGONBY) - So I enter BUELENSC's password and RACF rejects it. Seems that the query DIRMAINT passes to RACF indeed wants indeed an authentication as MAINT: OPERATOR gets ICH301I MAXIMUM PASSWORD ATTEMPTS BY SPECIAL USER MAINT Is this supposed to work? I would say No. You have LOGON BY access, but that doesn't confer modify the directory permission. If MAINT is LBYONLY (in the RACF sense) then you need to make such changes from another user who is authorized to act FOR MAINT. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
Alan Altmark alan_altm...@us.ibm.com wrote: I would say No. You have LOGON BY access, but that doesn't confer modify the directory permission. If MAINT is LBYONLY (in the RACF sense) then you need to make such changes from another user who is authorized to act FOR MAINT. Alan Altmark z/VM Development IBM Endicott From my point of view I would have thought that this is not what you would want. In our installation, for security reasons, privileged functions are not carried out on personal userids and all privileged userids (including MAINT) are LOGONBY. This means there is an audit trail of who did what. MAINT has been set to 'DIRM NEEDPASS NO' for as long as I can remember so I can't remember how we did that in the first place but it is certainly what we would want. The alternative is for function to be distributed and then you have little chance of following or controlling/auditing what is going on. Colin Allinson Amadeus Data Processing GmbH
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
On Thursday, 02/12/2009 at 04:16 EST, Colin Allinson cgallin...@amadeus.com wrote: Alan Altmark alan_altm...@us.ibm.com wrote: I would say No. You have LOGON BY access, but that doesn't confer modify the directory permission. If MAINT is LBYONLY (in the RACF sense) then you need to make such changes from another user who is authorized to act FOR MAINT. From my point of view I would have thought that this is not what you would want. In our installation, for security reasons, privileged functions are not carried out on personal userids and all privileged userids (including MAINT) are LOGONBY. This means there is an audit trail of who did what. MAINT has been set to 'DIRM NEEDPASS NO' for as long as I can remember so I can't remember how we did that in the first place but it is certainly what we would want. The alternative is for function to be distributed and then you have little chance of following or controlling/auditing what is going on. I'm not denying the requirement (need/desire) for the capability. The question was asked whether the way it works is correct or not. It is working as we (IBM) intend. Over time I hope to provide better controls for this sort of thing. It was not until recently that LOGON BY considerations began to appear in implicit authorizations. This leads me to ask: Is NEEDPASS YES still needed? I view it as an anachronism from an older time when we didn't have autolock screensavers and generally more stringent workstation security policies. No more always on terminals. Alan Altmark z/VM Development IBM Endicott
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
Alan Altmark alan_altm...@us.ibm.com wrote: This leads me to ask: Is NEEDPASS YES still needed? I view it as an anachronism from an older time when we didn't have autolock screensavers and generally more stringent workstation security policies. No more always on terminals. Alan Altmark z/VM Development IBM Endicott That is, indeed, a good point. In a well controlled environment, (good attention paid to physical security as well as controlled authorities), it should not be needed. I am not sure, however, that it is possible to always make that assumption. Maybe, in a future release of DIRMAINT, it will be possible to configure the default (it would be nice but I am not really expecting to see it before I retire !!). Colin Allinson Amadeus Data Processing GmbH
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
On Thu, 12 Feb 2009 09:21:59 -0500, Alan Altmark alan_altm...@us.ibm.com wrote: This leads me to ask: Is NEEDPASS YES still needed? I view it as an anachronism from an older time when we didn't have autolock screensavers and generally more stringent workstation security policies. No more always on terminals. Given the number of people who walk away and leave their PC's unlocked an d unattended despite policy, it would be a poor assumption that the delay time it takes the autolock to kick in is sufficient security. Blech! Brian Nielsen
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
I think whether NEEDPASS YES is still needed is an it depends and should be left to the customer. What is needed, however, is a re-engineering or a redesign or rethinking of how and where it is defined in DIRMAINT. In talking to some developer in Endicott (don't remember who), what came thru is that from the developer standpoint, they know the product and definition tables so well that it is not apparent to them how totally confusing DIRMAINT is from a setup or installation standpoint. Coupling the confusion of DIRMAINT with RACF takes the confusion factor to a whole new dimension. Take some VM sysprog from off the street who doesn't live with DIRMAINT every day and have them install it and take note of the questions and problems they encounter. Just my opinion. Jim Alan Altmark wrote: I'm not denying the requirement (need/desire) for the capability. The question was asked whether the way it works is correct or not. It is working as we (IBM) intend. Over time I hope to provide better controls for this sort of thing. It was not until recently that LOGON BY considerations began to appear in implicit authorizations. This leads me to ask: Is NEEDPASS YES still needed? I view it as an anachronism from an older time when we didn't have autolock screensavers and generally more stringent workstation security policies. No more always on terminals. Alan Altmark z/VM Development IBM Endicott -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
On 2/12/09 9:21 AM, Alan Altmark alan_altm...@us.ibm.com wrote: This leads me to ask: Is NEEDPASS YES still needed? I view it as an anachronism from an older time when we didn't have autolock screensavers and generally more stringent workstation security policies. No more always on terminals. Yes, it is still needed, or at least until IBM supplies a native, no additional cost authorization capability that is more granular than the CP privilege class system and the word comes down from on high that applications will use that capability in place of password or privilege class checking. As you pointed out, login ability does not imply the ability to modify the directory, and having to confirm changes to system configuration with a token (note, not necessarily a password) is an important part of controlling an environment. There's not really (at least IMHO) a tie between terminal access issues any more; it's an issue of change control.
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
Jim said: = I think whether NEEDPASS YES is still needed is an it depends and should be left to the customer. What is needed, however, is a re-engineering or a redesign or rethinking of how and where it is defined in DIRMAINT. In talking to some developer in Endicott (don't remember who), what came thru is that from the developer standpoint, they know the product and definition tables so well that it is not apparent to them how totally confusing DIRMAINT is from a setup or installation standpoint. Coupling the confusion of DIRMAINT with RACF takes the confusion factor to a whole new dimension. Take some VM sysprog from off the street who doesn't live with DIRMAINT every day and have them install it and take note of the questions and problems they encounter. = Better yet go to a new z/VM shop that has z/VM just to support virtualized Linux and watch as they attempt to get dirmaint and racf installed and configured and then begin to use it. It isn't pretty. Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: lionel.b.d...@kp.org AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We?re here to make lives better.? ?Never attribute to malice what can be caused by miscommunication.? NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
Amen! Hear Hear. On 2/12/09 11:03 AM, Jim Bohnsack jab...@cornell.edu wrote: I think whether NEEDPASS YES is still needed is an it depends and should be left to the customer. What is needed, however, is a re-engineering or a redesign or rethinking of how and where it is defined in DIRMAINT. In talking to some developer in Endicott (don't remember who), what came thru is that from the developer standpoint, they know the product and definition tables so well that it is not apparent to them how totally confusing DIRMAINT is from a setup or installation standpoint. Coupling the confusion of DIRMAINT with RACF takes the confusion factor to a whole new dimension. Take some VM sysprog from off the street who doesn't live with DIRMAINT every day and have them install it and take note of the questions and problems they encounter. Just my opinion. Jim
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
Been there - done that. We had some problems setting up DIRMAINT and RACF in a three lpar environment. Back to the question of the need for NEEDPASS. What about the possibility of having an option in DIRMAINT to allow RACF (shot self in foot) to control things. Paul Feller AIT Mainframe Technical Support From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Lionel B. Dyck Sent: Thursday, February 12, 2009 10:11 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Setting DIRM NEEDPASS NO in a LOGONBY user Jim said: = I think whether NEEDPASS YES is still needed is an it depends and should be left to the customer. What is needed, however, is a re-engineering or a redesign or rethinking of how and where it is defined in DIRMAINT. In talking to some developer in Endicott (don't remember who), what came thru is that from the developer standpoint, they know the product and definition tables so well that it is not apparent to them how totally confusing DIRMAINT is from a setup or installation standpoint. Coupling the confusion of DIRMAINT with RACF takes the confusion factor to a whole new dimension. Take some VM sysprog from off the street who doesn't live with DIRMAINT every day and have them install it and take note of the questions and problems they encounter. = Better yet go to a new z/VM shop that has z/VM just to support virtualized Linux and watch as they attempt to get dirmaint and racf installed and configured and then begin to use it. It isn't pretty. Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: lionel.b.d...@kp.orgmailto:lionel.b.d...@kp.org AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We're here to make lives better. Never attribute to malice what can be caused by miscommunication. NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
We have VM:Secure, but the same question came up the other day. We have application userids that have a number of developers authorized to use LOGONBY, but the application owners don't want those developers to be able to change the Rules files for those userids. They want that authority restricted to just a couple of people. VM:Secure normally prompts for the directory password when a user enters a command to modify the directory or Rules file. If the password is LBYONLY, then the user enters LBYONLY in response to the prompt. There's also an authorization similar to DIRM NEEDPASS NO to remove the prompt. The solution for this application was to withhold the authorization for the userids to manage their own Rules files, and grant it to an administrator userid that only the Rules administrators could LOGONBY to. As far as security and audit trails go, there's no functional difference between an audit trail that says userid DENNIS did LOGONBY to MAINT and then MAINT did VMSECURE EDIT RSCS, vs an audit trail that says userid DENNIS did VMSECURE EDIT RSCS, except that the first version takes more steps to follow. To the question of whether DIRM NEEDPASS YES is still needed, our security standards require re-authentication, i.e. enter your password, at the time a password is changed. Even though we're not a DIRMAINT customer, I'm sure there are DIRMAINT shops with the same requirement. I've used DIRMAINT before, and I agree that the setup and configuration is arcane. My suggestion for changing it is to make it look just like VM:Secure. Dennis O'Brien 39,585 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Thursday, February 12, 2009 06:22 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Setting DIRM NEEDPASS NO in a LOGONBY user On Thursday, 02/12/2009 at 04:16 EST, Colin Allinson cgallin...@amadeus.com wrote: Alan Altmark alan_altm...@us.ibm.com wrote: I would say No. You have LOGON BY access, but that doesn't confer modify the directory permission. If MAINT is LBYONLY (in the RACF sense) then you need to make such changes from another user who is authorized to act FOR MAINT. From my point of view I would have thought that this is not what you would want. In our installation, for security reasons, privileged functions are not carried out on personal userids and all privileged userids (including MAINT) are LOGONBY. This means there is an audit trail of who did what. MAINT has been set to 'DIRM NEEDPASS NO' for as long as I can remember so I can't remember how we did that in the first place but it is certainly what we would want. The alternative is for function to be distributed and then you have little chance of following or controlling/auditing what is going on. I'm not denying the requirement (need/desire) for the capability. The question was asked whether the way it works is correct or not. It is working as we (IBM) intend. Over time I hope to provide better controls for this sort of thing. It was not until recently that LOGON BY considerations began to appear in implicit authorizations. This leads me to ask: Is NEEDPASS YES still needed? I view it as an anachronism from an older time when we didn't have autolock screensavers and generally more stringent workstation security policies. No more always on terminals. Alan Altmark z/VM Development IBM Endicott
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
On Thursday, 02/12/2009 at 11:05 EST, Jim Bohnsack jab...@cornell.edu wrote: I think whether NEEDPASS YES is still needed is an it depends and should be left to the customer. What is needed, however, is a re-engineering or a redesign or rethinking of how and where it is defined in DIRMAINT. In talking to some developer in Endicott (don't remember who), what came thru is that from the developer standpoint, they know the product and definition tables so well that it is not apparent to them how totally confusing DIRMAINT is from a setup or installation standpoint. Coupling the confusion of DIRMAINT with RACF takes the confusion factor to a whole new dimension. Take some VM sysprog from off the street who doesn't live with DIRMAINT every day and have them install it and take note of the questions and problems they encounter. I do understand and appreciate that the number of touchpoints in z/VM to configure permissions to do various things might be considered by some to be, um, a tad excessive. There is an oft-repeated requirement (particularly from larger companies) for z/VM to centralize security management. This extends to authorizations for TCP/IP, DIRMAINT, Performance Toolkit, and even little ol' RSCS. Further, I recognize that while the DIRMAINT-RACF connector is way(!) better in z/VM 5.4, it still isn't complete. Alan Altmark z/VM Development IBM Endicott
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
On Thursday, 02/12/2009 at 09:45 EST, Colin Allinson cgallin...@amadeus.com wrote: That is, indeed, a good point. In a well controlled environment, (good attention paid to physical security as well as controlled authorities), it should not be needed. I am not sure, however, that it is possible to always make that assumption. The system already does. The radioactive STORE HOST command, able to subtly and significantly alter the eDNA of the system, and arguably the most dangerous (even if occassionally useful) CP command extant, does not require password confirmation. Likewise, RACF admin commands issued by a RACF SPECIAL users do not prompt. So I'm not sure that the false sense of security engendered by NEEDPASS YES is healthy. Alan Altmark z/VM Development IBM Endicott
Setting DIRM NEEDPASS NO in a LOGONBY user
I'm installing z/VM 5.4 with Dirmaint and RACF (and this time following the book as opposed to my own methods). I did copy the CONFIGRC SAMPDVH as DATADVH and DIRMAINT sees it. So, it should have all RACF enablements. MAINT is defined as a LOGONBY user and is logged on BY BUELENSC. When I issue DIRM NEEDPASS NO in MAINT, DIRMAINT prompts me for MAINT's password: - I'd say it should prompt for BUELENSC's password (I am not supposed to know MAINT's password when using LOGONBY) - So I enter BUELENSC's password and RACF rejects it. Seems that the query DIRMAINT passes to RACF indeed wants indeed an authentication as MAINT: OPERATOR gets ICH301I MAXIMUM PASSWORD ATTEMPTS BY SPECIAL USER MAINT Is this supposed to work? -- Kris Buelens, IBM Belgium, VM customer support
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
The DIRMAINT install can be, or rather IS, a real PITA. Make sure that in your CONFIG* DATADVH you have replaced ESM_PASSWORD_AUTHENTICATION_EXIT= with DVHXPA EXEC rather than the older DVHDA0. Also in 140CMDS DATADVH and 150CMDS DATADVH, be sure to have column 35 set to N. AUTHFOR CONTROL needs to be set up as well on the DIRMAINT 1DF disk. I'm pretty sure that those are not the only gotcha's but they are what I have in my notes for going to 5.4. It's hard to believe that a product can have evolved with so many related and interdependent control files on different disks. I don't think that DIRMAINT was planned. It just sort of happened and I've voiced that opinion before here on the list and to various people in Endicott. Jim Kris Buelens wrote: I'm installing z/VM 5.4 with Dirmaint and RACF (and this time "following the book" as opposed to my own methods). I did copy the CONFIGRC SAMPDVH as DATADVH and DIRMAINT sees it. So, it should have all RACF enablements. MAINT is defined as a LOGONBY user and is logged on BY BUELENSC. When I issue DIRM NEEDPASS NO in MAINT, DIRMAINT prompts me for MAINT's password: - I'd say it should prompt for BUELENSC's password (I am not supposed to know MAINT's password when using LOGONBY) - So I enter BUELENSC's password and RACF rejects it. Seems that the query DIRMAINT passes to RACF indeed wants indeed an authentication as MAINT: OPERATOR gets ICH301I MAXIMUM PASSWORD ATTEMPTS BY SPECIAL USER MAINT Is this supposed to work? -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell jab...@cornell.edu
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
VM:Secure would also prompt for MAINT's password, using the logic that even if you had LOGONBY to a user ID, that wouldn't grant you the capability to change the directory entry for that ID. Bob Bolch - I'd say it should prompt for BUELENSC's password (I am not supposed to know MAINT's password when using LOGONBY)
Re: Setting DIRM NEEDPASS NO in a LOGONBY user
On Wednesday, 02/11/2009 at 11:40 EST, Kris Buelens kris.buel...@gmail.com wrote: I'm installing z/VM 5.4 with Dirmaint and RACF (and this time following the book as opposed to my own methods). I did copy the CONFIGRC SAMPDVH as DATADVH and DIRMAINT sees it. So, it should have all RACF enablements. MAINT is defined as a LOGONBY user and is logged on BY BUELENSC. When I issue DIRM NEEDPASS NO in MAINT, DIRMAINT prompts me for MAINT's password: - I'd say it should prompt for BUELENSC's password (I am not supposed to know MAINT's password when using LOGONBY) - So I enter BUELENSC's password and RACF rejects it. Seems that the query DIRMAINT passes to RACF indeed wants indeed an authentication as MAINT: OPERATOR gets ICH301I MAXIMUM PASSWORD ATTEMPTS BY SPECIAL USER MAINT Is this supposed to work? I would say No. You have LOGON BY access, but that doesn't confer modify the directory permission. If MAINT is LBYONLY (in the RACF sense) then you need to make such changes from another user who is authorized to act FOR MAINT. Alan Altmark z/VM Development IBM Endicott
