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
Re: dirm needpass no
From DirMaint Support: What they have done is made every command be not prompted for a password. Which of course is not the way DirMaint typically runs. Someone, probably on the listserv, told them in the past they could alter the cmds file to remove them from password authorization. Something which I would typically describe as dangerous but perhaps on their education/test system it is what they want. With this in mind these files are not typical files to be needing tailoring at all. The are tailorable if there is some special case which they seem to have. This is why they are not discussed in the documentation (TAG). In the case of AUTHBY CONTROL this is built when you use the AUTHBY function for BYUSERS. There are several control files in DirMaint which get built because the external command was issued. Therefore there is no need for the customer to be informed of this file. If he would follow the documentation given with the product he is informed of everything he needs to know about. By default DirMaint requires passwords. The way they operate as discussed they are not. However, if the issue a NEEDPASS command which is an optional command it could confuse the issue. What I believe they should have done to give everyone access to all commands by making every command a GENERAL use command. Then the password prompt would not be so confusing. But as long as they know what they have done there is no issue. Just be aware that this could be dangerous. They are giving access to everyone to DASD commands which could be a loaded gun in the hands of the wrong people Colleen M Brown IBM z/VM and Related Products Development and Service Jim Bohnsack [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 11/14/2007 01:10 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: dirm needpass no I took a look at doc for 140CMDS and 150CMDS and now I see the Y or N called out for col 35. I overlooked that as I did the last time we upgraded DIRMAINT. Mark found it then as he did now. What I don't understand is what appears to be the fact that there are so many places in DIRMAINT, both the client side and the server side where authorization is granted. On the client side, there appear to be GLOBALV options that can be set and there is also the DIRM NEEDPASS NO or YES. On DIRMAINT, there is the Y or N in the 1x0CMDS DATADVH file but there is also the AUTHBY CONTROL file. The descriptions for all of them seem to be scattered in different manuals rather than having a section in the Tailoring and Admin. manual. That makes setup of DIRMAINT really messy as does many of the different configuration files. Jim Mark Bodenstein wrote: --=_277284843==.ALT Content-Type: text/plain; charset=us-ascii; format=flowed Jim is away in Texas and I'm here minding the shop. (Though he seems to be reading email, so I won't be surprised if he chimes in.) I checked the 140CMDS DATADVH and 150CMDS DATADVH files on the DIRMAINT 11F minidisk on our test VM LPAR which has DirMaint at the z/VM 5.3 level. These two files had mostly Y's in column 35 for the various commands, indicating that a password was required. In production (where we don't need to specify passwords) these two files have all N's in column 35. So I edited the files to specify N's in column 35, and restarted DIRMAINT. Voila! No passwords required. This is without doing anything with GLOBALV on the client side. I checked my GLOBALV files and didn't find NEEDPASS anywhere. Just to be sure I also checked the http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsl3b21/9.43 z/VM 5.3 DirMaint http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsl3b21/9.43 Tailoring and Administration Guide. NEEDPASS is defined in Table 42 as a LASTING GLOBALV variable in pool DVH15 for possible use by DVHCX* and DVHPX* exits in the user's virtual machine (client side). There's no mention of the NEEDPASS global variable being used by anything other than being available for use by these exits. Mark Bodenstein ([EMAIL PROTECTED]) Cornell University At 10:57 AM 11/12/2007, Alan Altmark wrote: On Monday, 11/12/2007 at 08:19 EST, Phil Smith III [EMAIL PROTECTED] wrote: A. Harry Williams [EMAIL PROTECTED] wrote: No, he's talking about GLOBALV SELECT DVH15 SET NEEDPASS NO OK, I must have misunderstood part of the thread then. This is the setting I was referring to which, as your post goes on to note, doesn't work if done SOLELY on the client, because the server still wants a password. So, from the discussion here, I'm getting the idea that even though NEEDPASS NO is remaining set on the client side, upgrading the DIRMAINT server somehow causes it to forget its setting for that same client. And that necessitates yet another NEEDPASS
Re: dirm needpass no
Thanks Colleen. Could you please pass this response back to DirMaint Support? This is our production system, and we certainly want to control who can issue DirMaint commands. The question is the best way to do this. In general we want to make things secure, but also easy to use for the few authorized userids. Note that we do NOT give DirMaint authority to all of our users. We give it to a few systems programmers, and a few staff at the Help Desk that are responsible for creating VM userids. To do this, we use the following DirMaint configuration files: AUTHFOR CONTROL AUTHDASD DATADVH (Jim was probably thinking of AUTHFOR CONTROL when he said AUTHBY CONTROL.) We also use RACF to restrict access to 5VMDIR30 11F, the DirMaint primary interface code disk, to only the userids we intend to have DirMaint privileges. With all of that in place to restrict who can issue DirMaint commands, we don't want to also have to have each privileged user respond with a password to use DirMaint. I'll leave it up to Jim to respond to If he would follow the documentation given with the product he is informed of everything he needs to know about. First he needs to take more of his blood pressure medicine. Thanks, Mark Bodenstein ([EMAIL PROTECTED]) Cornell University At 01:56 PM 11/16/2007, you wrote: From DirMaint Support: What they have done is made every command be not prompted for a password. Which of course is not the way DirMaint typically runs. Someone, probably on the listserv, told them in the past they could alter the cmds file to remove them from password authorization. Something which I would typically describe as dangerous but perhaps on their education/test system it is what they want. With this in mind these files are not typical files to be needing tailoring at all. The are tailorable if there is some special case which they seem to have. This is why they are not discussed in the documentation (TAG). In the case of AUTHBY CONTROL this is built when you use the AUTHBY function for BYUSERS. There are several control files in DirMaint which get built because the external command was issued. Therefore there is no need for the customer to be informed of this file. If he would follow the documentation given with the product he is informed of everything he needs to know about. By default DirMaint requires passwords. The way they operate as discussed they are not. However, if the issue a NEEDPASS command which is an optional command it could confuse the issue. What I believe they should have done to give everyone access to all commands by making every command a GENERAL use command. Then the password prompt would not be so confusing. But as long as they know what they have done there is no issue. Just be aware that this could be dangerous. They are giving access to everyone to DASD commands which could be a loaded gun in the hands of the wrong people Colleen M Brown IBM z/VM and Related Products Development and Service Jim Bohnsack [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 11/14/2007 01:10 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: dirm needpass no I took a look at doc for 140CMDS and 150CMDS and now I see the Y or N called out for col 35. I overlooked that as I did the last time we upgraded DIRMAINT. Mark found it then as he did now. What I don't understand is what appears to be the fact that there are so many places in DIRMAINT, both the client side and the server side where authorization is granted. On the client side, there appear to be GLOBALV options that can be set and there is also the DIRM NEEDPASS NO or YES. On DIRMAINT, there is the Y or N in the 1x0CMDS DATADVH file but there is also the AUTHBY CONTROL file. The descriptions for all of them seem to be scattered in different manuals rather than having a section in the Tailoring and Admin. manual. That makes setup of DIRMAINT really messy as does many of the different configuration files. Jim
Re: dirm needpass no
Thanks Colleen. Could you please pass this response back to DirMaint Support? I agree with what Alan recommended a week ago now, please open a problem with the IBM support center and work directly with level 2. Thanks Best Regards, Les Geer IBM z/VM and Linux Development
Re: dirm needpass no
I passed this onto DirMaint support and they have asked that you open a PMR. Colleen M Brown IBM z/VM and Related Products Development and Service Les Geer (607-429-3580) [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 11/16/2007 04:36 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: dirm needpass no Thanks Colleen. Could you please pass this response back to DirMaint Support? I agree with what Alan recommended a week ago now, please open a problem with the IBM support center and work directly with level 2. Thanks Best Regards, Les Geer IBM z/VM and Linux Development
Re: dirm needpass no
On Friday, 11/16/2007 at 03:25 EST, Mark Bodenstein [EMAIL PROTECTED] wrote: This is our production system, and we certainly want to control who can issue DirMaint commands. The question is the best way to do this. In general we want to make things secure, but also easy to use for the few authorized userids. An excellent goal. DirMaint Support can tell you the right way to do that so that your configuration doesn't get hosed on the next Dirmaint upgrade. Or tell you that what you're trying to do isn't supported. (Maybe it involves some of the server exits?) With all of that in place to restrict who can issue DirMaint commands, we don't want to also have to have each privileged user respond with a password to use DirMaint. This is the specific issue you need to discuss with DirMaint support. It is possible that it is simply a result of switching from R4 command set to the R5 command set and will not occur again once all the NEEDPASS NOs have been issued. I'll leave it up to Jim to respond to If he would follow the documentation given with the product he is informed of everything he needs to know about. First he needs to take more of his blood pressure medicine. LOL! That statement didn't come out exactly the way Doug in Dirmaint Support intended it. He really meant that if you follow the book, all those extra files are handled for you rather than you having to configure them. Doug sends his apologies in advance, if his phrasing gives offense. He also asks that you open a PMR so he can figure out what your underlying problem is and address that, rather than getting sidetracked by tangential issues. Alan Altmark z/VM Development IBM Endicott
Re: dirm needpass no
I took a look at doc for 140CMDS and 150CMDS and now I see the Y or N called out for col 35. I overlooked that as I did the last time we upgraded DIRMAINT. Mark found it then as he did now. What I don't understand is what appears to be the fact that there are so many places in DIRMAINT, both the client side and the server side where authorization is granted. On the client side, there appear to be GLOBALV options that can be set and there is also the DIRM NEEDPASS NO or YES. On DIRMAINT, there is the Y or N in the 1x0CMDS DATADVH file but there is also the AUTHBY CONTROL file. The descriptions for all of them seem to be scattered in different manuals rather than having a section in the Tailoring and Admin. manual. That makes setup of DIRMAINT really messy as does many of the different configuration files. Jim Mark Bodenstein wrote: --=_277284843==.ALT Content-Type: text/plain; charset=us-ascii; format=flowed Jim is away in Texas and I'm here minding the shop. (Though he seems to be reading email, so I won't be surprised if he chimes in.) I checked the 140CMDS DATADVH and 150CMDS DATADVH files on the DIRMAINT 11F minidisk on our test VM LPAR which has DirMaint at the z/VM 5.3 level. These two files had mostly Y's in column 35 for the various commands, indicating that a password was required. In production (where we don't need to specify passwords) these two files have all N's in column 35. So I edited the files to specify N's in column 35, and restarted DIRMAINT. Voila! No passwords required. This is without doing anything with GLOBALV on the client side. I checked my GLOBALV files and didn't find NEEDPASS anywhere. Just to be sure I also checked the http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsl3b21/9.43z/VM 5.3 DirMainthttp://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsl3b21/9.43 Tailoring and Administration Guide. NEEDPASS is defined in Table 42 as a LASTING GLOBALV variable in pool DVH15 for possible use by DVHCX* and DVHPX* exits in the user's virtual machine (client side). There's no mention of the NEEDPASS global variable being used by anything other than being available for use by these exits. Mark Bodenstein ([EMAIL PROTECTED]) Cornell University At 10:57 AM 11/12/2007, Alan Altmark wrote: On Monday, 11/12/2007 at 08:19 EST, Phil Smith III [EMAIL PROTECTED] wrote: A. Harry Williams [EMAIL PROTECTED] wrote: No, he's talking about GLOBALV SELECT DVH15 SET NEEDPASS NO OK, I must have misunderstood part of the thread then. This is the setting I was referring to which, as your post goes on to note, doesn't work if done SOLELY on the client, because the server still wants a password. So, from the discussion here, I'm getting the idea that even though NEEDPASS NO is remaining set on the client side, upgrading the DIRMAINT server somehow causes it to forget its setting for that same client. And that necessitates yet another NEEDPASS NO. Do I have that right? Alan Altmark z/VM Development IBM Endicott --=_277284843==.ALT Content-Type: text/html; charset=us-ascii html body Jim is away in Texas and I'm here minding the shop.nbsp; (Though he seems to be reading email, so I won't be surprised if he chimes in.)brbr I checked the 140CMDS DATADVH and 150CMDS DATADVH files on the DIRMAINT 11F minidisk on our test VM LPAR which has DirMaint at the z/VM 5.3 level.nbsp; These two files had mostly Y's in column 35 for the various commands, indicating that a password was required.nbsp; In production (where we don't need to specify passwords) these two files have all N's in column 35.brbr So I edited the files to specify N's in column 35, and restarted DIRMAINT.nbsp; Voila!nbsp; No passwords required.brbr This is without doing anything with GLOBALV on the client side.nbsp; I checked my GLOBALV files and didn't find NEEDPASS anywhere.brbr Just to be sure I also checked the a href=http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsl3b21/9.43; z/a/VM 5.3 DirMainta href=http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/hcsl3b21/9.43; Tailoring and Administration Guide/a.nbsp; NEEDPASS is defined in Table 42 as a LASTING GLOBALV variable in pool DVH15 for possible use by DVHCX* and DVHPX* exits in the user's virtual machine (client side).nbsp; There's no mention of the NEEDPASS global variable being used by anything other than being available for use by these exits.brbr br Mark Bodensteinnbsp; ([EMAIL PROTECTED])br Cornell Universitybrbr At 10:57 AM 11/12/2007, Alan Altmark wrote:br blockquote type=cite class=cite cite=On Monday, 11/12/2007 at 08:19 EST, Phil Smith III lt;[EMAIL PROTECTED]gt; br wrote:br gt; quot;A. Harry Williamsquot; lt;[EMAIL PROTECTED]gt; wrote:br gt; gt;No, he's talking aboutbr gt; gt;GLOBALV SELECT DVH15 SET NEEDPASS NObr gt; br gt; OK, I must have misunderstood part of the thread
Re: dirm needpass no
A. Harry Williams [EMAIL PROTECTED] wrote: No, he's talking about GLOBALV SELECT DVH15 SET NEEDPASS NO OK, I must have misunderstood part of the thread then. This is the setting I was referring to which, as your post goes on to note, doesn't work if done SOLELY on the client, because the server still wants a password. ...phsiii
Re: dirm needpass no
Won't DIRMAINT BATCH do what you want fairly easily? Using XEDIT, create a file of DIRM FOR NEEDPASS NO commands for those users with this requirement (or nicety) and execute a DIRM BATCH fn ft fm command from MAINT. Ron Schmiedge [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@listserv.uark.edu 11/09/2007 04:23 PM Please respond to The IBM z/VM Operating System IBMVM@listserv.uark.edu To IBMVM@listserv.uark.edu cc Subject Re: dirm needpass no Jim, Couldn't you use the big hammer approach and update the needpass value for all your user admin people from someone who can, like MAINT? A list of the users combined with enough EXEC DIRMAINT commands in one exec, run it and go on to something else? I recall having to do that for a different option that changed changed its default value between DIRMAINT on VM/ESA and DIRMAINT on z/VM 4.4. Ron On 11/9/07, Jim Bohnsack [EMAIL PROTECTED] wrote: I'm still having problems with NEEDPASS. I have every id that acts as an admin to the directory or as a system support person listed as authorized for every DIRMAINT command in AUTHFOR CONTROL. I don't see Kris's connection in his posting re: the 1x0CMDS file. The authorization level required for each command is included in the AUTHFOR file for each user. I tried just editing the DVHOPT entry for an id that was included in AUTHFOR and changing the record to specify NPW0. Even after restarting DIRMAINT on that test system, I had to still enter the DIRM NEEDPASS NO on that id to be able to do a DIRM FOR /userid / GET. I would like to be able to switch to the z/VM 5.3 level of DIRMAINT without having to try to explain to the userid admin people that before that can do something to the directory, they have to issue the DIRM NEEDPASS NO command from their own userid. Jim
Re: dirm needpass no
On Monday, 11/12/2007 at 08:19 EST, Phil Smith III [EMAIL PROTECTED] wrote: A. Harry Williams [EMAIL PROTECTED] wrote: No, he's talking about GLOBALV SELECT DVH15 SET NEEDPASS NO OK, I must have misunderstood part of the thread then. This is the setting I was referring to which, as your post goes on to note, doesn't work if done SOLELY on the client, because the server still wants a password. So, from the discussion here, I'm getting the idea that even though NEEDPASS NO is remaining set on the client side, upgrading the DIRMAINT server somehow causes it to forget its setting for that same client. And that necessitates yet another NEEDPASS NO. Do I have that right? Alan Altmark z/VM Development IBM Endicott
Re: dirm needpass no
Les Geer (607-429-3580) [EMAIL PROTECTED] wrote: I believe there is a dirm globalv setting which removes the need, perhaps this is the command I am thinking of. It is a onetime event. I believe Les means: GLOBALV SELECT DVH15 SET PRESET password This has obvious security implications, but it does work. Setting the other GLOBALV (whose value I forget) just tells DIRMAINT EXEC not to prompt for a password, in which case nothing works, as the SVM still wants one. ...phsiii
Re: dirm needpass no
On Sun, 11 Nov 2007 10:52:20 -0500 Phil Smith III said: Les Geer (607-429-3580) [EMAIL PROTECTED] wrote: I believe there is a dirm globalv setting which removes the need, perhaps this is the command I am thinking of. It is a onetime event. I believe Les means: GLOBALV SELECT DVH15 SET PRESET password This has obvious security implications, but it does work. Setting the other GLOBALV (whose value I forget) just tells DIRMAINT EXEC not to prompt for a password, in which case nothing works, as the SVM still wants one. No, he's talking about GLOBALV SELECT DVH15 SET NEEDPASS NO Remember, this is pseudo-client server. The client (CMS user side) needs to know to not prompt for the password (hence the GLOBALV variable in the user side) and the server needs to know to not require a password (hence the NPW0 option) Sounds like Jim has done everything on the server side, now he needs to set the globalv variable in each of his admins accounts. There basically are two flags, that have two values each, giving a total of 4 states - 2 functioning correctly (Client-promptserver-prompt; client-nopromptserver-noprompt), 1 broken (client-nopromptserver-prompt) and 1 annoying (client-promptserver-noprompt). Jim sounds like he's in the annoying category. ...phsiii /ahw
Re: dirm needpass no
On Sunday, 11/11/2007 at 10:16 EST, A. Harry Williams [EMAIL PROTECTED] wrote: Jim sounds like he's in the annoying category. I've never thought of Jim as annoying, but if you say so ;-) Alan
Re: dirm needpass no
I'm still having problems with NEEDPASS. I have every id that acts as an admin to the directory or as a system support person listed as authorized for every DIRMAINT command in AUTHFOR CONTROL. I don't see Kris's connection in his posting re: the 1x0CMDS file. The authorization level required for each command is included in the AUTHFOR file for each user. I tried just editing the DVHOPT entry for an id that was included in AUTHFOR and changing the record to specify NPW0. Even after restarting DIRMAINT on that test system, I had to still enter the DIRM NEEDPASS NO on that id to be able to do a DIRM FOR /userid / GET. I would like to be able to switch to the z/VM 5.3 level of DIRMAINT without having to try to explain to the userid admin people that before that can do something to the directory, they have to issue the DIRM NEEDPASS NO command from their own userid. Jim Kris Buelens wrote: --=_Part_492_24364452.1194510562809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline For NEEDPASS, there was some relief in 2002. But, I still change the 1x0CMDS file. Below the converstaion I had with Mark Ritter on the subject. -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: dirm needpass no
Ron--I'd be happy to do that if it worked. I tried, however, from my id that DIRMAINT accepted, and issued the command DIRM FOR MAINT NEEDPASS NO and nothing happened. I would think that it should work, but that does not do the job. Jim Ron Schmiedge wrote: Jim, Couldn't you use the big hammer approach and update the needpass value for all your user admin people from someone who can, like MAINT? A list of the users combined with enough EXEC DIRMAINT commands in one exec, run it and go on to something else? I recall having to do that for a different option that changed changed its default value between DIRMAINT on VM/ESA and DIRMAINT on z/VM 4.4. Ron On 11/9/07, Jim Bohnsack [EMAIL PROTECTED] wrote: I'm still having problems with NEEDPASS. I have every id that acts as an admin to the directory or as a system support person listed as authorized for every DIRMAINT command in AUTHFOR CONTROL. I don't see Kris's connection in his posting re: the 1x0CMDS file. The authorization level required for each command is included in the AUTHFOR file for each user. I tried just editing the DVHOPT entry for an id that was included in AUTHFOR and changing the record to specify NPW0. Even after restarting DIRMAINT on that test system, I had to still enter the DIRM NEEDPASS NO on that id to be able to do a DIRM FOR /userid / GET. I would like to be able to switch to the z/VM 5.3 level of DIRMAINT without having to try to explain to the userid admin people that before that can do something to the directory, they have to issue the DIRM NEEDPASS NO command from their own userid. Jim -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: dirm needpass no
On Friday, 11/09/2007 at 03:50 EST, Jim Bohnsack [EMAIL PROTECTED] wrote: I would like to be able to switch to the z/VM 5.3 level of DIRMAINT without having to try to explain to the userid admin people that before that can do something to the directory, they have to issue the DIRM NEEDPASS NO command from their own userid. Have you called the Support Center? It may be a bug. Alan Altmark z/VM Development IBM Endicott
Re: dirm needpass no
For NEEDPASS, there was some relief in 2002. But, I still change the 1x0CMDS file. Below the converstaion I had with Mark Ritter on the subject. -- Kris Buelens, IBM Belgium, VM customer support 2007/11/8, Jim Bohnsack [EMAIL PROTECTED]: Everytime I install a new DIRMAINT (every 5 years of so), I have the same problem. I brought up the level that shipped with zVM 5.3 today on our production system and as soon as I entered a DIRM command, I was asked for my logon pw. I am in the AUTHUSER list and about everywhere else in DIRMAINT and the system that I can give myself authority. I solved the problem for that one DIRM command by entering the pw and then DIRM NEEDPASS NO. I don't want to have to explain to the half dozen or so people whose job it is to add mdisks and new users. What is the other command that I can use to globally allow everyone and then just depend on AUTHUSER? jim -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED] -- old conversation -- Subject: Re: NEEDPASS NO From: Mark Ritter - IBM DirMaint Support [EMAIL PROTECTED] Organization: W3 Pilot INN Servers Date: Wed, 27 Feb 2002 23:27:35 UTC References: 1 Hello, Kris. No, I don't think you've missed anything. You are correct; there is no NEEDPASS= entry in the CONFIG* DATADVH file(s). DEFAULT_USEROPTN= is indeed the place where this was implemented. Let's look at each one independently. LNK: Old values=1|0, default was 1 (ENABLE); requirement was to change to the safer default of 0 (DISABLE) for both new users and existing users. New values of 0|3 accomplish this. The 1 becomes invalid, changes to a zero; users who need LINK ENABLE must re-issue the command to change this option to 3. LOG: Old values=0|1; default was 0 (OFF); requirement was to change to the safer default of 1 (ON) for both new and existing users. New values of 1|2 do this. The 0 becomes invalid, changes to 1; users who need LOG OFF must re-issue the command to change this option to 2. NPW: Old values=1|0; default was 1 (YES). I know from experience that many customers have changed their 140CMDS and 150CMDS files to change each command from Y to N. I chose to allow flexability here just because it seemed like the right thing to do. This allows customer tailoring of the default for new users, without affecting existing users. There was no requirement in front of me to force a change for existing users. RCM: Old values=0|1|2; default was 1 (ON). There was no specific requirement involved here. I chose to allow flexability here just because it seemed like the right thing to do. This allows customer tailoring of the default for new users; without affecting existing users. I'm not aware of any customers changing this default. SMS: Old values=0|1; default was 0 (OFF). Again, there was no specific requirement involved here. I chose to allow flexability here just because it seemed like the right thing to do. This allows customer tailoring of the default for new users; without affecting existing users. I'm not aware of any customers changing this default. Making global changes to the *DVHOPT records isn't that difficult. The following commands will do it nicely: DIRM DISABLE DIRM BACKUP DIRM CMS PIPE (END ?) USER BACKUP G | A:FIND *DVHOPT_| CHANGE /NPW1/NPW0/ | B:FANINANY | USER INPUT E ?A:|B: where: (1) you have the authority to issue all of these commands (the default command set S will do them all), (2) the CMS PIPE command is entered all on one line and there is no blank between the _ and the | in the FIND stage, and (3) you are using the default filemodes of G for DIRMAINT's 1DB backup disk and E for DIRMAINT's 1DF directory source disk. Presuming that you get return code zero (DVHREQ2289I) for all three commands, then issue a DIRM BATCH command to submit the following: CMS ERASE USER DIRECT E RLDDATA (These two commands must be processed as a single batch file, or entered from DIRMAINT's console. If issued as separate DIRM commands, the DIRM RLDDATA will fail because the submitter's password is neither waived nor available for verification. If that happens, you'll have to log on to the DIRMAINT id to issue the RLDDATA command. :-) Then: DIRM ENABLE Regards; Mark Ritter - IBM DirMaint Support Mark Ritter/Endicott/[EMAIL PROTECTED] - [EMAIL PROTECTED] DirMaint Support - Dept G32G / Bldg 250-2 IBM Corporation - 1701 North Street - Endicott, NY 13760 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I was installing the new service for Dirmaint, and found this in VM62609 The single most common customization of the DirMaint product other than
dirm needpass no
Everytime I install a new DIRMAINT (every 5 years of so), I have the same problem. I brought up the level that shipped with zVM 5.3 today on our production system and as soon as I entered a DIRM command, I was asked for my logon pw. I am in the AUTHUSER list and about everywhere else in DIRMAINT and the system that I can give myself authority. I solved the problem for that one DIRM command by entering the pw and then DIRM NEEDPASS NO. I don't want to have to explain to the half dozen or so people whose job it is to add mdisks and new users. What is the other command that I can use to globally allow everyone and then just depend on AUTHUSER? jim -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
