Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
I don't think it matters much. If the PC gets hacked then the hacker can probably figure out ways to get access to the mainframe whether it's setup to automatically logon or not. On 5/4/2020 1:31 PM, Tom Marchant wrote: On Mon, 4 May 2020 19:14:31 +, Frank Swarbrick wrote: What I would love to see is some sort of "single signon" option, where a user would only need to sign on to their personal workstation and not need to explicitly sign on to z/OS at all. IMO, this is a bad idea unless you can count on everyone's workstation being at least as secure as z/OS is. All you need is one user who gets their PC hacked and the hacker has access to z/OS, with whatever authority that user has. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
The vast majority of z/OS users don't need elevated authority, unlike much of Windows Workstations. I don't think it would be a good idea to include Sysprogs and z/OS Security Admins in the extended length world. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Marchant > Sent: Monday, May 04, 2020 1:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125) > > On Mon, 4 May 2020 19:14:31 +, Frank Swarbrick wrote: > > >What I would love to see is some sort of "single signon" option, where > >a user would only need to sign on to their personal workstation and not > need to explicitly sign on to z/OS at all. > > IMO, this is a bad idea unless you can count on everyone's workstation being > at least as secure as z/OS is. All you need is one user who gets their PC > hacked and the hacker has access to z/OS, with whatever authority that user > has. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using Windows ssh with z/OS
In article <6673472942485742.wa.paulgboulderaim@listserv.ua.edu> you wrote:
> On Mon, 4 May 2020 17:39:39 -0500, Wendell Lovewell wrote:
> >
> >Installing Rocket's bash provided the cursor history scrolling I was looking
> >for.
> >
> >I don't perceive a difference between TERM=xterm+256color and TERM=xterm in
> >the command-line-only functions I use. (I don't see any coloring in the ls
> >or other output for either value.)
> >
> >I have "bash" as the last line in /etc/profile. This seems to work, but I
> >do have to enter "exit" twice to close the window. Is there a way to invoke
> >bash so that this is not necessary? I'm also not sure if this matters, but
> >"echo $SHELL" still shows "/bin/sh", not "/bin/bash".
> >
> SHELL=/bin/bash exec $SHELL
> -- gil
If you have permission (or know someone that has permission), do:
TSO ALTUSER userid OMVS(PROGRAM('/path/to/bin/bash'))
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
sas...@sas.com (919) 531-5637Cary, NC 27513
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Using Windows ssh with z/OS
On Mon, 4 May 2020 17:39:39 -0500, Wendell Lovewell wrote: > >Installing Rocket's bash provided the cursor history scrolling I was looking >for. > >I don't perceive a difference between TERM=xterm+256color and TERM=xterm in >the command-line-only functions I use. (I don't see any coloring in the ls or >other output for either value.) > >I have "bash" as the last line in /etc/profile. This seems to work, but I do >have to enter "exit" twice to close the window. Is there a way to invoke bash >so that this is not necessary? I'm also not sure if this matters, but "echo >$SHELL" still shows "/bin/sh", not "/bin/bash". > SHELL=/bin/bash exec $SHELL -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Using Windows ssh with z/OS
On 5/4/20 4:39 PM, Wendell Lovewell wrote: I have "bash" as the last line in /etc/profile. This seems to work, but I do have to enter "exit" twice to close the window. Is there a way to invoke bash so that this is not necessary? I'm also not sure if this matters, but "echo $SHELL" still shows "/bin/sh", not "/bin/bash". The shell that loads when you log in is chosen by your profile. Not sure how this is done in USS but someone administratively could simply change your login shell to /bin/bash. In the meantime, just create a profile in your home directory .profile that does exec /bin/bash -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Using Windows ssh with z/OS
Thanks to everyone for the advice. Installing Rocket's bash provided the cursor history scrolling I was looking for. I don't perceive a difference between TERM=xterm+256color and TERM=xterm in the command-line-only functions I use. (I don't see any coloring in the ls or other output for either value.) I have "bash" as the last line in /etc/profile. This seems to work, but I do have to enter "exit" twice to close the window. Is there a way to invoke bash so that this is not necessary? I'm also not sure if this matters, but "echo $SHELL" still shows "/bin/sh", not "/bin/bash". - Wendell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
I know on my MQ instance I have installed on my home Windows machine, MQ truncates my Windows user ID "Frank Swarbrick" to "Frank Swarbr". From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Monday, May 4, 2020 2:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length The maximum length on Linux is 32; whether MQ will work with a name longer than 12 is a separate issue. There are also Linux commands that will display the UID instead of a username longer than 8. LDAP can map long names to short. I don't know about non-IBM LDAP. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Monday, May 4, 2020 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Wow! That's a lot to digest. A couple of things. First, I see the following documented: “On z/OS® and UNIX and Linux, the maximum length of a user ID is 12 characters.” From https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q010300_.htm I wonder how this works if RACF user IDs are only allowed up to 8 characters. Would an alternate SAF product be required? I can't see anything documented to explain how this might work. On a separate line, are you saying is it possible for z/OS to use a non-z/OS LDAP server for authentication (and authorization?), including user IDs and passwords? But this would that still require TSO and CICS (and IMS? and others?) signon processes to be able to handle those user IDs? It sounds like both of these things are true, but I want to make sure I am not misunderstanding you. From: IBM Mainframe Discussion List on behalf of Timothy Sipples Sent: Saturday, May 2, 2020 12:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference:
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
Well, in our case at least the workstation refers to a company provided and managed workstation. We can't log on to z/OS from our personal devices. And we use SSO for many applications. I don't know how it works; only that it does work. From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Monday, May 4, 2020 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125) On Mon, 4 May 2020 19:14:31 +, Frank Swarbrick wrote: >What I would love to see is some sort of "single signon" option, where a user >would only need >to sign on to their personal workstation and not need to explicitly sign on to >z/OS at all. IMO, this is a bad idea unless you can count on everyone's workstation being at least as secure as z/OS is. All you need is one user who gets their PC hacked and the hacker has access to z/OS, with whatever authority that user has. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length (not ... Digest ...)
On Mon, 4 May 2020 15:31:52 -0500, Tom Marchant wrote: >On Mon, 4 May 2020 19:14:31 +, Frank Swarbrick wrote: > >>What I would love to see is some sort of "single signon" option, where a user >>would only need >>to sign on to their personal workstation and not need to explicitly sign on >>to z/OS at all. > >IMO, this is a bad idea unless you can count on everyone's workstation being >at least as secure >as z/OS is. All you need is one user who gets their PC hacked and the hacker >has access to z/OS, >with whatever authority that user has. > But the user will keep credentials on a desktop system (I've done so with ssh) or on a Post-It on the terminal screen, etc. Multi-factor? Real-time facial recognition with challenge-response? Remember, Watson won at Jeopardy, and could probably beat captchas. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
The maximum length on Linux is 32; whether MQ will work with a name longer than 12 is a separate issue. There are also Linux commands that will display the UID instead of a username longer than 8. LDAP can map long names to short. I don't know about non-IBM LDAP. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Frank Swarbrick [frank.swarbr...@outlook.com] Sent: Monday, May 4, 2020 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Wow! That's a lot to digest. A couple of things. First, I see the following documented: “On z/OS® and UNIX and Linux, the maximum length of a user ID is 12 characters.” From https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q010300_.htm I wonder how this works if RACF user IDs are only allowed up to 8 characters. Would an alternate SAF product be required? I can't see anything documented to explain how this might work. On a separate line, are you saying is it possible for z/OS to use a non-z/OS LDAP server for authentication (and authorization?), including user IDs and passwords? But this would that still require TSO and CICS (and IMS? and others?) signon processes to be able to handle those user IDs? It sounds like both of these things are true, but I want to make sure I am not misunderstanding you. From: IBM Mainframe Discussion List on behalf of Timothy Sipples Sent: Saturday, May 2, 2020 12:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
On Mon, 4 May 2020 19:14:31 +, Frank Swarbrick wrote: >What I would love to see is some sort of "single signon" option, where a user >would only need >to sign on to their personal workstation and not need to explicitly sign on to >z/OS at all. IMO, this is a bad idea unless you can count on everyone's workstation being at least as secure as z/OS is. All you need is one user who gets their PC hacked and the hacker has access to z/OS, with whatever authority that user has. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
On Mon, 4 May 2020 at 04:23, Barbara Nitz wrote: > Doesn't matter. With an IMS region, you cannot use cancel (z/OS: > "non-cancelable, use force arm"). You cannot use force arm (z/OS: "cancel > first, please"). And you cannot use force because IMS intercepts that and > tells you to terminate the IMS region by de-registering it from IMS. ... How does IMS (or anyone else) "intercept" a FORCE? Is it watching the command interface (SSI) or some such anti social behaviour? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
It's simple enough to write your own CICS signon screen to allow for longer
user IDs (and passwords/phrases), but I think CICS would have to add support
for the EXEC CICS SIGNON command to allow for a longer user ID. Currently:
"
USERID(data-value)
Specifies the 8-byte sign-on user ID.
The user ID supplied is converted to uppercase.
"
They did, of course, already add support for a "PASSPHRASE" of up to 100
characters.
From: IBM Mainframe Discussion List on behalf of
Wayne Bickerdike
Sent: Monday, May 4, 2020 2:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
There are more CICS users than TSO users. Is there a howto for the CICS
signon screen to accept long IDs and Passphrases?
On Mon, May 4, 2020 at 6:03 PM Timothy Sipples wrote:
> Bob Bridges wrote:
> >So maybe - maybe, I don't know either - if I sign on to z/OS with a
> >certificate, or LDAP, or anything other than the usual, the sign-on
> routine
> >MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
> >everything works fine, I guess.
>
> I don't think RACF itself works that way, or at least the z/OS 2.4
> documentation doesn't suggest so. Take a look at this information, for
> example:
>
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm
>
> Let's suppose the user is authenticating with RACF (not with the IBM
> Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an X.509
> client digital certificate for that purpose. RACF has to know ahead of
> time whether or not to authenticate that particular user (digital
> certificate). So the digital certificate has to be known to RACF ahead of
> time. Since the digital certificate has to be known, it's not unreasonable
> to associate an up to 8 character "short" user ID with that certificate.
> And that's how it works, as I understand it. The user doesn't present the
> short user ID -- well, not really, I'll get to this in a moment -- but
> RACF can check the certificate and create an ACEE with a mapped short user
> ID.
>
> There are three basic choices here as I understand it:
>
> 1. A one-to-one mapping (one certificate to short ID ABCD1234). The
> documentation does a little bit of handwaving here along the lines of
> "this might be difficult to administer," but I'd argue that's somewhat
> dated advice now that so many organizations use identity management tools.
>
> 2. A many-to-one mapping (multiple certificates to ABCD1234).
>
> 3. Either mapping, but with the certificate itself holding an embedded
> short name ("hostIdMapping"). Certificate issuers don't typically support
> this extension, or at least they hide it well, but the z/OS PKI Services
> do. (Is this technique "cheating"? Not really)
>
> In all these cases the user need not be aware there's a short name that
> RACF uses "under the covers." The user just supplies a valid, unexpired
> client certificate -- from a PIN-protected smart card perhaps. From RACF's
> perspective the X.509 digital certificate is really just another alias, a
> verbose one.
>
> z/OS LDAP also supports broadly similar RACF ID mapping (supply a long CN,
> which the directory maps to a short name), but it's optional. You can
> certainly authenticate with LDAP as a standalone matter if you wish.
>
> It's an interesting idea to have a fourth option for digital certificate
> authentication with RACF, which would be like choice #1 but without
> telling RACF what the short user ID is ahead of time -- to let RACF create
> one "on the fly," probably with caching and templating. For example, allow
> me to register a bunch of digital certificates in RACF as valid users, but
> I'm not going to tell you (RACF) what their short user IDs are ahead of
> time. The first time you encounter a particular certificate, just create a
> short user ID of C$-- (where the dashes are RACF's randomized or
> sequential choice, of any length -- randomized as default, but sequential
> as an option), store it, and use that on-the-fly short ID to build the
> ACEE. For example. I'd have to ponder that one a bit more, but if you
> think you've got a good use case, ask (RFE).
>
> Of course it'd be "nice" to have more than a maximum 8 character ID (with
> the current maximum of 39 different characters per position) internally in
> RACF, but I imagine that'd be a big plumbing problem and potentially break
> a lot of important stuff if not done carefully. Fortunately, you're not
> required to limit users' experiences to maximum 8 character user IDs: use
> LDAP CNs, use digital certificates, or use something else.
>
> By the way, if someone is looking for an interesting project, I'd be
> pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN
> and passphrase that's then checked against the IBM Directory Server for
> z/OS for authentication (and thus also with the SAF security provider,
>
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
Interesting stuff. I certainly won't claim to understand it all.
What I would love to see is some sort of "single signon" option, where a user
would only need to sign on to their personal workstation and not need to
explicitly sign on to z/OS at all. It seems like (to me, anyway!) a user could
use a TN3270 application to connect to the z/OS Communication Server and
somehow a credential authentication could be done between the TN3270 client and
the TN3270 server. I think then CICS/TSO/etc. would need to query the "TN3270
session" and bypass the associated signon screen(s) if the session has already
been authenticated. Or something like that. Does this sound remotely in the
realm of possibility?
From: IBM Mainframe Discussion List on behalf of
Timothy Sipples
Sent: Monday, May 4, 2020 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
Bob Bridges wrote:
>So maybe - maybe, I don't know either - if I sign on to z/OS with a
>certificate, or LDAP, or anything other than the usual, the sign-on
routine
>MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
>everything works fine, I guess.
I don't think RACF itself works that way, or at least the z/OS 2.4
documentation doesn't suggest so. Take a look at this information, for
example:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm
Let's suppose the user is authenticating with RACF (not with the IBM
Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an X.509
client digital certificate for that purpose. RACF has to know ahead of
time whether or not to authenticate that particular user (digital
certificate). So the digital certificate has to be known to RACF ahead of
time. Since the digital certificate has to be known, it's not unreasonable
to associate an up to 8 character "short" user ID with that certificate.
And that's how it works, as I understand it. The user doesn't present the
short user ID -- well, not really, I'll get to this in a moment -- but
RACF can check the certificate and create an ACEE with a mapped short user
ID.
There are three basic choices here as I understand it:
1. A one-to-one mapping (one certificate to short ID ABCD1234). The
documentation does a little bit of handwaving here along the lines of
"this might be difficult to administer," but I'd argue that's somewhat
dated advice now that so many organizations use identity management tools.
2. A many-to-one mapping (multiple certificates to ABCD1234).
3. Either mapping, but with the certificate itself holding an embedded
short name ("hostIdMapping"). Certificate issuers don't typically support
this extension, or at least they hide it well, but the z/OS PKI Services
do. (Is this technique "cheating"? Not really)
In all these cases the user need not be aware there's a short name that
RACF uses "under the covers." The user just supplies a valid, unexpired
client certificate -- from a PIN-protected smart card perhaps. From RACF's
perspective the X.509 digital certificate is really just another alias, a
verbose one.
z/OS LDAP also supports broadly similar RACF ID mapping (supply a long CN,
which the directory maps to a short name), but it's optional. You can
certainly authenticate with LDAP as a standalone matter if you wish.
It's an interesting idea to have a fourth option for digital certificate
authentication with RACF, which would be like choice #1 but without
telling RACF what the short user ID is ahead of time -- to let RACF create
one "on the fly," probably with caching and templating. For example, allow
me to register a bunch of digital certificates in RACF as valid users, but
I'm not going to tell you (RACF) what their short user IDs are ahead of
time. The first time you encounter a particular certificate, just create a
short user ID of C$-- (where the dashes are RACF's randomized or
sequential choice, of any length -- randomized as default, but sequential
as an option), store it, and use that on-the-fly short ID to build the
ACEE. For example. I'd have to ponder that one a bit more, but if you
think you've got a good use case, ask (RFE).
Of course it'd be "nice" to have more than a maximum 8 character ID (with
the current maximum of 39 different characters per position) internally in
RACF, but I imagine that'd be a big plumbing problem and potentially break
a lot of important stuff if not done carefully. Fortunately, you're not
required to limit users' experiences to maximum 8 character user IDs: use
LDAP CNs, use digital certificates, or use something else.
By the way, if someone is looking for an interesting project, I'd be
pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN
and passphrase that's then checked against the IBM Directory Server for
z/OS for authentication (and thus also with the SAF security provider,
indirectly). This part of the z/OS
Re: zOSHF / zFS
The root, is not the same as the sysplex root.
/* syplex root file system - z/OS sysplex root */
<- /global/zosmf needs to be here
ROOT FILESYSTEM('OMVS.')
TYPE(ZFS) MODE(RDWR) AUTOMOVE
/* altroot sysplex root file system - alternate z/OS sysplex root
*/
ALTROOT FILESYSTEM('OMVS.')
MOUNTPOINT('/sysalt')
/* system-specific file system - z/OS USS - directory */
MOUNT FILESYSTEM('OMVS.')
TYPE(ZFS) MODE(RDWR) UNMOUNT PARM('NORWSHARE')
MOUNTPOINT('/')
/* z/OS USS operating system- z/OS USS binary $VERSION zFS
Image specific root FS */<--- /global /zosmf not
here
MOUNT FILESYSTEM('OMVS.OPSYS.')
TYPE(ZFS) MODE(READ) UNMOUNT PARM('NORWSHARE')
MOUNTPOINT('/$VERSION')
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
Allan
It is the first entry off the root
All the other zFS of interest are hung off of /REL240 meaning the JAVA's and
the Liberty_zos
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Allan Staller
Sent: Monday, May 4, 2020 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
Is the mountpoint /global/zosmf hung off of the sysplex root?
In all cases, I would think any system would complain the ZFS is already
mounted.
Check the mount mode for the zosmf zfs (s/b R/W)
SYSPLEX(YES) should make the zosmf zfs visible to all images provided the
mountpoint is available.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
We have SYSPLEX(YES) and FORK(COW)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jousma, David
Sent: Monday, May 4, 2020 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
Steve,
I replied earlier to one of your other threads about this. Unless you are
running with Shared Sysplex Root, you cannot mount the same filesystem on
multiple systems for READ/WRITE. You will know if you are or are not by
BPMPRMxx SYSPLEX (YES|NO) setting.There is quite a bit of pre-work and
planning required to turn on SYSPLEX Filesystem.
/* SYSPLEX ROOT DEFINTIONS */
/* */
VERSION('')
SYSPLEX(YES)
The alternative I gave you then is to manually UNMOUNT the filesystem from
where ZOSMF was, and MOUNT It on the system you WANT to run ZOSMF on, and you
should be fine.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSHF / zFS
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
I have come up against and INTERESTING problem. Ona zOS 2.4 system
On my MONOPLEX the zFS for zOSMF showed MOUTED in ISH and when I look at in
SDSF FS it's all good zOSMF operates as it should.
In my 4-way SYSPLEX the JAVA's and the LIBERTY zFS are correct in ISH and in
SDSF FS
Now the ZOSMF zFS shows it was properly mounted in ISH, however in SDSF FS, the
zFS is not visible, and the IZUANG1 fails.
Any ideas
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the
Re: Mainframe user ID length
MQ does, in fact, support that, and I've used it. It's the "Channel Authentication" user mapping feature. I was just wondering if it was "directly supported" without a mapping, if the presented user ID was more than 8 characters. Thanks. From: IBM Mainframe Discussion List on behalf of Walt Farrell Sent: Sunday, May 3, 2020 7:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length On Thu, 30 Apr 2020 19:46:04 +, Frank Swarbrick wrote: >Is z/OS still limited in all cases to 8 upper case characters? I am curious >if a user that only has access to MQ might be able to have a longer and >ideally mixed case user ID. They wouldn't have access to TSO or CICS or IMS. It is in theory possible for an application (such as MQ) to use z/OS security services to map an alternative identity (which might have different characteristics from a z/OS user ID) into a standard z/OS user ID. That can be done, for example, when applications support authentication via digital certificates, or via Kerberos (e.g., Windows Active Directory), or via LDAP. And there are additional mechanisms besides those three that z/OS supports. I have no idea whether MQ supports any of those alternative mechanisms, nor which ones, nor whether they're applicable in your environment. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
> As a side note, why won't JCL accept all legal e-mail address? I thought there was an IBM stated aim to get to this, but I cannot find it. Certainly the recently added (Z/OS 1.3 I think) email field (WAEMAIL) in the RACF WORKATTR segment has a requirement to be unique within the RACF database. So there is a one-to-one mapping between email addresses and RACF userids. Looks like this is paving the way to achieving what you suggest. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 04 May 2020 17:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Mainframe user ID length Your claim was "You can specify pretty much anything you want in JCL." Regardless of why it is coded that way, the code is in the C/I and the error message comes from the C/I. The fact remains that you are limited in what you can specify in JCL. My first thought was that you meant that JECL had looser limits, but I couldn't find thoses paraemters in either JES2 JECL or JES3 JECL. As a side note, why won't JCL accept all legal e-mail address? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Monday, May 4, 2020 1:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Shmuel Metz wrote: >According to MVS JCL Reference, SA23-1385-40, both USER=abcdefghi and >EMAIL=foo+...@patriot.net are illegal. That's not a JES issue. It is JES's issue. JCL is simply respecting JES limits there using that particular syntax. If you want to pass a longer user ID to something else using a different vocabulary, JCL isn't going to stop you. Example: Try using JCL to invoke z/OS's FTP client to transfer a file to an arbitrary FTP server, specifying a user ID longer than 8 characters. Can it be done? Of course it can; it's perfectly routine. You just don't use JES-related syntax, that's all. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOSHF / zFS
Allan
It is the first entry off the root
All the other zFS of interest are hung off of /REL240 meaning the JAVA's and
the Liberty_zos
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Allan Staller
Sent: Monday, May 4, 2020 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
Is the mountpoint /global/zosmf hung off of the sysplex root?
In all cases, I would think any system would complain the ZFS is already
mounted.
Check the mount mode for the zosmf zfs (s/b R/W)
SYSPLEX(YES) should make the zosmf zfs visible to all images provided the
mountpoint is available.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
We have SYSPLEX(YES) and FORK(COW)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jousma, David
Sent: Monday, May 4, 2020 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
Steve,
I replied earlier to one of your other threads about this. Unless you are
running with Shared Sysplex Root, you cannot mount the same filesystem on
multiple systems for READ/WRITE. You will know if you are or are not by
BPMPRMxx SYSPLEX (YES|NO) setting.There is quite a bit of pre-work and
planning required to turn on SYSPLEX Filesystem.
/* SYSPLEX ROOT DEFINTIONS */
/* */
VERSION('')
SYSPLEX(YES)
The alternative I gave you then is to manually UNMOUNT the filesystem from
where ZOSMF was, and MOUNT It on the system you WANT to run ZOSMF on, and you
should be fine.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSHF / zFS
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
I have come up against and INTERESTING problem. Ona zOS 2.4 system
On my MONOPLEX the zFS for zOSMF showed MOUTED in ISH and when I look at in
SDSF FS it's all good zOSMF operates as it should.
In my 4-way SYSPLEX the JAVA's and the LIBERTY zFS are correct in ISH and in
SDSF FS
Now the ZOSMF zFS shows it was properly mounted in ISH, however in SDSF FS, the
zFS is not visible, and the IZUANG1 fails.
Any ideas
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL
EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
This e-mail transmission contains information that is confidential and may
be privileged. It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it in
any manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates.
Re: zOSHF / zFS
Is the mountpoint /global/zosmf hung off of the sysplex root?
In all cases, I would think any system would complain the ZFS is already
mounted.
Check the mount mode for the zosmf zfs (s/b R/W)
SYSPLEX(YES) should make the zosmf zfs visible to all images provided the
mountpoint is available.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
We have SYSPLEX(YES) and FORK(COW)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jousma, David
Sent: Monday, May 4, 2020 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
Steve,
I replied earlier to one of your other threads about this. Unless you are
running with Shared Sysplex Root, you cannot mount the same filesystem on
multiple systems for READ/WRITE. You will know if you are or are not by
BPMPRMxx SYSPLEX (YES|NO) setting.There is quite a bit of pre-work and
planning required to turn on SYSPLEX Filesystem.
/* SYSPLEX ROOT DEFINTIONS */
/* */
VERSION('')
SYSPLEX(YES)
The alternative I gave you then is to manually UNMOUNT the filesystem from
where ZOSMF was, and MOUNT It on the system you WANT to run ZOSMF on, and you
should be fine.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSHF / zFS
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
I have come up against and INTERESTING problem. Ona zOS 2.4 system
On my MONOPLEX the zFS for zOSMF showed MOUTED in ISH and when I look at in
SDSF FS it's all good zOSMF operates as it should.
In my 4-way SYSPLEX the JAVA's and the LIBERTY zFS are correct in ISH and in
SDSF FS
Now the ZOSMF zFS shows it was properly mounted in ISH, however in SDSF FS, the
zFS is not visible, and the IZUANG1 fails.
Any ideas
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL
EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
This e-mail transmission contains information that is confidential and may
be privileged. It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it in
any manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of HCL is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any email and/or
Re: Mainframe user ID length
Wow! That's a lot to digest. A couple of things. First, I see the following documented: “On z/OS® and UNIX and Linux, the maximum length of a user ID is 12 characters.” From https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q010300_.htm I wonder how this works if RACF user IDs are only allowed up to 8 characters. Would an alternate SAF product be required? I can't see anything documented to explain how this might work. On a separate line, are you saying is it possible for z/OS to use a non-z/OS LDAP server for authentication (and authorization?), including user IDs and passwords? But this would that still require TSO and CICS (and IMS? and others?) signon processes to be able to handle those user IDs? It sounds like both of these things are true, but I want to make sure I am not misunderstanding you. From: IBM Mainframe Discussion List on behalf of Timothy Sipples Sent: Saturday, May 2, 2020 12:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Frank Swarbrick wrote: >"more than 8"? What's the limit, if any? The z/OS LDAP Server's CN limit is 256 characters, so it's at least that large. >Which system components/products permit/prohibit this? >(Start your list with JCL.) You can specify pretty much anything you want in JCL. Do you mean JES2? If so, that'll use maximum 8 character user IDs. Whatever list I come up with is necessarily going to be partial, but as we've already seen (I linked to the documentation) MQ for z/OS can authenticate users with the IBM Directory Server for z/OS at least in certain contexts. CICS Transaction Server for z/OS also can in certain contexts. See for example this documentation: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.5.0/security/java/dist_identity.html Other z/OS components and products that come to mind include the z/OS Container Extensions, WebSphere Application Server for z/OS, and the IBM HTTP Server for z/OS. See for example here: https://www.ibm.com/support/knowledgecenter/SSEQTJ_9.0.5/com.ibm.websphere.ihs.doc/ihs/tihs_apacheldapcfg.html There are quite a large number of intersections, so many that we've now reached the stage when one of them fell overboard. z/OS HCD had some LDAP affinities (would you believe), but they were removed in z/OS 2.3. Evidently that one was too "crazy." :-) Bob Bridges wrote: >I'm about to expose my ignorance here: IDS and LDAP, aren't they just >IBM's attempt to let z/OS talk to non-z/OS systems? No, not according to IBM. Right at the very beginning of the IBM (Tivoli) Directory Server for z/OS redbook, Section 1.1, it says that this component is for both z/OS and non-z/OS workloads. So take the hint: if maximum 8 character user IDs are constraining, then start using the IBM Directory Server for z/OS to authenticate users if you aren't already, as/where it makes sense for you. Or use a certain something else to authenticate (see below). >Or put it this way: If you say I can be authenticated via LPAR using a >longer ID, and then perform tasks on the mainframe using that ID, how does >RACF-or-whatever determine permissions? First of all, you didn't include "RACF" in the text I reacted to. RACF is a popular but optional z/OS component. z/OS is not equivalent to RACF. Second, if you are talking about RACF specifically, yes, it does use maximum 8 character user IDs But you're not required to authenticate with them. I (somewhat facetiously) pointed out that you don't have to authenticate at all, although (as I also pointed out) I'll urge you to at least perform authorizations. More seriously, z/OS RACF has supported client certificate authentication since the 1990s. (This feature was initially introduced way back in the OS/390 days. The OS/390 TN3270E Server picked up support for it with OS/390 2.9, backported to 2.8. IBM Personal Communications picked up support for this feature in the late 1990s, too.) See here for an introductory reference: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Enabling_client_login_using_certificates.htm In this case users don't present maximum 8 character user IDs at all, or not really. They present digital certificates, and those may be coming from PIN-protected smart cards for example. Please do check this out! It's a really nifty solution, and the world seems to be (re)discovering it lately. Another approach you can take is to authenticate with the IBM Directory Server for z/OS (or other LDAP server, but that one is a terrific one) and leverage a mapping to a "short name." This is the approach z/VSE takes when you turn on its included LDAP authentication support, and it's both simple and clever. You're certainly free to submit RFEs for IBM's consideration if you'd like more such features, such as a TSO/E sign on screen comparable to z/VSE's LDAP friendly sign on screen. >...Even if I've logged on from some other OS using a longer
Re: zOSHF / zFS
We have SYSPLEX(YES) and FORK(COW)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Monday, May 4, 2020 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSHF / zFS
Steve,
I replied earlier to one of your other threads about this. Unless you are
running with Shared Sysplex Root, you cannot mount the same filesystem on
multiple systems for READ/WRITE. You will know if you are or are not by
BPMPRMxx SYSPLEX (YES|NO) setting.There is quite a bit of pre-work and
planning required to turn on SYSPLEX Filesystem.
/* SYSPLEX ROOT DEFINTIONS */
/* */
VERSION('')
SYSPLEX(YES)
The alternative I gave you then is to manually UNMOUNT the filesystem from
where ZOSMF was, and MOUNT It on the system you WANT to run ZOSMF on, and
you should be fine.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids,
MI 49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSHF / zFS
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or
unexpected emails**
I have come up against and INTERESTING problem. Ona zOS 2.4 system
On my MONOPLEX the zFS for zOSMF showed MOUTED in ISH and when I look at in
SDSF FS it's all good zOSMF operates as it should.
In my 4-way SYSPLEX the JAVA's and the LIBERTY zFS are correct in ISH and in
SDSF FS
Now the ZOSMF zFS shows it was properly mounted in ISH, however in SDSF FS,
the zFS is not visible, and the IZUANG1 fails.
Any ideas
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or
unexpected emails**
This e-mail transmission contains information that is confidential and may
be privileged. It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOSHF / zFS
Do you see all the zOSMF zfs file systems when you issue the /D Omvs,f command in the LPAR IZUANG1 fails. And what kind of messages do you see in the IZUANG1 joblog referencing failure? Saygılarımla / Best Regards. Bülent Dülger Principal Mainframe IT Consultant and CoFounder ServiZ Information Technologies Inc. E-mail : bul...@serviz.com.tr > On 4 May 2020, at 20:22, Steve Beaver wrote: > > I have come up against and INTERESTING problem. Ona zOS 2.4 system > > On my MONOPLEX the zFS for zOSMF showed MOUTED in ISH and when I look at in > SDSF FS it's all good zOSMF operates as it should. > > In my 4-way SYSPLEX the JAVA's and the LIBERTY zFS are correct in ISH and in > SDSF FS > > Now the ZOSMF zFS shows it was properly mounted in ISH, however in SDSF FS, > the zFS is not visible, and the IZUANG1 fails. > > Any ideas > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOSHF / zFS
Steve,
I replied earlier to one of your other threads about this. Unless you are
running with Shared Sysplex Root, you cannot mount the same filesystem on
multiple systems for READ/WRITE. You will know if you are or are not by
BPMPRMxx SYSPLEX (YES|NO) setting.There is quite a bit of pre-work and
planning required to turn on SYSPLEX Filesystem.
/* SYSPLEX ROOT DEFINTIONS */
/* */
VERSION('')
SYSPLEX(YES)
The alternative I gave you then is to manually UNMOUNT the filesystem from
where ZOSMF was, and MOUNT It on the system you WANT to run ZOSMF on, and you
should be fine.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Monday, May 4, 2020 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zOSHF / zFS
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
I have come up against and INTERESTING problem. Ona zOS 2.4 system
On my MONOPLEX the zFS for zOSMF showed MOUTED in ISH and when I look at in
SDSF FS it's all good zOSMF operates as it should.
In my 4-way SYSPLEX the JAVA's and the LIBERTY zFS are correct in ISH and in
SDSF FS
Now the ZOSMF zFS shows it was properly mounted in ISH, however in SDSF FS, the
zFS is not visible, and the IZUANG1 fails.
Any ideas
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL
EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zOSHF / zFS
I have come up against and INTERESTING problem. Ona zOS 2.4 system On my MONOPLEX the zFS for zOSMF showed MOUTED in ISH and when I look at in SDSF FS it's all good zOSMF operates as it should. In my 4-way SYSPLEX the JAVA's and the LIBERTY zFS are correct in ISH and in SDSF FS Now the ZOSMF zFS shows it was properly mounted in ISH, however in SDSF FS, the zFS is not visible, and the IZUANG1 fails. Any ideas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe user ID length
Your claim was "You can specify pretty much anything you want in JCL." Regardless of why it is coded that way, the code is in the C/I and the error message comes from the C/I. The fact remains that you are limited in what you can specify in JCL. My first thought was that you meant that JECL had looser limits, but I couldn't find thoses paraemters in either JES2 JECL or JES3 JECL. As a side note, why won't JCL accept all legal e-mail address? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Monday, May 4, 2020 1:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Shmuel Metz wrote: >According to MVS JCL Reference, SA23-1385-40, both >USER=abcdefghi and EMAIL=foo+...@patriot.net are >illegal. That's not a JES issue. It is JES's issue. JCL is simply respecting JES limits there using that particular syntax. If you want to pass a longer user ID to something else using a different vocabulary, JCL isn't going to stop you. Example: Try using JCL to invoke z/OS's FTP client to transfer a file to an arbitrary FTP server, specifying a user ID longer than 8 characters. Can it be done? Of course it can; it's perfectly routine. You just don't use JES-related syntax, that's all. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Z/VM LPAR
Never. Dynamic LPAR addition and deletion. On Mon, May 4, 2020 at 12:09 PM Nai, Dean wrote: > > Anyone know if we need a POR to activate a new Z/VM LPAR > > > Dean Nai > > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
Keep in mind that it would be the short userid that would be used to complete
unqualified data set names, except when the prefix is used.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Timothy Sipples [sipp...@sg.ibm.com]
Sent: Monday, May 4, 2020 4:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
Bob Bridges wrote:
>So maybe - maybe, I don't know either - if I sign on to z/OS with a
>certificate, or LDAP, or anything other than the usual, the sign-on
routine
>MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
>everything works fine, I guess.
I don't think RACF itself works that way, or at least the z/OS 2.4
documentation doesn't suggest so. Take a look at this information, for
example:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm
Let's suppose the user is authenticating with RACF (not with the IBM
Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an X.509
client digital certificate for that purpose. RACF has to know ahead of
time whether or not to authenticate that particular user (digital
certificate). So the digital certificate has to be known to RACF ahead of
time. Since the digital certificate has to be known, it's not unreasonable
to associate an up to 8 character "short" user ID with that certificate.
And that's how it works, as I understand it. The user doesn't present the
short user ID -- well, not really, I'll get to this in a moment -- but
RACF can check the certificate and create an ACEE with a mapped short user
ID.
There are three basic choices here as I understand it:
1. A one-to-one mapping (one certificate to short ID ABCD1234). The
documentation does a little bit of handwaving here along the lines of
"this might be difficult to administer," but I'd argue that's somewhat
dated advice now that so many organizations use identity management tools.
2. A many-to-one mapping (multiple certificates to ABCD1234).
3. Either mapping, but with the certificate itself holding an embedded
short name ("hostIdMapping"). Certificate issuers don't typically support
this extension, or at least they hide it well, but the z/OS PKI Services
do. (Is this technique "cheating"? Not really)
In all these cases the user need not be aware there's a short name that
RACF uses "under the covers." The user just supplies a valid, unexpired
client certificate -- from a PIN-protected smart card perhaps. From RACF's
perspective the X.509 digital certificate is really just another alias, a
verbose one.
z/OS LDAP also supports broadly similar RACF ID mapping (supply a long CN,
which the directory maps to a short name), but it's optional. You can
certainly authenticate with LDAP as a standalone matter if you wish.
It's an interesting idea to have a fourth option for digital certificate
authentication with RACF, which would be like choice #1 but without
telling RACF what the short user ID is ahead of time -- to let RACF create
one "on the fly," probably with caching and templating. For example, allow
me to register a bunch of digital certificates in RACF as valid users, but
I'm not going to tell you (RACF) what their short user IDs are ahead of
time. The first time you encounter a particular certificate, just create a
short user ID of C$-- (where the dashes are RACF's randomized or
sequential choice, of any length -- randomized as default, but sequential
as an option), store it, and use that on-the-fly short ID to build the
ACEE. For example. I'd have to ponder that one a bit more, but if you
think you've got a good use case, ask (RFE).
Of course it'd be "nice" to have more than a maximum 8 character ID (with
the current maximum of 39 different characters per position) internally in
RACF, but I imagine that'd be a big plumbing problem and potentially break
a lot of important stuff if not done carefully. Fortunately, you're not
required to limit users' experiences to maximum 8 character user IDs: use
LDAP CNs, use digital certificates, or use something else.
By the way, if someone is looking for an interesting project, I'd be
pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN
and passphrase that's then checked against the IBM Directory Server for
z/OS for authentication (and thus also with the SAF security provider,
indirectly). This part of the z/OS documentation starts to explain how to
do that:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikjb400/logpan.htm
- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Re: z/OS performance question
Thanks, everyone. We are running z/OS v2.1, just upgraded from z/OS v1.12. Over the weekend, I add a second structure to the CLASSDEF SML. Hopefully, that will help with the issues. Thanks again, Jerry From: IBM Mainframe Discussion List on behalf of Michael Babcock Sent: Sunday, May 3, 2020 12:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS performance question This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. If you are on z/OS 2.4 you don’t need to tune the classes. Just turn on auto tuning. On Fri, May 1, 2020 at 1:44 PM Edgington, Jerry < jerry.edging...@westernsouthernlife.com> wrote: > Thanks Allen, that is good place to start. The CPU% for the ISGLOCK, > IXCSTR1 and IXCSTR2 are 58%, 74% and 21%, which seem very high to me. But, > the IXCSTR3 and IXCSTR4 are very low. It would seem I might have an > imbalance with the XCF messages and size. Async rate for IXCSTR1 is 120 > > I am wondering if I need to adjust my CLASSDEF CLASSLEN size for each of > the structures. We are running ICFs on GP, with one virtual connection to > each ICFA/B. Not ideal, but all I could do at the moment. > > > /* TRANSPORT CLASSES. */ > CLASSDEF CLASS(SML) CLASSLEN(956) GROUP(UNDESIG) > CLASSDEF CLASS(MED) CLASSLEN(8000) > CLASSDEF CLASS(DEFAULT) CLASSLEN(16316) > CLASSDEF CLASS(BIG) CLASSLEN(32000) > > /* XCF STRUCTURES */ > PATHOUT STRNAME(IXCSTR1) CLASS(SML) > PATHOUT STRNAME(IXCSTR2) CLASS(MED) > PATHOUT STRNAME(IXCSTR3) CLASS(BIG) > PATHOUT STRNAME(IXCSTR4) CLASS(DEFAULT) > /* */ > PATHIN STRNAME(IXCSTR1,IXCSTR2,IXCSTR3,IXCSTR4) > > Also, we have: > FUNCTIONS ENABLE(DUPLEXCF16, SYSSTATDETECT, CRITICALPAGING) > > Thanks Jerry > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Allan Staller > Sent: Friday, May 1, 2020 2:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS performance question > > This message was sent from an external source outside of Western & > Southern's network. Do not click links or open attachments unless you > recognize the sender and know the contents are safe. > > > > The only tuning I a aware of for XCF is to provide appropriate transport > classes for the messages being passed. If inappropriate, this will usually > show up as CPU concumption in the XCFAS address space. Look at the CPU > consumed, not the delay. > > It is possible that this is contributing to the CICS delays. GRS will use > XCF if available. > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Edgington, Jerry > Sent: Friday, May 1, 2020 12:30 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: z/OS performance question > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > To anyone, > > I am not a performance person at all, but can someone help me with > pointing me in the right direction. We are running a small SYSplex, but we > are getting delays on one LPAR, PROC-XCFAS > > *SYSTEMPROC-XCFAS 3.7 users > ALL STCPROC-XCFAS 3.2 users > IMS PROC-XCFAS 26.0 % delay > RMFPROC-XCFAS 18.0 % delay > RMFGAT PROC-XCFAS 21.0 % delay > IMSCTL PROC-XCFAS 25.0 % delay > TN3270 PROC-XCFAS 28.0 % delay > VTAM PROC-XCFAS 19.0 % delay > > Also, we are ACF2 shop and our production CICS regions are getting delays: > > ENQ -ACFVSAM 38.0 % delay LOGONIDS > ENQ -ACF2ACB 100.0 % delay LOGONIDS > > So any help would be great. > Thanks, > Jerry Edgington > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of
Z/VM LPAR
Anyone know if we need a POR to activate a new Z/VM LPAR Dean Nai > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
This is the whole "bound to another address space" issue. Does it matter what sequence you take the address spaces down in? And I wonder if the same applies to Db2 and MQ. (I would guess not as the binding/attachment must be different.) Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Barbara Nitz To: IBM-MAIN@LISTSERV.UA.EDU Date: 04/05/2020 09:23 Subject:[EXTERNAL] Re: S0F9 and SOFD ABENDs and SVC dumps - oh my! Sent by:IBM Mainframe Discussion List On Thu, 30 Apr 2020 09:09:32 -0400, Peter Relson wrote: > >z/OS FORCE did not work > > >Wanna bet? > >FORCE,ARM runs in the address space so would have been affected. >FORCE does not. Doesn't matter. With an IMS region, you cannot use cancel (z/OS: "non-cancelable, use force arm"). You cannot use force arm (z/OS: "cancel first, please"). And you cannot use force because IMS intercepts that and tells you to terminate the IMS region by de-registering it from IMS. Which doesn't work because it is already *unknown* (i.e. deregistered) in the control region, but the de-registering hasn't made it down the tcbs in that IMS message region. Sometimes the callrtm program worked after the 5th invocation, but sometimes it didn't work even after 10 invocations. (With the dumps to verify it didn't work in between invocations.) IMS message regions are BAD, IMHO. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
Not CESL.
On Mon, May 4, 2020 at 6:40 PM Wayne Bickerdike wrote:
> There are more CICS users than TSO users. Is there a howto for the CICS
> signon screen to accept long IDs and Passphrases?
>
> On Mon, May 4, 2020 at 6:03 PM Timothy Sipples wrote:
>
>> Bob Bridges wrote:
>> >So maybe - maybe, I don't know either - if I sign on to z/OS with a
>> >certificate, or LDAP, or anything other than the usual, the sign-on
>> routine
>> >MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
>> >everything works fine, I guess.
>>
>> I don't think RACF itself works that way, or at least the z/OS 2.4
>> documentation doesn't suggest so. Take a look at this information, for
>> example:
>>
>>
>> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm
>>
>> Let's suppose the user is authenticating with RACF (not with the IBM
>> Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an
>> X.509
>> client digital certificate for that purpose. RACF has to know ahead of
>> time whether or not to authenticate that particular user (digital
>> certificate). So the digital certificate has to be known to RACF ahead of
>> time. Since the digital certificate has to be known, it's not
>> unreasonable
>> to associate an up to 8 character "short" user ID with that certificate.
>> And that's how it works, as I understand it. The user doesn't present the
>> short user ID -- well, not really, I'll get to this in a moment -- but
>> RACF can check the certificate and create an ACEE with a mapped short
>> user
>> ID.
>>
>> There are three basic choices here as I understand it:
>>
>> 1. A one-to-one mapping (one certificate to short ID ABCD1234). The
>> documentation does a little bit of handwaving here along the lines of
>> "this might be difficult to administer," but I'd argue that's somewhat
>> dated advice now that so many organizations use identity management tools.
>>
>> 2. A many-to-one mapping (multiple certificates to ABCD1234).
>>
>> 3. Either mapping, but with the certificate itself holding an embedded
>> short name ("hostIdMapping"). Certificate issuers don't typically support
>> this extension, or at least they hide it well, but the z/OS PKI Services
>> do. (Is this technique "cheating"? Not really)
>>
>> In all these cases the user need not be aware there's a short name that
>> RACF uses "under the covers." The user just supplies a valid, unexpired
>> client certificate -- from a PIN-protected smart card perhaps. From
>> RACF's
>> perspective the X.509 digital certificate is really just another alias, a
>> verbose one.
>>
>> z/OS LDAP also supports broadly similar RACF ID mapping (supply a long
>> CN,
>> which the directory maps to a short name), but it's optional. You can
>> certainly authenticate with LDAP as a standalone matter if you wish.
>>
>> It's an interesting idea to have a fourth option for digital certificate
>> authentication with RACF, which would be like choice #1 but without
>> telling RACF what the short user ID is ahead of time -- to let RACF
>> create
>> one "on the fly," probably with caching and templating. For example,
>> allow
>> me to register a bunch of digital certificates in RACF as valid users,
>> but
>> I'm not going to tell you (RACF) what their short user IDs are ahead of
>> time. The first time you encounter a particular certificate, just create
>> a
>> short user ID of C$-- (where the dashes are RACF's randomized or
>> sequential choice, of any length -- randomized as default, but sequential
>> as an option), store it, and use that on-the-fly short ID to build the
>> ACEE. For example. I'd have to ponder that one a bit more, but if you
>> think you've got a good use case, ask (RFE).
>>
>> Of course it'd be "nice" to have more than a maximum 8 character ID (with
>> the current maximum of 39 different characters per position) internally
>> in
>> RACF, but I imagine that'd be a big plumbing problem and potentially
>> break
>> a lot of important stuff if not done carefully. Fortunately, you're not
>> required to limit users' experiences to maximum 8 character user IDs: use
>> LDAP CNs, use digital certificates, or use something else.
>>
>> By the way, if someone is looking for an interesting project, I'd be
>> pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN
>> and passphrase that's then checked against the IBM Directory Server for
>> z/OS for authentication (and thus also with the SAF security provider,
>> indirectly). This part of the z/OS documentation starts to explain how to
>> do that:
>>
>>
>> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikjb400/logpan.htm
>>
>> - - - - - - - - - -
>> Timothy Sipples
>> I.T. Architect Executive
>> Digital Asset & Other Industry Solutions
>> IBM Z & LinuxONE
>> - - - - - - - - - -
>> E-Mail: sipp...@sg.ibm.com
>>
>> --
>> For IBM-MAIN subscribe /
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
There are more CICS users than TSO users. Is there a howto for the CICS
signon screen to accept long IDs and Passphrases?
On Mon, May 4, 2020 at 6:03 PM Timothy Sipples wrote:
> Bob Bridges wrote:
> >So maybe - maybe, I don't know either - if I sign on to z/OS with a
> >certificate, or LDAP, or anything other than the usual, the sign-on
> routine
> >MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
> >everything works fine, I guess.
>
> I don't think RACF itself works that way, or at least the z/OS 2.4
> documentation doesn't suggest so. Take a look at this information, for
> example:
>
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm
>
> Let's suppose the user is authenticating with RACF (not with the IBM
> Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an X.509
> client digital certificate for that purpose. RACF has to know ahead of
> time whether or not to authenticate that particular user (digital
> certificate). So the digital certificate has to be known to RACF ahead of
> time. Since the digital certificate has to be known, it's not unreasonable
> to associate an up to 8 character "short" user ID with that certificate.
> And that's how it works, as I understand it. The user doesn't present the
> short user ID -- well, not really, I'll get to this in a moment -- but
> RACF can check the certificate and create an ACEE with a mapped short user
> ID.
>
> There are three basic choices here as I understand it:
>
> 1. A one-to-one mapping (one certificate to short ID ABCD1234). The
> documentation does a little bit of handwaving here along the lines of
> "this might be difficult to administer," but I'd argue that's somewhat
> dated advice now that so many organizations use identity management tools.
>
> 2. A many-to-one mapping (multiple certificates to ABCD1234).
>
> 3. Either mapping, but with the certificate itself holding an embedded
> short name ("hostIdMapping"). Certificate issuers don't typically support
> this extension, or at least they hide it well, but the z/OS PKI Services
> do. (Is this technique "cheating"? Not really)
>
> In all these cases the user need not be aware there's a short name that
> RACF uses "under the covers." The user just supplies a valid, unexpired
> client certificate -- from a PIN-protected smart card perhaps. From RACF's
> perspective the X.509 digital certificate is really just another alias, a
> verbose one.
>
> z/OS LDAP also supports broadly similar RACF ID mapping (supply a long CN,
> which the directory maps to a short name), but it's optional. You can
> certainly authenticate with LDAP as a standalone matter if you wish.
>
> It's an interesting idea to have a fourth option for digital certificate
> authentication with RACF, which would be like choice #1 but without
> telling RACF what the short user ID is ahead of time -- to let RACF create
> one "on the fly," probably with caching and templating. For example, allow
> me to register a bunch of digital certificates in RACF as valid users, but
> I'm not going to tell you (RACF) what their short user IDs are ahead of
> time. The first time you encounter a particular certificate, just create a
> short user ID of C$-- (where the dashes are RACF's randomized or
> sequential choice, of any length -- randomized as default, but sequential
> as an option), store it, and use that on-the-fly short ID to build the
> ACEE. For example. I'd have to ponder that one a bit more, but if you
> think you've got a good use case, ask (RFE).
>
> Of course it'd be "nice" to have more than a maximum 8 character ID (with
> the current maximum of 39 different characters per position) internally in
> RACF, but I imagine that'd be a big plumbing problem and potentially break
> a lot of important stuff if not done carefully. Fortunately, you're not
> required to limit users' experiences to maximum 8 character user IDs: use
> LDAP CNs, use digital certificates, or use something else.
>
> By the way, if someone is looking for an interesting project, I'd be
> pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN
> and passphrase that's then checked against the IBM Directory Server for
> z/OS for authentication (and thus also with the SAF security provider,
> indirectly). This part of the z/OS documentation starts to explain how to
> do that:
>
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikjb400/logpan.htm
>
> - - - - - - - - - -
> Timothy Sipples
> I.T. Architect Executive
> Digital Asset & Other Industry Solutions
> IBM Z & LinuxONE
> - - - - - - - - - -
> E-Mail: sipp...@sg.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Wayne V. Bickerdike
Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!
On Thu, 30 Apr 2020 09:09:32 -0400, Peter Relson wrote: > >z/OS FORCE did not work > > >Wanna bet? > >FORCE,ARM runs in the address space so would have been affected. >FORCE does not. Doesn't matter. With an IMS region, you cannot use cancel (z/OS: "non-cancelable, use force arm"). You cannot use force arm (z/OS: "cancel first, please"). And you cannot use force because IMS intercepts that and tells you to terminate the IMS region by de-registering it from IMS. Which doesn't work because it is already *unknown* (i.e. deregistered) in the control region, but the de-registering hasn't made it down the tcbs in that IMS message region. Sometimes the callrtm program worked after the 5th invocation, but sometimes it didn't work even after 10 invocations. (With the dumps to verify it didn't work in between invocations.) IMS message regions are BAD, IMHO. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125)
Bob Bridges wrote:
>So maybe - maybe, I don't know either - if I sign on to z/OS with a
>certificate, or LDAP, or anything other than the usual, the sign-on
routine
>MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that
>everything works fine, I guess.
I don't think RACF itself works that way, or at least the z/OS 2.4
documentation doesn't suggest so. Take a look at this information, for
example:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm
Let's suppose the user is authenticating with RACF (not with the IBM
Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an X.509
client digital certificate for that purpose. RACF has to know ahead of
time whether or not to authenticate that particular user (digital
certificate). So the digital certificate has to be known to RACF ahead of
time. Since the digital certificate has to be known, it's not unreasonable
to associate an up to 8 character "short" user ID with that certificate.
And that's how it works, as I understand it. The user doesn't present the
short user ID -- well, not really, I'll get to this in a moment -- but
RACF can check the certificate and create an ACEE with a mapped short user
ID.
There are three basic choices here as I understand it:
1. A one-to-one mapping (one certificate to short ID ABCD1234). The
documentation does a little bit of handwaving here along the lines of
"this might be difficult to administer," but I'd argue that's somewhat
dated advice now that so many organizations use identity management tools.
2. A many-to-one mapping (multiple certificates to ABCD1234).
3. Either mapping, but with the certificate itself holding an embedded
short name ("hostIdMapping"). Certificate issuers don't typically support
this extension, or at least they hide it well, but the z/OS PKI Services
do. (Is this technique "cheating"? Not really)
In all these cases the user need not be aware there's a short name that
RACF uses "under the covers." The user just supplies a valid, unexpired
client certificate -- from a PIN-protected smart card perhaps. From RACF's
perspective the X.509 digital certificate is really just another alias, a
verbose one.
z/OS LDAP also supports broadly similar RACF ID mapping (supply a long CN,
which the directory maps to a short name), but it's optional. You can
certainly authenticate with LDAP as a standalone matter if you wish.
It's an interesting idea to have a fourth option for digital certificate
authentication with RACF, which would be like choice #1 but without
telling RACF what the short user ID is ahead of time -- to let RACF create
one "on the fly," probably with caching and templating. For example, allow
me to register a bunch of digital certificates in RACF as valid users, but
I'm not going to tell you (RACF) what their short user IDs are ahead of
time. The first time you encounter a particular certificate, just create a
short user ID of C$-- (where the dashes are RACF's randomized or
sequential choice, of any length -- randomized as default, but sequential
as an option), store it, and use that on-the-fly short ID to build the
ACEE. For example. I'd have to ponder that one a bit more, but if you
think you've got a good use case, ask (RFE).
Of course it'd be "nice" to have more than a maximum 8 character ID (with
the current maximum of 39 different characters per position) internally in
RACF, but I imagine that'd be a big plumbing problem and potentially break
a lot of important stuff if not done carefully. Fortunately, you're not
required to limit users' experiences to maximum 8 character user IDs: use
LDAP CNs, use digital certificates, or use something else.
By the way, if someone is looking for an interesting project, I'd be
pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN
and passphrase that's then checked against the IBM Directory Server for
z/OS for authentication (and thus also with the SAF security provider,
indirectly). This part of the z/OS documentation starts to explain how to
do that:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikjb400/logpan.htm
- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
