> You can specify pretty much anything you want in JCL. According to MVS JCL Reference, SA23-1385-40, both USER=abcdefghi and EMAIL=foo+...@patriot.net are illegal. That's not a JES issue.
-- 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: Saturday, May 2, 2020 2: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 ID, >inside z/OS the system is still using an 8-byte ID. But "who cares?" Users presenting longer IDs or client certificates certainly don't. "If a tree falls in the woods...." As long as there is at least adequate granularity in providing enough different security contexts it shouldn't particularly matter. For all we know (and I don't know) RACF already does something internally that has more breadth than maximum 8 character TSO/E user IDs would ordinarily suggest. Analogously, does it matter much that Microsoft Windows still only supports a maximum of 26 single character drive letters (A to Z)? Not really, no. Microsoft (and IBM) sidestepped that limitation a long time ago by providing an alternate way to refer to disks: \\DiskABC123456\... (for example). Older software (that only understands D:\...) doesn't break because you can assign and reassign the old drive letters, while newer software and user interfaces forge ahead. You then decide whether and how quickly you'd like to move forward. I think it's much the same here. There are lots of applications and subsystems that run on z/OS that expect user IDs (or "user IDs") up to 8 characters maximum, but that's not how you must present the world to users. Go ahead and use these LDAP and/or client certificate authentication technologies as/where you like. If you have z/OS you have the former, and if you have RACF you have the latter, too. And if something is missing, ask! (RFEs.) - - - - - - - - - - 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
