Re: Simple RACF question re: LOGONBY & NOPASSWORD
On Tue, Mar 22, 2011 at 1:44 PM, Colin Allinson wrote: > Seems I am getting old and had forgotten that I had asked the self same > question before. You're probably going to ask that every 60 days until it's resolved :-)
Re: Simple RACF question re: LOGONBY & NOPASSWORD
Bruce Hayden wrote: > In the current releases (5.4 and 6.1), you'll need to generate a > periodic dummy activity on the userid to keep it alive. In a future > release, nopassword/nophrase users will not be revoked due to > inactivity. > Also, here is a couple of posts on this from a few years ago: > http://www.mail-archive.com/ibmvm@listserv.uark.edu/msg19233.html > http://www.mail-archive.com/ibmvm@listserv.uark.edu/msg19239.html Seems I am getting old and had forgotten that I had asked the self same question before. Thanks Bruce and Alan - sorry for my senility. With best regards / mit freundlichen Grüßen, Colin Allinson VM Systems Support Amadeus Data Processing GmbH
Re: Simple RACF question re: LOGONBY & NOPASSWORD
No, NOPASSWORD will not stop revocation for inactivity. For that you need the z/OS-inspired PROTECTED attribute. IBM is aware of the requirement. Regards, Alan Altmark IBM Lab Services - Sent from my BlackBerry Handheld.
Re: Simple RACF question re: LOGONBY & NOPASSWORD
In the current releases (5.4 and 6.1), you'll need to generate a periodic dummy activity on the userid to keep it alive. In a future release, nopassword/nophrase users will not be revoked due to inactivity. Also, here is a couple of posts on this from a few years ago: http://www.mail-archive.com/ibmvm@listserv.uark.edu/msg19233.html http://www.mail-archive.com/ibmvm@listserv.uark.edu/msg19239.html On Tue, Mar 22, 2011 at 5:09 AM, Colin Allinson wrote: > We have a number of userids that are only used with logonby. > > I am aware that, if I set these up as NOPASSWORD, this prevents them getting > revoked as a result of someone erroneously trying to log on directly. > However, historically, we have not had this problem and these userids have > not been set up this way. > > We now have a different situation where one of these userids is only used > once per quarter and this breaks the installation rule of revoke after 60 > days of no use. > > Will NOPASSWORD also protect against this or do I have to generate a > periodic dummy activity on this userid to keep it alive. > > > With best regards / mit freundlichen Grüßen, > > Colin Allinson > VM Systems Support > Amadeus Data Processing GmbH > -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
Simple RACF question re: LOGONBY & NOPASSWORD
We have a number of userids that are only used with logonby. I am aware that, if I set these up as NOPASSWORD, this prevents them getting revoked as a result of someone erroneously trying to log on directly. However, historically, we have not had this problem and these userids have not been set up this way. We now have a different situation where one of these userids is only used once per quarter and this breaks the installation rule of revoke after 60 days of no use. Will NOPASSWORD also protect against this or do I have to generate a periodic dummy activity on this userid to keep it alive. With best regards / mit freundlichen Grüßen, Colin Allinson VM Systems Support Amadeus Data Processing GmbH
Re: LOGONBY 8 user limitation
Hi Dave, We have 15 users shared to be used for support purpose and a great number of users sharing them. You can define a GROUP and CONNECT those users to them. Abraços / Best regards Edi Lopes Alves IBM Global Accounts (IGA) z/VM Systems Base, Vicom & Program Products Support ITIL Foundation Certified IBM Certified 424 zSeries Specialist IBM Certified 442 Content Manager IBM Certified 437 Websphere Portal ITN 5750-2054 - External phone: +5511 9618-2946 Location: IBM Hortolândia - São Paulo - Brazil From: Dave Keeton To: IBMVM@LISTSERV.UARK.EDU Date: 10/06/2009 14:44 Subject: LOGONBY 8 user limitation I'm trying to determine if RACF will allow me to bypass the 8 user limitation imposed with the LOGONBY attribute of the USER DIRECT entry. I need to add operations staff to a virtual machine so they can respond to messages and other tasks. I need to allow 16 users, so I'm trying to figure out how to accomplish this. Thanks, Dave
Re: LOGONBY 8 user limitation
Thanks, makes a lot of sense, I'll pass that on to our RACF admin. > -Original Message- > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > Behalf Of Rob van der Heij > Sent: Wednesday, June 10, 2009 3:31 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: LOGONBY 8 user limitation > > On Wed, Jun 10, 2009 at 9:08 PM, Romanowski, John > (OFT) wrote: > > > PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF1) ACCESS(READ) > > Do yourself a favor and connect the various individuals to RACF groups > and then permit these groups to the logonby profiles. Even when you > have several people with different roles, the number of groups is > probably pretty small. Doing so will make your life easier when people > change roles in your shop. > And it avoids the trouble when you want to delete a user and can't > find the profile where he's still on the access list. > > -Rob This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
Re: LOGONBY 8 user limitation
Thanks to Rob & everyone else who responded. I'm pretty new to RACF as well, so your examples helped out a lot. Regards, Dave -Original Message- From: Rob van der Heij Reply-to: The IBM z/VM Operating System To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY 8 user limitation Date: Wed, 10 Jun 2009 21:30:38 +0200 On Wed, Jun 10, 2009 at 9:08 PM, Romanowski, John (OFT) wrote: > PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF1) ACCESS(READ) Do yourself a favor and connect the various individuals to RACF groups and then permit these groups to the logonby profiles. Even when you have several people with different roles, the number of groups is probably pretty small. Doing so will make your life easier when people change roles in your shop. And it avoids the trouble when you want to delete a user and can't find the profile where he's still on the access list. -Rob
Re: LOGONBY 8 user limitation
Dave, Using RACF you can have hundreds of logonby users, or you can group users and authorize those groups to do logonby to a server. We normally have a racf group for the system programmers, and grant that racf group access to the logonby profiles for the server userids. A similar setup is used for instance for the operators, they are authorized for OPERATOR and a few other operator userids. By doing this, it is very easy to maintain the list of operators, VM system programmers, Linux system programmers and so on. When somebody joins or leaves such a group, all you need is to connect/remove the personal userid to/from the maintenance user groups. Ronald van der Laan
Re: LOGONBY 8 user limitation
On Wed, Jun 10, 2009 at 9:08 PM, Romanowski, John (OFT) wrote: > PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF1) ACCESS(READ) Do yourself a favor and connect the various individuals to RACF groups and then permit these groups to the logonby profiles. Even when you have several people with different roles, the number of groups is probably pretty small. Doing so will make your life easier when people change roles in your shop. And it avoids the trouble when you want to delete a user and can't find the profile where he's still on the access list. -Rob
Re: LOGONBY 8 user limitation
On Wednesday, 06/10/2009 at 02:16 EDT, Dave Keeton wrote: > I'm trying to determine if RACF will allow me to bypass the 8 user limitation > imposed with the LOGONBY attribute of the USER DIRECT entry. I need to add > operations staff to a virtual machine so they can respond to messages and other > tasks. I need to allow 16 users, so I'm trying to figure out how to accomplish > this. Yes, RACF will allow you to exceed the CP-imposed limitation in the directory. Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY 8 user limitation
Yes, this will work in RACF: If using RACF, when you define the user as LOGONBY, it can by default no longer be logged on to with its own password (what is normally what you'd want). But, with an extra command you can restore that possibility: 1. Define TERRY as LOGONBY RAC RDEFINE SURROGAT LOGONBY.TERRY UACC(NONE) 2. Reset the PERMIT RACF created for the command issuer RAC PERMIT LOGONBY.TERRY CLASS(SURROGAT) RESET 3. Allow users/groups to use this LOGONBY to TERRY RAC PERMIT LOGONBY.TERRY CLASS(SURROGAT) ID(user/group) ACCESS(READ) 4. (optional) Make it possible to logon to TERRY with its own password RAC PERMIT LOGONBY.TERRY CLASS(SURROGAT) ID(TERRY) ACCESS(ALTER) Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov <mailto:terry.mar...@cms.hhs.gov> From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Wednesday, June 10, 2009 2:21 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY 8 user limitation If you were using VM:Secure, you would do it via the Rules Facility. Is there anything equivalent in RACF? Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Keeton Sent: Wednesday, June 10, 2009 9:52 AM To: IBMVM@LISTSERV.UARK.EDU Subject: LOGONBY 8 user limitation I'm trying to determine if RACF will allow me to bypass the 8 user limitation imposed with the LOGONBY attribute of the USER DIRECT entry. I need to add operations staff to a virtual machine so they can respond to messages and other tasks. I need to allow 16 users, so I'm trying to figure out how to accomplish this. Thanks, Dave
Re: LOGONBY 8 user limitation
RACF doesn't have a limit on the number of surrogate users that can use the 'by' option of logon. On Wed, Jun 10, 2009 at 12:52 PM, Dave Keeton wrote: > I'm trying to determine if RACF will allow me to bypass the 8 user > limitation imposed with the LOGONBY attribute of the USER DIRECT entry. I > need to add operations staff to a virtual machine so they can respond to > messages and other tasks. I need to allow 16 users, so I'm trying to figure > out how to accomplish this. > > Thanks, > Dave > > -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: LOGONBY 8 user limitation
RACF lets you define as many LOGONBY users for a target userid as you like. RDEFINE SURROGAT LOGONBY.PERFSVM UACC(NONE) and here we permit the staff to doLOGON PERFSVM BY staffx at z/VM logon screen: PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF1) ACCESS(READ) PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF2) ACCESS(READ) PERMIT LOGONBY.PERFSVM CLASS(SURROGAT) ID(STAFF3) ACCESS(READ) From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Keeton Sent: Wednesday, June 10, 2009 12:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: LOGONBY 8 user limitation I'm trying to determine if RACF will allow me to bypass the 8 user limitation imposed with the LOGONBY attribute of the USER DIRECT entry. I need to add operations staff to a virtual machine so they can respond to messages and other tasks. I need to allow 16 users, so I'm trying to figure out how to accomplish this. Thanks, Dave This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
Re: LOGONBY 8 user limitation
If you were using VM:Secure, you would do it via the Rules Facility. Is there anything equivalent in RACF? Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Keeton Sent: Wednesday, June 10, 2009 9:52 AM To: IBMVM@LISTSERV.UARK.EDU Subject: LOGONBY 8 user limitation I'm trying to determine if RACF will allow me to bypass the 8 user limitation imposed with the LOGONBY attribute of the USER DIRECT entry. I need to add operations staff to a virtual machine so they can respond to messages and other tasks. I need to allow 16 users, so I'm trying to figure out how to accomplish this. Thanks, Dave
Re: LOGONBY and FTP
Thanks Alan. In the interest of good citizenship I'll open a Sev 3 PMR. Regarding NOPASSWORD, we do typically use that for SVMs, etc. Not this time because of what I was testing. Mark At 11:32 AM 6/10/2009, Alan Altmark wrote: FTP logon allows users in the ACL to use "testuser.by.surrogate" to log on to TESTUSER as expected, but DOES allow TESTUSER to logon directly. This is a surprise. Bug, or feature? Bug. Feel free to open a PMR. If you want to stop authentication using TESTUSER, remove its password (ALTUSER TESTUSER NOPASSWORD). Then it can't be used as an authenticator in ANY interface (including RACROUTE REQUEST=VERIFY), it can never be revoked due to invalid password attempts, and isn't subject to password expiry rules. This effectively turns it into AUTOONLY without having to mess with the directory. Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY and FTP (was: A Strange Use Of AUTOLOG)
On Wednesday, 06/10/2009 at 10:54 EDT, Mark Bodenstein wrote: > RACF profile SURROGAT LOGONBY.TESTUSER exists, with the ACL not including > TESTUSER itself. > ... > FTP logon allows users in the ACL to use "testuser.by.surrogate" to log on > to TESTUSER as expected, but DOES allow TESTUSER to logon directly. This > is a surprise. > > Bug, or feature? Bug. Feel free to open a PMR. If you want to stop authentication using TESTUSER, remove its password (ALTUSER TESTUSER NOPASSWORD). Then it can't be used as an authenticator in ANY interface (including RACROUTE REQUEST=VERIFY), it can never be revoked due to invalid password attempts, and isn't subject to password expiry rules. This effectively turns it into AUTOONLY without having to mess with the directory. Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY - limit of 8 userids.
On Tuesday, 11/25/2008 at 03:50 EST, Rob van der Heij <[EMAIL PROTECTED]> wrote: > On Tue, Nov 25, 2008 at 5:40 PM, Alan Altmark <[EMAIL PROTECTED]> wrote: > > > 2. Create a list of target of target IDs so that you can change the list > > of target IDs without have to do PERMITs. > > How's that with RACF ? You can't group the targets unless they are so > similar that a generic profile does it? Through the use of a RACFVARS profile. You can use it when the resource names don't have a pattern and there is no grouping profile (such as GTERMINAL). >From the new example on pp. 71-72 in the RACF 5.4 Security Admin Guide, pp 71-72: * Allow generic profiles to be defined for SURROGAT class SETROPTS GENERIC(SURROGAT) * Define variable &MNTIDS to contain list of users for whom LOGON BY is required RDEFINE RACFVARS &MNTIDS ADDMEM(MAINT TCPMAINT RSCS PERFSVM) * Create the generic profile. RDEFINE SURROGAT LOGONBY.&MNTIDS UACC(NONE) * Give all users in SYSPROGS group LOGON BY authority to maintenence ids PERMIT LOGONBY.&MNTIDS CL(SURROGAT) ID(SYSPROGS) ACCESS(READ) * Turn on SURROGAT and RACFVARS class processing SETROPTS CLASSACT(SURROGAT RACFVARS) * Cache the resource definitions in memory * Add REFRESH if already active SETROPTS RACLIST(SURROGAT RACFVARS) To change the list: * Use ADDMEM or DELMEM RALTER RACFVARS &MNTIDS ADDMEM(TCPIP) * Refresh the in-memory cache SETROPTS RACLIST(RACFVARS) REFRESH Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY - limit of 8 userids.
On Tue, Nov 25, 2008 at 5:40 PM, Alan Altmark <[EMAIL PROTECTED]> wrote: > 2. Create a list of target of target IDs so that you can change the list > of target IDs without have to do PERMITs. How's that with RACF ? You can't group the targets unless they are so similar that a generic profile does it? Rob
Re: LOGONBY - limit of 8 userids.
On Tuesday, 11/25/2008 at 10:54 EST, Thomas Kern <[EMAIL PROTECTED]> wrote: > Since changes are a'coming > > I like the idea of a new DIRMAINT/ESM authorization > LGNBYGRP acigname1 acigname2 ... I meant that changes in the ACI itself are coming that will require more changes to more things in the CP-resident code. But I have to respond to your request as "Available". RACF lets you: 1. Create a group of users. Permit the group to use LOGON BY to the desired set of target IDs. As you change the group membership, their ability to LOGON BY to all those target IDs changes. 2. Create a list of target of target IDs so that you can change the list of target IDs without have to do PERMITs. 3. Use both. Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY - limit of 8 userids.
On Tue, Nov 25, 2008 at 4:53 PM, Thomas Kern <[EMAIL PROTECTED]> wrote: > Since changes are a'coming With Alan that's a threat, not a promise of desirable change. And certainly not that you can pick you favorite change ;-) Rob
Re: LOGONBY - limit of 8 userids.
On Nov 25, 2008, at 9:43 AM, Alan Altmark wrote: 2) they must change as CP changes. [free advice: changes are a- comin', rollin' 'round the bend.] Should we be using "Folsom Prison Blues" or Dylan's "Slow Train" as our model? Adam
Re: LOGONBY - limit of 8 userids.
Since changes are a'coming I like the idea of a new DIRMAINT/ESM authorization LGNBYGRP acigname1 acigname2 ... /Tom Kern Alan Altmark wrote: > That wouldn't work. The exit is called after the LOGON command has been > parsed, but before LOGON has actually begun. No passwords validated and > no LOGON BY permissions have been determined yet. > > Shimon's patch to HCPRPI (where ESMs are born) is the only solution I see, > but HCPRPI mods are inherently dangerous. > 1) They ARE the security subsystem. > 2) they must change as CP changes. [free advice: changes are a-comin', > rollin' 'round the bend.] > 3) You need HLASM > > Buy an ESM or forget it. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: LOGONBY - limit of 8 userids.
On Tuesday, 11/25/2008 at 07:52 EST, "Wakser, David" <[EMAIL PROTECTED]> wrote: > Unless I am misreading things, wouldn't CP Exit 1101: Logon > Post-Parse Processing do exactly what he needs? He would have a list of > acceptable users in the exit, if it is any of them, he would change the > return code. Sound too simple? That wouldn't work. The exit is called after the LOGON command has been parsed, but before LOGON has actually begun. No passwords validated and no LOGON BY permissions have been determined yet. Shimon's patch to HCPRPI (where ESMs are born) is the only solution I see, but HCPRPI mods are inherently dangerous. 1) They ARE the security subsystem. 2) they must change as CP changes. [free advice: changes are a-comin', rollin' 'round the bend.] 3) You need HLASM Buy an ESM or forget it. Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY - limit of 8 userids.
On Tue, Nov 25, 2008 at 7:37 AM, Shimon Lebowitz <[EMAIL PROTECTED]> wrote: > I once wrote a local mod to HCPRPI or whatever (I am at home > now) which allowed LOGONBY to a non-ESM system we have, based > on the ACIGROUP of the logging on user. The acceptable > ACIGROUPS were hardcoded in the mod, so you might not be > happy with my choices ;-) but if you want the code I can > share it without the boatload of money. I think ACIGROUP is a neat trick. Would you not simply want the ACIGROUP to be in the list as if it were a user? And if you don't have the requirements that justify an ESM, it might also be an idea to assign one privilege class a "free for all" to logonby to any user (since they can autolog and secuser already anyway). Rob
Re: LOGONBY - limit of 8 userids.
You probably know this, but I think that¹s a compelling argument for a ESM and using ESM groups to manage LOGONBY authorization. It¹s going to be a lot cheaper to get VM:Secure (dir mgmt and ESM all in one) than to hack something up yourself. Use DIRM/RACF if you must, but buy it rather than build it. On 11/24/08 7:58 PM, "David Kreuter" <[EMAIL PROTECTED]> wrote: > The LOGONBY statement in the directory is limited to 8 users. I have a client > that wants to have, say, 16 in the list. > The system is fairly knuckle scraping, i.e., no RACF, DIRMAINT, products, etc. > This isn't helping, as if DIRMAINT was there we could do a dynamic directory > update. > > I have thought of a command exit, or even a class C or E service machine that > zaps storage. But I'm too old for zapping storage ... > ... at least in production systems. > > Any ideas? > Thanks. > David Kreuter >
Re: LOGONBY - limit of 8 userids.
Alan: Unless I am misreading things, wouldn't CP Exit 1101: Logon Post-Parse Processing do exactly what he needs? He would have a list of acceptable users in the exit, if it is any of them, he would change the return code. Sound too simple? David Wakser -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, November 24, 2008 9:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY - limit of 8 userids. On Monday, 11/24/2008 at 08:01 EST, David Kreuter <[EMAIL PROTECTED]> wrote: > The LOGONBY statement in the directory is limited to 8 users. I have > a client > that wants to have, say, 16 in the list. > The system is fairly knuckle scraping, i.e., no RACF, DIRMAINT, products, > etc. This isn't helping, as if DIRMAINT was there we could do a dynamic > directory update. > > I have thought of a command exit, or even a class C or E service machine that > zaps storage. But I'm too old for zapping storage ... > ... at least in production systems. > > Any ideas? The limit's not in CP code, but in the object directory. That's something that isn't changed trivially, requiring you to recompile any part of the system that references the directory. Good news: I think the code that abends the system doesn't reference the directory. That's, like, two modules you don't have to compile! :-) You'll have to drop back to your client's security policy for guidance. Security is not free, so if they MUST have LOGON BY with more than 8 byusers, then they MUST purchase an ESM. Of course, you could write an ESM for them, but that will cost them a boatload of money and take a while to complete, not to mention the ongoing cost of your support. Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY - limit of 8 userids.
I once wrote a local mod to HCPRPI or whatever (I am at home now) which allowed LOGONBY to a non-ESM system we have, based on the ACIGROUP of the logging on user. The acceptable ACIGROUPS were hardcoded in the mod, so you might not be happy with my choices ;-) but if you want the code I can share it without the boatload of money. Shimon Original message >Of course, you could write an >ESM for them, but that will cost them a boatload of money and take a while >to complete, not to mention the ongoing cost of your support. >
Re: LOGONBY - limit of 8 userids.
On Monday, 11/24/2008 at 11:32 EST, Mike Walter <[EMAIL PROTECTED]> wrote: > OTOH, completely outside the box, you could write a CMS that would allow one of > the authorized users, from their ID to contact (maybe SMSG) a server that has > access to the USER DIRECT, check that the target userid is not already logged > on, change one of the LOGONBY IDs in the USER DIRECT to their userid, run > DIRECTXA, then CP MSG them to go ahead with LOGONBY. > > It could be made more complex (change MAINT 2CC MDISK to RR, have the server > dynamically LINK/DET the MAINT 2CC as needed, etc.), but that's a start. Much > more cumbersome, and less sophisticated than a ISV's ESM, but much less > expensive, too. You get what you pay for. Given that the system in question: - Has no requirement for encrypted passwords - Has no requirement to change the password on a specified interval - Has no quality checks on the password - Has no audit requirement, I don't think I'd worry *too* much about LOGON BY. (If they have 16 people needing to share the logon, something is probably wrong.) Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY - limit of 8 userids.
OTOH, completely outside the box, you could write a CMS that would allow one of the authorized users, from their ID to contact (maybe SMSG) a server that has access to the USER DIRECT, check that the target userid is not already logged on, change one of the LOGONBY IDs in the USER DIRECT to their userid, run DIRECTXA, then CP MSG them to go ahead with LOGONBY. It could be made more complex (change MAINT 2CC MDISK to RR, have the server dynamically LINK/DET the MAINT 2CC as needed, etc.), but that's a start. Much more cumbersome, and less sophisticated than a ISV's ESM, but much less expensive, too. Mike Walter Hewitt Associates - Original Message - From: "Alan Altmark" [EMAIL PROTECTED] Sent: 11/24/2008 09:53 PM EST To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY - limit of 8 userids. On Monday, 11/24/2008 at 08:01 EST, David Kreuter <[EMAIL PROTECTED]> wrote: > The LOGONBY statement in the directory is limited to 8 users. I have a client > that wants to have, say, 16 in the list. > The system is fairly knuckle scraping, i.e., no RACF, DIRMAINT, products, > etc. This isn't helping, as if DIRMAINT was there we could do a dynamic > directory update. > > I have thought of a command exit, or even a class C or E service machine that > zaps storage. But I'm too old for zapping storage ... > ... at least in production systems. > > Any ideas? The limit's not in CP code, but in the object directory. That's something that isn't changed trivially, requiring you to recompile any part of the system that references the directory. Good news: I think the code that abends the system doesn't reference the directory. That's, like, two modules you don't have to compile! :-) You'll have to drop back to your client's security policy for guidance. Security is not free, so if they MUST have LOGON BY with more than 8 byusers, then they MUST purchase an ESM. Of course, you could write an ESM for them, but that will cost them a boatload of money and take a while to complete, not to mention the ongoing cost of your support. Alan Altmark z/VM Development IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: LOGONBY - limit of 8 userids.
On Monday, 11/24/2008 at 08:01 EST, David Kreuter <[EMAIL PROTECTED]> wrote: > The LOGONBY statement in the directory is limited to 8 users. I have a client > that wants to have, say, 16 in the list. > The system is fairly knuckle scraping, i.e., no RACF, DIRMAINT, products, > etc. This isn't helping, as if DIRMAINT was there we could do a dynamic > directory update. > > I have thought of a command exit, or even a class C or E service machine that > zaps storage. But I'm too old for zapping storage ... > ... at least in production systems. > > Any ideas? The limit's not in CP code, but in the object directory. That's something that isn't changed trivially, requiring you to recompile any part of the system that references the directory. Good news: I think the code that abends the system doesn't reference the directory. That's, like, two modules you don't have to compile! :-) You'll have to drop back to your client's security policy for guidance. Security is not free, so if they MUST have LOGON BY with more than 8 byusers, then they MUST purchase an ESM. Of course, you could write an ESM for them, but that will cost them a boatload of money and take a while to complete, not to mention the ongoing cost of your support. Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY - limit of 8 userids.
David, You didn't say anything about the userid that they're trying to log on to. If all they need are some privileges that you don't want to grant to their personal userids, can you have two, with eight LOGONBY users on each, e.g. MAINT1 and MAINT2? Obviously, that won't work for some things. Assuming spending money on RACF, VM:Secure, or even DIRMAINT is out, the other option is to give up on LOGONBY, and store the password somewhere where they can all find it. A minidisk that's directory linked to their personal userids would be best. They can log on to their own userid, look up the password, then log on to the target userid. If security policies prevent password sharing, the client will have to decide if the policy is important enough to warrant spending money to comply with it. Dennis "Until and unless you discover that money is the root of all good, you ask for your own destruction. When money ceases to be the tool by which men deal with one another, then men become the tools of men. Blood, whips and guns - or dollars. Take your choice - there is no other - and your time is running out." -- Ayn Rand From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Monday, November 24, 2008 16:59 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] LOGONBY - limit of 8 userids. The LOGONBY statement in the directory is limited to 8 users. I have a client that wants to have, say, 16 in the list. The system is fairly knuckle scraping, i.e., no RACF, DIRMAINT, products, etc. This isn't helping, as if DIRMAINT was there we could do a dynamic directory update. I have thought of a command exit, or even a class C or E service machine that zaps storage. But I'm too old for zapping storage ... ... at least in production systems. Any ideas? Thanks. David Kreuter
Re: LOGONBY
One slight correction. It was called PIE-VM/Sessions. There were also PIE-CICS/Sessions and PIE-TSO/Sessions (PIE = Productivity Integrated Environment; TSC = Technologic Software Concepts, Inc.). TSC already had session managers for CICS and TSO when they bought Amdahl's product. They tried to combine the them without hiring anyone who knew anything about VM. Their only real success in the integration effort was in the naming of the products. TSC sold all of its legacy software products to Unicom Systems. It was a sad day when Amdahl decided to not sell Sessions to Kolinar, where it would have been properly supported. Even when TSC was supporting Sessions, they weren't, they were just collecting rent. Having known and worked with the developers of Sessions, I never did call it PIE after it was sold. (Maybe that is why problems we reported were never fixed.) Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter > Sent: Wednesday, September 24, 2008 7:56 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: LOGONBY > > David, > > Aside from a test, I never installed Arty's "Session". For > years we had from Technologic Software Concepts a product > called PIE-Sessions/VM, which was Amdahl's "Sessions" tool > (an outstanding LDEV manager - the server for which one > DIALed into before logon, as in 'DIAL PIE'). TSC utterly > abandoned that product at Y2K, and then 3270 emulators pretty > much took > over the show. TSC is long gone, although a subset of their other > products appear to have been bought by others (might have > been a good VMSHARE topic: "MEMO SOLDOUT").
Re: TNVT100 (was Re: LOGONBY)
> OK, I'll "byte". Is the most current TNVT100 located by google at: > http://ukcc.uky.edu/~tools/1997 > Or is a newer one located somewhere beyond google's wide vision? That's the version I have. I don't think Arty's done anything to it in a very long while. Emacs on a 3270 is a very strange experience. -- db
Re: TNVT100 (was Re: LOGONBY)
On Wed, 24 Sep 2008 10:25:47 -0500 Mike Walter said: >OK, I'll "byte". Is the most current TNVT100 located by google at: >http://ukcc.uky.edu/~tools/1997 >Or is a newer one located somewhere beyond google's wide vision? > There have been minor tweaks since 1997. Cheers, Arty
TNVT100 (was Re: LOGONBY)
OK, I'll "byte". Is the most current TNVT100 located by google at: http://ukcc.uky.edu/~tools/1997 Or is a newer one located somewhere beyond google's wide vision? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "David Boyes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 09/23/2008 07:37 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: LOGONBY On 9/23/08 5:58 PM, "Martin, Terry R. (CMS/CTR) (CTR)" <[EMAIL PROTECTED]> wrote: > Hi > > One last thing on this. Am I logged on with my user id and password then > from there logonby to another machine such as MAINT? Or do I just logon > to MAINT using LOGONBY with my personal user id's password? The latter, although if you have RACF or a similar ESM, you can force the other behavior by limiting the pattern of logical terminals that certain IDs can be used from, and installing a copy of the super-fabulous SESSION tool available from most collections of useful VM tools. No system should be without it (or TNVT100). SESSION lets you create essentially a poor-mans session manager from a CMS session. Good for environments that force you to logon as you first. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: LOGONBY
David, Aside from a test, I never installed Arty's "Session". For years we had from Technologic Software Concepts a product called PIE-Sessions/VM, which was Amdahl's "Sessions" tool (an outstanding LDEV manager - the server for which one DIALed into before logon, as in 'DIAL PIE'). TSC utterly abandoned that product at Y2K, and then 3270 emulators pretty much took over the show. TSC is long gone, although a subset of their other products appear to have been bought by others (might have been a good VMSHARE topic: "MEMO SOLDOUT"). I did install and still run YVETTE, bit can't remember the last time anyone actually dialed to it. Again, 3270 emulators stole the show. Why didn't I mention any them? Aside from forgetting them, because the original question was asked by someone unfamiliar with the basics of LOGONBY. Adding a session manager would definitely cloud the issue. They are not part of the CP or CMS deliverables. First: learn the basics. Then, only after those are firmly understood: "Add complexity for productivity". Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "David Boyes" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 09/23/2008 07:40 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: LOGONBY On 9/23/08 6:14 PM, "Mike Walter" <[EMAIL PROTECTED]> wrote: > No, you cannot logon to one userid when logged onto another. Mike! What happened to your copy of SESSION? Native CP can't do it, but you certainly can use SESSION or YVETTE or NV/AS or PVM to get multiple login sessions from a single terminal. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: LOGONBY
On 9/23/08 6:14 PM, "Mike Walter" <[EMAIL PROTECTED]> wrote: > No, you cannot logon to one userid when logged onto another. Mike! What happened to your copy of SESSION? Native CP can't do it, but you certainly can use SESSION or YVETTE or NV/AS or PVM to get multiple login sessions from a single terminal.
Re: LOGONBY
On 9/23/08 5:58 PM, "Martin, Terry R. (CMS/CTR) (CTR)" <[EMAIL PROTECTED]> wrote: > Hi > > One last thing on this. Am I logged on with my user id and password then > from there logonby to another machine such as MAINT? Or do I just logon > to MAINT using LOGONBY with my personal user id's password? The latter, although if you have RACF or a similar ESM, you can force the other behavior by limiting the pattern of logical terminals that certain IDs can be used from, and installing a copy of the super-fabulous SESSION tool available from most collections of useful VM tools. No system should be without it (or TNVT100). SESSION lets you create essentially a poor-mans session manager from a CMS session. Good for environments that force you to logon as you first.
Re: LOGONBY
Geez. 28 years. Now I really feel officially ancient. Thanks a lot, dude. On 9/23/08 5:44 PM, "Dave Wade" <[EMAIL PROTECTED]> wrote: > David Boyes wrote: > A very long time... > http://vm.marist.edu/~vmshare/browse?fn=DMKLOG&ft=MEMO > http://vm.marist.edu/~vmshare/browse?fn=NOPSWD&ft=NOTE
Re: LOGONBY
Just to clarify -- you can be logged on to your own userid if you like.. just bring up another session and logonby to maint with your userid/pw. Just want to be sure you understand that being logged on to your own userid has no bearing at all on being able to logonby to another userid... Scott Rohling On Tue, Sep 23, 2008 at 4:14 PM, Martin, Terry R. (CMS/CTR) (CTR) < [EMAIL PROTECTED]> wrote: > Thanks Scott > > > > *Thank You,* > > > > *Terry Martin*** > > *Lockheed Martin - Information Technology*** > > *z/OS & z/VM Systems - Performance and Tuning*** > > *Cell - 443 632-4191*** > > *Work - 410 786-0386*** > > [EMAIL PROTECTED] > -- > > *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On > Behalf Of *Scott Rohling > *Sent:* Tuesday, September 23, 2008 6:12 PM > > *To:* IBMVM@LISTSERV.UARK.EDU > *Subject:* Re: LOGONBY > > > > Just logon to MAINT using LOGONBY with your personal userid/pw > > Scott Rohling > > On Tue, Sep 23, 2008 at 3:58 PM, Martin, Terry R. (CMS/CTR) (CTR) < > [EMAIL PROTECTED]> wrote: > > Hi > > One last thing on this. Am I logged on with my user id and password then > from there logonby to another machine such as MAINT? Or do I just logon > to MAINT using LOGONBY with my personal user id's password? > > Thank You, > > Terry Martin > Lockheed Martin - Information Technology > z/OS & z/VM Systems - Performance and Tuning > Cell - 443 632-4191 > Work - 410 786-0386 > [EMAIL PROTECTED] > > > -Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > > Behalf Of Rob van der Heij > Sent: Tuesday, September 23, 2008 5:51 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: LOGONBY > > On Tue, Sep 23, 2008 at 8:35 PM, O'Brien, Dennis L > > > wrote: > > > Be careful about what "*no* password" means. Rob is talking about > RACF. > > The directory allows a password of NOPASS, which might seem to be the > > obvious thing if you don't read the manual. NOPASS actually allows > > anyone to log on without specifying a password. If using VM:Secure or > > no ESM, specify a password of LBYONLY. > > Thank you :-) I was indeed thinking RACF only. A lot of this becomes > a moot point when you have passwords in plain text... > > Rob > > >
Re: LOGONBY
Your id need not be logged on. You can logon to more than one id using logonby. When I am testing tools for our TPF testers, I frequently have up to 6 concurrent ids that I have logged on via logonby. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Terry > R. (CMS/CTR) (CTR) > Sent: Tuesday, September 23, 2008 2:58 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: LOGONBY > > Hi > > One last thing on this. Am I logged on with my user id and > password then from there logonby to another machine such as > MAINT? Or do I just logon to MAINT using LOGONBY with my > personal user id's password? > > Thank You, > > Terry Martin > Lockheed Martin - Information Technology z/OS & z/VM Systems > - Performance and Tuning Cell - 443 632-4191 Work - 410 > 786-0386 [EMAIL PROTECTED] > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij > Sent: Tuesday, September 23, 2008 5:51 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: LOGONBY > > On Tue, Sep 23, 2008 at 8:35 PM, O'Brien, Dennis L > wrote: > > > Be careful about what "*no* password" means. Rob is talking about > RACF. > > The directory allows a password of NOPASS, which might seem > to be the > > obvious thing if you don't read the manual. NOPASS actually allows > > anyone to log on without specifying a password. If using > VM:Secure or > > no ESM, specify a password of LBYONLY. > > Thank you :-) I was indeed thinking RACF only. A lot of > this becomes a moot point when you have passwords in plain text... > > Rob >
Re: LOGONBY
Thanks Scott Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Scott Rohling Sent: Tuesday, September 23, 2008 6:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY Just logon to MAINT using LOGONBY with your personal userid/pw Scott Rohling On Tue, Sep 23, 2008 at 3:58 PM, Martin, Terry R. (CMS/CTR) (CTR) <[EMAIL PROTECTED]> wrote: Hi One last thing on this. Am I logged on with my user id and password then from there logonby to another machine such as MAINT? Or do I just logon to MAINT using LOGONBY with my personal user id's password? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Tuesday, September 23, 2008 5:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY On Tue, Sep 23, 2008 at 8:35 PM, O'Brien, Dennis L mailto:[EMAIL PROTECTED]> > wrote: > Be careful about what "*no* password" means. Rob is talking about RACF. > The directory allows a password of NOPASS, which might seem to be the > obvious thing if you don't read the manual. NOPASS actually allows > anyone to log on without specifying a password. If using VM:Secure or > no ESM, specify a password of LBYONLY. Thank you :-) I was indeed thinking RACF only. A lot of this becomes a moot point when you have passwords in plain text... Rob
Re: LOGONBY
No, you cannot logon to one userid when logged onto another. When already logged on, the process is CP LOGoff (or CP DISConnect). Then you get a logo screen and can logon using LOGONBY. Personally, I'd just clear the logon screen, and logon from a blank screen. The command entry from a cleared logo screen would be: LOGON MAINT BY youruserid your password Once you get past that, you can experiment with ways to reduce the number of individual commands. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Martin, Terry R. (CMS/CTR) (CTR)" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 09/23/2008 04:58 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: LOGONBY Hi One last thing on this. Am I logged on with my user id and password then from there logonby to another machine such as MAINT? Or do I just logon to MAINT using LOGONBY with my personal user id's password? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Tuesday, September 23, 2008 5:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY On Tue, Sep 23, 2008 at 8:35 PM, O'Brien, Dennis L wrote: > Be careful about what "*no* password" means. Rob is talking about RACF. > The directory allows a password of NOPASS, which might seem to be the > obvious thing if you don't read the manual. NOPASS actually allows > anyone to log on without specifying a password. If using VM:Secure or > no ESM, specify a password of LBYONLY. Thank you :-) I was indeed thinking RACF only. A lot of this becomes a moot point when you have passwords in plain text... Rob The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: LOGONBY
Just logon to MAINT using LOGONBY with your personal userid/pw Scott Rohling On Tue, Sep 23, 2008 at 3:58 PM, Martin, Terry R. (CMS/CTR) (CTR) < [EMAIL PROTECTED]> wrote: > Hi > > One last thing on this. Am I logged on with my user id and password then > from there logonby to another machine such as MAINT? Or do I just logon > to MAINT using LOGONBY with my personal user id's password? > > Thank You, > > Terry Martin > Lockheed Martin - Information Technology > z/OS & z/VM Systems - Performance and Tuning > Cell - 443 632-4191 > Work - 410 786-0386 > [EMAIL PROTECTED] > > -Original Message- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Rob van der Heij > Sent: Tuesday, September 23, 2008 5:51 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: LOGONBY > > On Tue, Sep 23, 2008 at 8:35 PM, O'Brien, Dennis L > > > wrote: > > > Be careful about what "*no* password" means. Rob is talking about > RACF. > > The directory allows a password of NOPASS, which might seem to be the > > obvious thing if you don't read the manual. NOPASS actually allows > > anyone to log on without specifying a password. If using VM:Secure or > > no ESM, specify a password of LBYONLY. > > Thank you :-) I was indeed thinking RACF only. A lot of this becomes > a moot point when you have passwords in plain text... > > Rob >
Re: LOGONBY
Hi One last thing on this. Am I logged on with my user id and password then from there logonby to another machine such as MAINT? Or do I just logon to MAINT using LOGONBY with my personal user id's password? Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Tuesday, September 23, 2008 5:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY On Tue, Sep 23, 2008 at 8:35 PM, O'Brien, Dennis L wrote: > Be careful about what "*no* password" means. Rob is talking about RACF. > The directory allows a password of NOPASS, which might seem to be the > obvious thing if you don't read the manual. NOPASS actually allows > anyone to log on without specifying a password. If using VM:Secure or > no ESM, specify a password of LBYONLY. Thank you :-) I was indeed thinking RACF only. A lot of this becomes a moot point when you have passwords in plain text... Rob
Re: LOGONBY
On Tue, Sep 23, 2008 at 8:35 PM, O'Brien, Dennis L wrote: > Be careful about what "*no* password" means. Rob is talking about RACF. > The directory allows a password of NOPASS, which might seem to be the > obvious thing if you don't read the manual. NOPASS actually allows > anyone to log on without specifying a password. If using VM:Secure or > no ESM, specify a password of LBYONLY. Thank you :-) I was indeed thinking RACF only. A lot of this becomes a moot point when you have passwords in plain text... Rob
Re: LOGONBY
David Boyes wrote: It was a user mod for a while (pre-XA). I think VM/XA or VM/ESA 1.x was when it became "official". That was a long time ago, though. I know I had it on SP5 as a usermod and remember that I was really glad to not have to maintain it any more. A very long time... http://vm.marist.edu/~vmshare/browse?fn=DMKLOG&ft=MEMO & http://vm.marist.edu/~vmshare/browse?fn=NOPSWD&ft=NOTE ...
Re: LOGONBY
It was a user mod for a while (pre-XA). I think VM/XA or VM/ESA 1.x was when it became "official". That was a long time ago, though. I know I had it on SP5 as a usermod and remember that I was really glad to not have to maintain it any more.
Re: LOGONBY
Rob van der Heij wrote: >Actually, the better solution is to have *no* password for TCPMAINT. >You can with z/VM 5.3. Without a password, the TCPMAINT user can not >be revoked by incorrect logon attempts. If it were revoked, the >authorized people could not even logon to it with logonby. Also, you >don't put individual users on the access list of the surrogate >profile, but primarily groups of users. That way it is very easy to >handle people joining or leaving the group or change their role. And >if needed, you can use Q BYUSER in the PROFILE EXEC to see which >person is using the shared userid. Be careful about what "*no* password" means. Rob is talking about RACF. The directory allows a password of NOPASS, which might seem to be the obvious thing if you don't read the manual. NOPASS actually allows anyone to log on without specifying a password. If using VM:Secure or no ESM, specify a password of LBYONLY. Dennis We are Borg of America. You will be assimilated. Resistance is futile.
Re: LOGONBY
Before VM got LOGONBY, IBM had internally a RACF modification that allowed a Logon By, for ages. Obviously, CP was not aware of the LOGONBY, (so no Q BYUSER for example). CP was even fooled: on the password prompt one'd enter byuser/byuserpswd/byuserpswd that is, for CP it looked like a password change. I think that around VM/ESA 1.0 both CP and RACF 1.9 got official Logon By support, that is thus at the same time as seen by external VM users. 2008/9/23 Stephen Frazier <[EMAIL PROTECTED]>: > LOGONBY has been a part of CP since before VM/ESA 2.3 (1998). It is not > mentioned in the Quick Reference for VM/SP 6 (1988) so it was added between > 1988 and 1998. It has been around a long time. Maybe even longer that RACF. > (I don't know when it was introduced on VM.) > > David Boyes wrote: >> >> It's controllable by RACF, but is part of CP (finally). >> >> Is LOGONBY a RACF thing or z/VM??? >> >> > > -- > Stephen Frazier > Information Technology Unit > Oklahoma Department of Corrections > 3400 Martin Luther King > Oklahoma City, Ok, 73111-4298 > Tel.: (405) 425-2549 > Fax: (405) 425-2554 > Pager: (405) 690-1828 > email: stevef%doc.state.ok.us > -- Kris Buelens, IBM Belgium, VM customer support
Re: LOGONBY
LOGONBY has been a part of CP since before VM/ESA 2.3 (1998). It is not mentioned in the Quick Reference for VM/SP 6 (1988) so it was added between 1988 and 1998. It has been around a long time. Maybe even longer that RACF. (I don't know when it was introduced on VM.) David Boyes wrote: It’s controllable by RACF, but is part of CP (finally). Is LOGONBY a RACF thing or z/VM??? -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: LOGONBY
It's controllable by RACF, but is part of CP (finally). Is LOGONBY a RACF thing or z/VM???
Re: LOGONBY
Terry, LOGONBY has been around for many VM releases. We set all our service machine accounts and important maintenance ids (MAINT, TCPMAINT, etc) up with a LOGONBY list. Then we change those ids' passwords to LBYONLY, which says the userid can only be logged on using LOGONBY. So if you try and log on to MAINT directly you get told L MAINT HCPLGA053E MAINT not in CP directory A scary message for the faint of heart! Besides limiting the number of people who can access MAINT to the ones in the LOGONBY list, MAINT never needs its password changed again, and the auditors are appeased (a considerable benefit for those who have to answer the questions at annual audits!). Ron On Tue, Sep 23, 2008 at 12:17 AM, Rob van der Heij <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 6:05 AM, Martin, Terry R. (CMS/CTR) (CTR) > <[EMAIL PROTECTED]> wrote: > >> So the only thing you are buying here is that you keep TCPMAINT password >> secret is that the whole idea behind LOGOnBY? So then you only add >> certain user ids to do LOGONBY for this user id correct? > > Actually, the better solution is to have *no* password for TCPMAINT. > You can with z/VM 5.3. Without a password, the TCPMAINT user can not > be revoked by incorrect logon attempts. If it were revoked, the > authorized people could not even logon to it with logonby. Also, you > don't put individual users on the access list of the surrogate > profile, but primarily groups of users. That way it is very easy to > handle people joining or leaving the group or change their role. And > if needed, you can use Q BYUSER in the PROFILE EXEC to see which > person is using the shared userid. > > This scheme is also useful for service machine that you may > occasionally logon to. Knowing all those passwords is either risky or > inconvenient. And you certainly do not want service machines to be > revoked (it will bite you at next IPL). > > The only users with a password should be the "warm body" users, > belonging to a single known individual who can maintain his own > password. All other userids should not have a password because they > are either autologged or accessed via LOGONBY. > > -Rob > -- > Rob van der Heij > Velocity Software > http://velocitysoftware.com/ >
Re: LOGONBY
One thing not mentioned by others (unless I missed it) - if you have
VM:Secure for your ESM, if you use logonby to log on to a userid, say
ALAN for purposes of discussion, and try to use VM:Secure to change any
of the security settings, you must give the logged on machine's password
in response to any prompts. You cannot change ALAN's passwords or rules
without knowing ALAN's password. I would hope that other ESMs, including
RACF, had similar requirements.
Regards,
Richard Schuh
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Ivica Brodaric
Sent: Monday, September 22, 2008 9:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: LOGONBY
So if I understand LOGONBY it simply allows a user to
logon to lets say TCPMAINT using the user's own PASSWORD. Does this mean
you still use TCPMAINT as the userid?
That's correct. LOGONBY will let a user logon to TCPMAINT using
his own userid and password of his own userid (the command will be
"LOGON TCPMAINT BY userid"). That will leave an audit trail of *who*
logged on to TCPMAINT and when. But the main advantage of LOGONBY is
that user does not need to know TCPMAINT's password. That also means
that you can change it without having to tell anyone about it.
If you set *yourself* with LOGONBY to all "system-type" userids,
you will not have to remember multiple passwords, just your own. Then,
you can even let your ESM generate random passwords for userids like
TCPMAINT, because you don't really have to know it either. NB, don't do
this (random passwords) until you are comfortable with LOGONBY. Just
don't tell anyone about the passwords.
Ivica Brodaric
Re: LOGONBY
On Tue, Sep 23, 2008 at 3:27 PM, Kris Buelens <[EMAIL PROTECTED]> wrote: > I never set tis up for a user like VMUTIL, but only to be able to > logon to my colleague's userid with my password when he was on > vacation (and a alike for my user when I was on vacation). And that's exactly why you should keep that separate. You mess up auditing by letting someone else use your personal userid. Even when you're on vacation, your colleague is not you (unless he's posting in your name on the list, paying bills out of your bank account, etc). Most corporate security regulations forbid such schemes for a good reason. I know it's easy for folks at the helpdesk to take control of an end-user account like this, but it is probably a good warning for the user to find that he's not able to use it himself during such period. If you keep roles in functional userid (even if under normal circumstances there is only one individual using it) then delegating tasks temporarily is easy. Rob
Re: LOGONBY
z/VM From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Tuesday, September 23, 2008 9:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY Is LOGONBY a RACF thing or z/VM??? T.y. >>> Graves Nora E <[EMAIL PROTECTED]> 9/23/2008 8:59 AM >>> And it makes it easy to revoke privileges from a user: just remove the LOGONBY authority. This is handy in an environment where roles change frequently. And if the person leaves or retires, deleting the User ID takes care of all access, without scrambling to remember which seldom-used accounts that the person may have used occasionally. Nora Graves -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Tuesday, September 23, 2008 8:35 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY > So the only thing you are buying here is that you keep TCPMAINT password > secret is that the whole idea behind LOGOnBY? So then you only add > certain user ids to do LOGONBY for this user id correct? Think of it more as a role: you are assuming the role of TCPMAINT, using your own login credentials to validate your claim to the role. The idea is minimum privilege; shared ids should not be directly logged into, because you lose the audit trail of who did what. You give individual ids minimum privilege (essentially with the combination of LOGINBY and PROP, there's rarely a real reason for any individual id to have more than class G), and they authenticate to the shared ID when they need to do something more powerful, or an extended string of things that require privileges or access to files w/o having to jump through a lot of maintenance-intensive hoops. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: LOGONBY
Howard Rifkind wrote: Is LOGONBY a RACF thing or z/VM??? T.y. No, it is not a RACF thing...it's part of the native CP user facilities. It can be used with RACF, or your ESM of choice. Graves Nora E <[EMAIL PROTECTED]> 9/23/2008 8:59 AM >>> And it makes it easy to revoke privileges from a user: just remove the LOGONBY authority. This is handy in an environment where roles change frequently. And if the person leaves or retires, deleting the User ID takes care of all access, without scrambling to remember which seldom-used accounts that the person may have used occasionally. Nora Graves -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: LOGONBY
On Tue, Sep 23, 2008 at 3:33 PM, Howard Rifkind <[EMAIL PROTECTED]> wrote: > Is LOGONBY a RACF thing or z/VM??? It is easier with RACF, but CP also has directory statements that support it. Rob
Re: LOGONBY
Is LOGONBY a RACF thing or z/VM??? T.y. >>> Graves Nora E <[EMAIL PROTECTED]> 9/23/2008 8:59 AM >>> And it makes it easy to revoke privileges from a user: just remove the LOGONBY authority. This is handy in an environment where roles change frequently. And if the person leaves or retires, deleting the User ID takes care of all access, without scrambling to remember which seldom-used accounts that the person may have used occasionally. Nora Graves -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Tuesday, September 23, 2008 8:35 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY > So the only thing you are buying here is that you keep TCPMAINT password > secret is that the whole idea behind LOGOnBY? So then you only add > certain user ids to do LOGONBY for this user id correct? Think of it more as a role: you are assuming the role of TCPMAINT, using your own login credentials to validate your claim to the role. The idea is minimum privilege; shared ids should not be directly logged into, because you lose the audit trail of who did what. You give individual ids minimum privilege (essentially with the combination of LOGINBY and PROP, there's rarely a real reason for any individual id to have more than class G), and they authenticate to the shared ID when they need to do something more powerful, or an extended string of things that require privileges or access to files w/o having to jump through a lot of maintenance-intensive hoops. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: LOGONBY
Not mentioned yet. If using RACF, when you define the user as LOGONBY, it can by default no longer be logged on to with its own password (what is normally what you'd want). But, with an extra command you can restore that possibility: 1. Define VMUTIL as LOGONBY RAC RDEFINE SURROGAT LOGONBY.VMUTIL UACC(NONE) 2. Reset the PERMIT RACF created for the command issuer RAC PERMIT LOGONBY.VMUTIL CLASS(SURROGAT) RESET 3. Allow users/groups to use this LOGONBY to VMUTIL RAC PERMIT LOGONBY.VMUTIL CLASS(SURROGAT) ID(user/group) ACCESS(READ) 4. (optional) Make it possible to logon to VMUTIL with its own password RAC PERMIT LOGONBY.VMUTIL CLASS(SURROGAT) ID(VMUTIL) ACCESS(ALTER) I never set tis up for a user like VMUTIL, but only to be able to logon to my colleague's userid with my password when he was on vacation (and a alike for my user when I was on vacation). 2008/9/23 Graves Nora E <[EMAIL PROTECTED]> > > And it makes it easy to revoke privileges from a user: just remove the > LOGONBY authority. This is handy in an environment where roles change > frequently. And if the person leaves or retires, deleting the User ID > takes care of all access, without scrambling to remember which > seldom-used accounts that the person may have used occasionally. > > > Nora Graves > > -Original Message- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of David Boyes > Sent: Tuesday, September 23, 2008 8:35 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: LOGONBY > > > So the only thing you are buying here is that you keep TCPMAINT > password > > secret is that the whole idea behind LOGOnBY? So then you only add > > certain user ids to do LOGONBY for this user id correct? > > Think of it more as a role: you are assuming the role of TCPMAINT, using > your own login credentials to validate your claim to the role. > > The idea is minimum privilege; shared ids should not be directly logged > into, because you lose the audit trail of who did what. You give > individual ids minimum privilege (essentially with the combination of > LOGINBY and PROP, there's rarely a real reason for any individual id to > have more than class G), and they authenticate to the shared ID when > they need to do something more powerful, or an extended string of things > that require privileges or access to files w/o having to jump through a > lot of maintenance-intensive hoops. -- Kris Buelens, IBM Belgium, VM customer support
Re: LOGONBY
And it makes it easy to revoke privileges from a user: just remove the LOGONBY authority. This is handy in an environment where roles change frequently. And if the person leaves or retires, deleting the User ID takes care of all access, without scrambling to remember which seldom-used accounts that the person may have used occasionally. Nora Graves -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Tuesday, September 23, 2008 8:35 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY > So the only thing you are buying here is that you keep TCPMAINT password > secret is that the whole idea behind LOGOnBY? So then you only add > certain user ids to do LOGONBY for this user id correct? Think of it more as a role: you are assuming the role of TCPMAINT, using your own login credentials to validate your claim to the role. The idea is minimum privilege; shared ids should not be directly logged into, because you lose the audit trail of who did what. You give individual ids minimum privilege (essentially with the combination of LOGINBY and PROP, there's rarely a real reason for any individual id to have more than class G), and they authenticate to the shared ID when they need to do something more powerful, or an extended string of things that require privileges or access to files w/o having to jump through a lot of maintenance-intensive hoops.
Re: LOGONBY
> So the only thing you are buying here is that you keep TCPMAINT password > secret is that the whole idea behind LOGOnBY? So then you only add > certain user ids to do LOGONBY for this user id correct? Think of it more as a role: you are assuming the role of TCPMAINT, using your own login credentials to validate your claim to the role. The idea is minimum privilege; shared ids should not be directly logged into, because you lose the audit trail of who did what. You give individual ids minimum privilege (essentially with the combination of LOGINBY and PROP, there's rarely a real reason for any individual id to have more than class G), and they authenticate to the shared ID when they need to do something more powerful, or an extended string of things that require privileges or access to files w/o having to jump through a lot of maintenance-intensive hoops.
Re: LOGONBY
On Tue, Sep 23, 2008 at 6:05 AM, Martin, Terry R. (CMS/CTR) (CTR) <[EMAIL PROTECTED]> wrote: > So the only thing you are buying here is that you keep TCPMAINT password > secret is that the whole idea behind LOGOnBY? So then you only add > certain user ids to do LOGONBY for this user id correct? Actually, the better solution is to have *no* password for TCPMAINT. You can with z/VM 5.3. Without a password, the TCPMAINT user can not be revoked by incorrect logon attempts. If it were revoked, the authorized people could not even logon to it with logonby. Also, you don't put individual users on the access list of the surrogate profile, but primarily groups of users. That way it is very easy to handle people joining or leaving the group or change their role. And if needed, you can use Q BYUSER in the PROFILE EXEC to see which person is using the shared userid. This scheme is also useful for service machine that you may occasionally logon to. Knowing all those passwords is either risky or inconvenient. And you certainly do not want service machines to be revoked (it will bite you at next IPL). The only users with a password should be the "warm body" users, belonging to a single known individual who can maintain his own password. All other userids should not have a password because they are either autologged or accessed via LOGONBY. -Rob -- Rob van der Heij Velocity Software http://velocitysoftware.com/
Re: LOGONBY
> > So if I understand LOGONBY it simply allows a user to logon to lets say > TCPMAINT using the user's own PASSWORD. Does this mean you still use > TCPMAINT as the userid? > That's correct. LOGONBY will let a user logon to TCPMAINT using his own userid and password of his own userid (the command will be "LOGON TCPMAINT BY userid"). That will leave an audit trail of *who* logged on to TCPMAINT and when. But the main advantage of LOGONBY is that user does not need to know TCPMAINT's password. That also means that you can change it without having to tell anyone about it. If you set *yourself* with LOGONBY to all "system-type" userids, you will not have to remember multiple passwords, just your own. Then, you can even let your ESM generate random passwords for userids like TCPMAINT, because you don't really have to know it either. NB, don't do this (random passwords) until you are comfortable with LOGONBY. Just don't tell anyone about the passwords. Ivica Brodaric
Re: LOGONBY
Hi Alan, So the only thing you are buying here is that you keep TCPMAINT password secret is that the whole idea behind LOGOnBY? So then you only add certain user ids to do LOGONBY for this user id correct? Thanks, Terry -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, September 22, 2008 11:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY On Monday, 09/22/2008 at 11:09 EDT, "Martin, Terry R. (CMS/CTR) (CTR)" <[EMAIL PROTECTED]> wrote: > So if I understand LOGONBY it simply allows a user to logon to lets say > TCPMAINT using the user?s own PASSWORD. Does this mean you still use TCPMAINT > as the userid? LOGON TCPMAINT BY ALAN Once you are logged on, you will be TCPMAINT. The RACF audit trail records the relationship on subsequent authorization calls as well, if memory serves. If someone else then tries LOGON TCPMAINT BY TERRY they will get "TCPMAINT already logged on". Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY
On Monday, 09/22/2008 at 11:09 EDT, "Martin, Terry R. (CMS/CTR) (CTR)" <[EMAIL PROTECTED]> wrote: > So if I understand LOGONBY it simply allows a user to logon to lets say > TCPMAINT using the user?s own PASSWORD. Does this mean you still use TCPMAINT > as the userid? LOGON TCPMAINT BY ALAN Once you are logged on, you will be TCPMAINT. The RACF audit trail records the relationship on subsequent authorization calls as well, if memory serves. If someone else then tries LOGON TCPMAINT BY TERRY they will get "TCPMAINT already logged on". Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY and FTP clients
The latest BlueZone Secure FTP 5.0 (still free) has a FTP command record/playback feature call Transfer Lists. Enable it to record and save any series of FTP commands, then play them back over and over. The file is ASCII, so you can create them manually or edit them with Notepad. They can be invoked from a command line allowing easy scheduling of unattended transfers. Steve Bireley Vice President Development BlueZone Software -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Noal Sent: Sunday, July 13, 2008 8:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: LOGONBY and FTP clients I've used BlueZone for years, almost decades. BlueZone has a macro facility. If you can do it manually and use LOGONBY, record the keystrokes in a macro. You've got it!! From: The IBM z/VM Operating System on behalf of Fred Schmidt Sent: Sun 7/13/2008 4:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: LOGONBY and FTP clients Hi Listers, Is there a way to get FTP clients like Bluezone, WS-FTP etc to work with z/VM users that use LOGONBY? Regards, Fred Schmidt Department of Corporate and Information Services (DCIS) Data Centre Services (DCS) Northern Territory Government, Australia
Re: LOGONBY and FTP clients
On Sunday, 07/13/2008 at 07:57 EDT, Fred Schmidt <[EMAIL PROTECTED]> wrote: > Is there a way to get FTP clients like Bluezone, WS-FTP etc to work with z/VM > users that use LOGONBY? Configure them with your user id as userid/by/yourid or userid.by.yourid Alan Altmark z/VM Development IBM Endicott
Re: LOGONBY and FTP clients
I've used BlueZone for years, almost decades. BlueZone has a macro facility. If you can do it manually and use LOGONBY, record the keystrokes in a macro. You've got it!! From: The IBM z/VM Operating System on behalf of Fred Schmidt Sent: Sun 7/13/2008 4:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: LOGONBY and FTP clients Hi Listers, Is there a way to get FTP clients like Bluezone, WS-FTP etc to work with z/VM users that use LOGONBY? Regards, Fred Schmidt Department of Corporate and Information Services (DCIS) Data Centre Services (DCS) Northern Territory Government, Australia
