Re: SMF to capture user login history
On 27/10/2020 2:53 am, Paul Gilmartin wrote: Does that include OMVS fork()? Seems like overkill given that some jobs may do copious forks. OMVS can produce a lot of SMF records. I did some testing on a short shell script, and 1000 iterations of a loop produced about 28,000 type 30 records - around 200 records/second. The good news is that the records are likely small with very similar data, so the facilities to compress SMF data should handle it nicely. I wrote up the testing here, and it gives some idea of when separate address spaces are used and SMF records written: https://www.blackhillsoftware.com/news/2019/08/27/comparing-bash-and-bin-sh-on-z-os/ Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Yes. But to do this, you will need to switch off "list of groups" processing. This option was introduced in the 1980s and most shops decided to turn it on. The concept of the "connect group" as the group specified at logon time (or if you like RACINIT time) has largely gone. What you ask could also be performed in various RACF exits of course. Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: 26 October 2020 16:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Curious question. Is it possible to have a single user ID with different privileges depending on what group you specify when logging in (to TSO, for example)? From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Sunday, October 25, 2020 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history > two sets of IDs Multiple ids can be very usefull. If you have a lot of privileges and write code that is supposed to work without those privileges, it's useful to have a bare bones userid. If you have work that requires privileges that you consider too dangerous for normal work, it's nice to have a more privileged userid and proxy permission. BTDT, GTTS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Horein [steve.hor...@gmail.com] Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > Meh. The first shop I worked in implemented something like that to track the use of privileged IDs that had elevated permissions to update production resources. At the time, the scope had been TSO, so I wrote some automation that would send an email to the "security operations center" if RACF IDs matching specific patterns generated an IEF125I, IEF126I, or an IEF45* message. The time frames from logon to logoff/abend needed to be justified with a change request or incident, otherwise it would be considered suspicious activity. Yes, it meant having to maintain two sets of IDs - a BAU ID for day to day work, and the privileged ID for changes or recovery support, but it satisfied someone's requirement. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Right. Was hoping to be able to do it with a single user ID. Oh well! From: IBM Mainframe Discussion List on behalf of Allan Staller Sent: Monday, October 26, 2020 1:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Classification: Internal That would require an additional longon ID with a different default group/grouplist. This is a fairly common practice. One ID for everyday use and another with elevated privileges when needed. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Monday, October 26, 2020 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history [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.] Thanks. Looks like there is not a way to do what I was hoping for, which would allow for a set of default groups for a user, along with one or more groups that require a user to explicitly log in to use them. For example, I am a member of 3 groups right now, and we must use GRPLIST because I don't have to specify a particular group to have my rights for all three. I would like to have an additional group available to me, but only if I explicitly specify it. In that case I would want to have the rights for all four groups. I would also want to be able to "log" any time I (or any user) log in to this "special access" fourth group. Sounds like I am out of luck here, but someone correct me if I'm wrong. From: IBM Mainframe Discussion List on behalf of R.S. Sent: Monday, October 26, 2020 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Yes, obviously! But ...no. To explain: there is an option in RACF, called GRPLIST. Vast majority of installations use GRPLIST, but few use NOGRPLIST. 1. YES For NOGRPLIST you may belong to meny group, but only one connection at the time is "active" - that means you logon as Frank, FRANK1 (that's the password) and NETADM - that's the group. And you have all the authorities given to user FRANK and to group NETADM. However you are member of SMSADM as well - but this group gives you no authorities, because only one group is taken. Is it stupid? Some people say it is good. Let's leave it. 2. NO In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it doesn't matter what group you provide, if any. And you have all the authorities given to FRANK, NETADM, SMSADM and all other groups you are connected to. So, it in this case privileges are not different. Exception: there are very few, very rare cases when "current connect group" is important even in GRPLIST. See ARCCATGP (DFSMShsm manual). However AFAIR it is enough to provide this groupname during logon. Remark: no group provided = default group. Every RACF user has default group assigned. And of course the user is connected to this group. HTH -- Radoslaw Skorupka Lodz, Poland W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze: > Curious question. Is it possible to have a single user ID with different > privileges depending on what group you specify when logging in (to TSO, for > example)? > > > From: IBM Mainframe Discussion List on > behalf of Seymour J Metz > Sent: Sunday, October 25, 2020 8:05 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > >> two sets of IDs > Multiple ids can be very usefull. If you have a lot of privileges and write > code that is supposed to work without those privileges, it's useful to have a > bare bones userid. If you have work that requires privileges that you > consider too dangerous for normal work, it's nice to have a more privileged > userid and proxy permission. BTDT, GTTS. > > > -- > Shmuel (Seymour J.) Metz > https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g > mu.edu%2F~smetz3data=04%7C01%7Callan.staller%40HCL.COM%7C0eaac4d6 > fb9245e9d75c08d879df9a98%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C > 637393349175371164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ew8aS0sA5X7qu > EdwJZayOILNENkQsBhqgCYRSDOqkeQ%3Dreserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Steve Horein [steve.hor...@gmail.com] > Sent: Sunday, October 25, 2020 9:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < > 02dee3fcae33-dmarc
Re: SMF to capture user login history
Then yes. I think the last time this was surveyed n RACF-L, very few shops run with it inactive. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Seymour J Metz > Sent: Monday, October 26, 2020 2:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > And if it's inactive? > > > -- > Shmuel (Seymour J.) Metz > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg > BY0HMszNaDT!6GGUMaN8Y-sqd- > iROsg5T9RjNGe6TerOX71ZS_Y9z1ADewg8U0vrHUcUyMLEnA$ > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Gibney, Dave [gib...@wsu.edu] > Sent: Monday, October 26, 2020 5:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > In general and with list of groups active, no. The only case of specific logon > group dependency I know of is the DFHSM situation Radoslaw mentioned. > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Seymour J Metz > > Sent: Monday, October 26, 2020 1:35 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SMF to capture user login history > > > > If foo is connected to groups bar and baz, don't you get different > permissions > > with LOGON FOO GROUP(BAR) and LOGON FOO GROUP(BAZ)? > > > > > > -- > > Shmuel (Seymour J.) Metz > > > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg > > > BY0HMszNaDT!6A2a7swnD99n20E9woQiB5vEDqC1oZzshsL6LOJZdhrQIdFEepZ > > i5aTQDQEx9A$ > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > > behalf of Allan Staller [allan.stal...@hcl.com] > > Sent: Monday, October 26, 2020 3:03 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SMF to capture user login history > > > > Classification: Internal > > > > That would require an additional longon ID with a different default > > group/grouplist. > > This is a fairly common practice. One ID for everyday use and another with > > elevated privileges when needed. > > > > HTH, > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Frank Swarbrick > > Sent: Monday, October 26, 2020 1:47 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SMF to capture user login history > > > > [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.] > > > > Thanks. > > Looks like there is not a way to do what I was hoping for, which would allow > > for a set of default groups for a user, along with one or more groups that > > require a user to explicitly log in to use them. For example, I am a member > of > > 3 groups right now, and we must use GRPLIST because I don't have to > specify > > a particular group to have my rights for all three. I would like to have an > > additional group available to me, but only if I explicitly specify it. In > > that > case I > > would want to have the rights for all four groups. I would also want to be > > able to "log" any time I (or any user) log in to this "special access" > > fourth > > group. > > > > Sounds like I am out of luck here, but someone correct me if I'm wrong. > > > > > > From: IBM Mainframe Discussion List on > > behalf of R.S. > > Sent: Monday, October 26, 2020 11:18 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SMF to capture user login history > > > > Yes, obviously! > > But ...no. > > > > To explain: there is an option in RACF, called GRPLIST. Vast majority of > > installations use GRPLIST, but few use NOGRPLIST. > > > > 1. YES > > For NOGRPLIST you may belong to meny group, but only one connection at > > the time is "active" - that means you logon as Frank, FRANK1 (that's the > > password) and NETADM - that's the group. > > And you have all the authorities given to user FRANK and to group > NETADM. > > However you are member of SMSADM as well - but this group gives you no > > authorities, because only one group is taken. > > Is it stupid? Some people say it is good. Let's leave it. > > > > > > 2. NO > > In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it > doesn't > >
Re: SMF to capture user login history
And if it's inactive? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Gibney, Dave [gib...@wsu.edu] Sent: Monday, October 26, 2020 5:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history In general and with list of groups active, no. The only case of specific logon group dependency I know of is the DFHSM situation Radoslaw mentioned. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Seymour J Metz > Sent: Monday, October 26, 2020 1:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > If foo is connected to groups bar and baz, don't you get different permissions > with LOGON FOO GROUP(BAR) and LOGON FOO GROUP(BAZ)? > > > -- > Shmuel (Seymour J.) Metz > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg > BY0HMszNaDT!6A2a7swnD99n20E9woQiB5vEDqC1oZzshsL6LOJZdhrQIdFEepZ > i5aTQDQEx9A$ > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Allan Staller [allan.stal...@hcl.com] > Sent: Monday, October 26, 2020 3:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > Classification: Internal > > That would require an additional longon ID with a different default > group/grouplist. > This is a fairly common practice. One ID for everyday use and another with > elevated privileges when needed. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Frank Swarbrick > Sent: Monday, October 26, 2020 1:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > [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.] > > Thanks. > Looks like there is not a way to do what I was hoping for, which would allow > for a set of default groups for a user, along with one or more groups that > require a user to explicitly log in to use them. For example, I am a member > of > 3 groups right now, and we must use GRPLIST because I don't have to specify > a particular group to have my rights for all three. I would like to have an > additional group available to me, but only if I explicitly specify it. In > that case I > would want to have the rights for all four groups. I would also want to be > able to "log" any time I (or any user) log in to this "special access" fourth > group. > > Sounds like I am out of luck here, but someone correct me if I'm wrong. > > ________ > From: IBM Mainframe Discussion List on > behalf of R.S. > Sent: Monday, October 26, 2020 11:18 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > Yes, obviously! > But ...no. > > To explain: there is an option in RACF, called GRPLIST. Vast majority of > installations use GRPLIST, but few use NOGRPLIST. > > 1. YES > For NOGRPLIST you may belong to meny group, but only one connection at > the time is "active" - that means you logon as Frank, FRANK1 (that's the > password) and NETADM - that's the group. > And you have all the authorities given to user FRANK and to group NETADM. > However you are member of SMSADM as well - but this group gives you no > authorities, because only one group is taken. > Is it stupid? Some people say it is good. Let's leave it. > > > 2. NO > In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it doesn't > matter what group you provide, if any. > And you have all the authorities given to FRANK, NETADM, SMSADM and all > other groups you are connected to. > So, it in this case privileges are not different. > > Exception: there are very few, very rare cases when "current connect group" > is important even in GRPLIST. See ARCCATGP (DFSMShsm manual). > However AFAIR it is enough to provide this groupname during logon. > > Remark: no group provided = default group. Every RACF user has default > group assigned. And of course the user is connected to this group. > > HTH > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze: > > Curious question. Is it possible to have a single user ID with different > privileges depending on what group you specify when logging in (to TSO, for > example)? > > > > > > From: IBM Mainframe Discus
Re: SMF to capture user login history
In general and with list of groups active, no. The only case of specific logon group dependency I know of is the DFHSM situation Radoslaw mentioned. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Seymour J Metz > Sent: Monday, October 26, 2020 1:35 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > If foo is connected to groups bar and baz, don't you get different permissions > with LOGON FOO GROUP(BAR) and LOGON FOO GROUP(BAZ)? > > > -- > Shmuel (Seymour J.) Metz > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg > BY0HMszNaDT!6A2a7swnD99n20E9woQiB5vEDqC1oZzshsL6LOJZdhrQIdFEepZ > i5aTQDQEx9A$ > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Allan Staller [allan.stal...@hcl.com] > Sent: Monday, October 26, 2020 3:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > Classification: Internal > > That would require an additional longon ID with a different default > group/grouplist. > This is a fairly common practice. One ID for everyday use and another with > elevated privileges when needed. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Frank Swarbrick > Sent: Monday, October 26, 2020 1:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > [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.] > > Thanks. > Looks like there is not a way to do what I was hoping for, which would allow > for a set of default groups for a user, along with one or more groups that > require a user to explicitly log in to use them. For example, I am a member > of > 3 groups right now, and we must use GRPLIST because I don't have to specify > a particular group to have my rights for all three. I would like to have an > additional group available to me, but only if I explicitly specify it. In > that case I > would want to have the rights for all four groups. I would also want to be > able to "log" any time I (or any user) log in to this "special access" fourth > group. > > Sounds like I am out of luck here, but someone correct me if I'm wrong. > > ________ > From: IBM Mainframe Discussion List on > behalf of R.S. > Sent: Monday, October 26, 2020 11:18 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > Yes, obviously! > But ...no. > > To explain: there is an option in RACF, called GRPLIST. Vast majority of > installations use GRPLIST, but few use NOGRPLIST. > > 1. YES > For NOGRPLIST you may belong to meny group, but only one connection at > the time is "active" - that means you logon as Frank, FRANK1 (that's the > password) and NETADM - that's the group. > And you have all the authorities given to user FRANK and to group NETADM. > However you are member of SMSADM as well - but this group gives you no > authorities, because only one group is taken. > Is it stupid? Some people say it is good. Let's leave it. > > > 2. NO > In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it doesn't > matter what group you provide, if any. > And you have all the authorities given to FRANK, NETADM, SMSADM and all > other groups you are connected to. > So, it in this case privileges are not different. > > Exception: there are very few, very rare cases when "current connect group" > is important even in GRPLIST. See ARCCATGP (DFSMShsm manual). > However AFAIR it is enough to provide this groupname during logon. > > Remark: no group provided = default group. Every RACF user has default > group assigned. And of course the user is connected to this group. > > HTH > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze: > > Curious question. Is it possible to have a single user ID with different > privileges depending on what group you specify when logging in (to TSO, for > example)? > > > > > > From: IBM Mainframe Discussion List on > > behalf of Seymour J Metz > > Sent: Sunday, October 25, 2020 8:05 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: SMF to capture user login history > > > >> two sets of IDs > > Multiple ids can be very usefull. If you have a lot of privileges a
Re: SMF to capture user login history
If foo is connected to groups bar and baz, don't you get different permissions with LOGON FOO GROUP(BAR) and LOGON FOO GROUP(BAZ)? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Allan Staller [allan.stal...@hcl.com] Sent: Monday, October 26, 2020 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Classification: Internal That would require an additional longon ID with a different default group/grouplist. This is a fairly common practice. One ID for everyday use and another with elevated privileges when needed. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Monday, October 26, 2020 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history [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.] Thanks. Looks like there is not a way to do what I was hoping for, which would allow for a set of default groups for a user, along with one or more groups that require a user to explicitly log in to use them. For example, I am a member of 3 groups right now, and we must use GRPLIST because I don't have to specify a particular group to have my rights for all three. I would like to have an additional group available to me, but only if I explicitly specify it. In that case I would want to have the rights for all four groups. I would also want to be able to "log" any time I (or any user) log in to this "special access" fourth group. Sounds like I am out of luck here, but someone correct me if I'm wrong. From: IBM Mainframe Discussion List on behalf of R.S. Sent: Monday, October 26, 2020 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Yes, obviously! But ...no. To explain: there is an option in RACF, called GRPLIST. Vast majority of installations use GRPLIST, but few use NOGRPLIST. 1. YES For NOGRPLIST you may belong to meny group, but only one connection at the time is "active" - that means you logon as Frank, FRANK1 (that's the password) and NETADM - that's the group. And you have all the authorities given to user FRANK and to group NETADM. However you are member of SMSADM as well - but this group gives you no authorities, because only one group is taken. Is it stupid? Some people say it is good. Let's leave it. 2. NO In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it doesn't matter what group you provide, if any. And you have all the authorities given to FRANK, NETADM, SMSADM and all other groups you are connected to. So, it in this case privileges are not different. Exception: there are very few, very rare cases when "current connect group" is important even in GRPLIST. See ARCCATGP (DFSMShsm manual). However AFAIR it is enough to provide this groupname during logon. Remark: no group provided = default group. Every RACF user has default group assigned. And of course the user is connected to this group. HTH -- Radoslaw Skorupka Lodz, Poland W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze: > Curious question. Is it possible to have a single user ID with different > privileges depending on what group you specify when logging in (to TSO, for > example)? > > > From: IBM Mainframe Discussion List on > behalf of Seymour J Metz > Sent: Sunday, October 25, 2020 8:05 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > >> two sets of IDs > Multiple ids can be very usefull. If you have a lot of privileges and write > code that is supposed to work without those privileges, it's useful to have a > bare bones userid. If you have work that requires privileges that you > consider too dangerous for normal work, it's nice to have a more privileged > userid and proxy permission. BTDT, GTTS. > > > -- > Shmuel (Seymour J.) Metz > https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g > mu.edu%2F~smetz3data=04%7C01%7Callan.staller%40HCL.COM%7C0eaac4d6 > fb9245e9d75c08d879df9a98%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C > 637393349175371164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ew8aS0sA5X7qu > EdwJZayOILNENkQsBhqgCYRSDOqkeQ%3Dreserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Steve Horein [steve.hor...@gmail.com] > Sent: Sunday, October 25, 2020 9:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture
Re: SMF to capture user login history
Classification: Internal That would require an additional longon ID with a different default group/grouplist. This is a fairly common practice. One ID for everyday use and another with elevated privileges when needed. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Monday, October 26, 2020 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history [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.] Thanks. Looks like there is not a way to do what I was hoping for, which would allow for a set of default groups for a user, along with one or more groups that require a user to explicitly log in to use them. For example, I am a member of 3 groups right now, and we must use GRPLIST because I don't have to specify a particular group to have my rights for all three. I would like to have an additional group available to me, but only if I explicitly specify it. In that case I would want to have the rights for all four groups. I would also want to be able to "log" any time I (or any user) log in to this "special access" fourth group. Sounds like I am out of luck here, but someone correct me if I'm wrong. From: IBM Mainframe Discussion List on behalf of R.S. Sent: Monday, October 26, 2020 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Yes, obviously! But ...no. To explain: there is an option in RACF, called GRPLIST. Vast majority of installations use GRPLIST, but few use NOGRPLIST. 1. YES For NOGRPLIST you may belong to meny group, but only one connection at the time is "active" - that means you logon as Frank, FRANK1 (that's the password) and NETADM - that's the group. And you have all the authorities given to user FRANK and to group NETADM. However you are member of SMSADM as well - but this group gives you no authorities, because only one group is taken. Is it stupid? Some people say it is good. Let's leave it. 2. NO In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it doesn't matter what group you provide, if any. And you have all the authorities given to FRANK, NETADM, SMSADM and all other groups you are connected to. So, it in this case privileges are not different. Exception: there are very few, very rare cases when "current connect group" is important even in GRPLIST. See ARCCATGP (DFSMShsm manual). However AFAIR it is enough to provide this groupname during logon. Remark: no group provided = default group. Every RACF user has default group assigned. And of course the user is connected to this group. HTH -- Radoslaw Skorupka Lodz, Poland W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze: > Curious question. Is it possible to have a single user ID with different > privileges depending on what group you specify when logging in (to TSO, for > example)? > > > From: IBM Mainframe Discussion List on > behalf of Seymour J Metz > Sent: Sunday, October 25, 2020 8:05 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > >> two sets of IDs > Multiple ids can be very usefull. If you have a lot of privileges and write > code that is supposed to work without those privileges, it's useful to have a > bare bones userid. If you have work that requires privileges that you > consider too dangerous for normal work, it's nice to have a more privileged > userid and proxy permission. BTDT, GTTS. > > > -- > Shmuel (Seymour J.) Metz > https://apc01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g > mu.edu%2F~smetz3data=04%7C01%7Callan.staller%40HCL.COM%7C0eaac4d6 > fb9245e9d75c08d879df9a98%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C > 637393349175371164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=ew8aS0sA5X7qu > EdwJZayOILNENkQsBhqgCYRSDOqkeQ%3Dreserved=0 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Steve Horein [steve.hor...@gmail.com] > Sent: Sunday, October 25, 2020 9:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > >> I hope no one encourages this kind of snooping on the list. >> Stinks of an attempt to police working hours. >> >> - KB >> == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym
Re: SMF to capture user login history
Thanks. Looks like there is not a way to do what I was hoping for, which would allow for a set of default groups for a user, along with one or more groups that require a user to explicitly log in to use them. For example, I am a member of 3 groups right now, and we must use GRPLIST because I don't have to specify a particular group to have my rights for all three. I would like to have an additional group available to me, but only if I explicitly specify it. In that case I would want to have the rights for all four groups. I would also want to be able to "log" any time I (or any user) log in to this "special access" fourth group. Sounds like I am out of luck here, but someone correct me if I'm wrong. From: IBM Mainframe Discussion List on behalf of R.S. Sent: Monday, October 26, 2020 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Yes, obviously! But ...no. To explain: there is an option in RACF, called GRPLIST. Vast majority of installations use GRPLIST, but few use NOGRPLIST. 1. YES For NOGRPLIST you may belong to meny group, but only one connection at the time is "active" - that means you logon as Frank, FRANK1 (that's the password) and NETADM - that's the group. And you have all the authorities given to user FRANK and to group NETADM. However you are member of SMSADM as well - but this group gives you no authorities, because only one group is taken. Is it stupid? Some people say it is good. Let's leave it. 2. NO In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it doesn't matter what group you provide, if any. And you have all the authorities given to FRANK, NETADM, SMSADM and all other groups you are connected to. So, it in this case privileges are not different. Exception: there are very few, very rare cases when "current connect group" is important even in GRPLIST. See ARCCATGP (DFSMShsm manual). However AFAIR it is enough to provide this groupname during logon. Remark: no group provided = default group. Every RACF user has default group assigned. And of course the user is connected to this group. HTH -- Radoslaw Skorupka Lodz, Poland W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze: > Curious question. Is it possible to have a single user ID with different > privileges depending on what group you specify when logging in (to TSO, for > example)? > > > From: IBM Mainframe Discussion List on behalf of > Seymour J Metz > Sent: Sunday, October 25, 2020 8:05 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > >> two sets of IDs > Multiple ids can be very usefull. If you have a lot of privileges and write > code that is supposed to work without those privileges, it's useful to have a > bare bones userid. If you have work that requires privileges that you > consider too dangerous for normal work, it's nice to have a more privileged > userid and proxy permission. BTDT, GTTS. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Steve Horein [steve.hor...@gmail.com] > Sent: Sunday, October 25, 2020 9:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > >> I hope no one encourages this kind of snooping on the list. >> Stinks of an attempt to police working hours. >> >> - KB >> == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, di
Re: SMF to capture user login history
W dniu 26.10.2020 o 18:14, Charles Mills pisze: No. The OP did not specify TSO (or any other subsystem). The OP wrote "I would like to fetch a user's logon history like when he was logged with all time intervals." I have no time to check it, so I may be wrong, but I believe every logon cut SMF80 with RACINITI. Note: in order to check it one should logon using all available ways - job, TSO, ftp, RMF, CICS, DRDA, telnet, ssh, console, whatever. And then make IRRADU00 report and find all the cases. Remarks: 1. Unsuccesful logon is visible quite better - ICH408I in syslog. However it is not the same as succesful logon. 2. Logoff is much more complex - especially when user forgot to logoff and left the session. 3. I'm not sure but maybe UAUDIT makes more traces of the logon. Obviously it will not change the past. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Yes, obviously! But ...no. To explain: there is an option in RACF, called GRPLIST. Vast majority of installations use GRPLIST, but few use NOGRPLIST. 1. YES For NOGRPLIST you may belong to meny group, but only one connection at the time is "active" - that means you logon as Frank, FRANK1 (that's the password) and NETADM - that's the group. And you have all the authorities given to user FRANK and to group NETADM. However you are member of SMSADM as well - but this group gives you no authorities, because only one group is taken. Is it stupid? Some people say it is good. Let's leave it. 2. NO In typical GRPLIST world you logon as FRANK/FRANK1 and (usually) it doesn't matter what group you provide, if any. And you have all the authorities given to FRANK, NETADM, SMSADM and all other groups you are connected to. So, it in this case privileges are not different. Exception: there are very few, very rare cases when "current connect group" is important even in GRPLIST. See ARCCATGP (DFSMShsm manual). However AFAIR it is enough to provide this groupname during logon. Remark: no group provided = default group. Every RACF user has default group assigned. And of course the user is connected to this group. HTH -- Radoslaw Skorupka Lodz, Poland W dniu 26.10.2020 o 17:30, Frank Swarbrick pisze: Curious question. Is it possible to have a single user ID with different privileges depending on what group you specify when logging in (to TSO, for example)? From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Sunday, October 25, 2020 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history two sets of IDs Multiple ids can be very usefull. If you have a lot of privileges and write code that is supposed to work without those privileges, it's useful to have a bare bones userid. If you have work that requires privileges that you consider too dangerous for normal work, it's nice to have a more privileged userid and proxy permission. BTDT, GTTS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Horein [steve.hor...@gmail.com] Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: I hope no one encourages this kind of snooping on the list. Stinks of an attempt to police working hours. - KB == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
No. The OP did not specify TSO (or any other subsystem). The OP wrote "I would like to fetch a user's logon history like when he was logged with all time intervals." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Monday, October 26, 2020 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Classification: Internal I believe it does. However, the OP was asking about TSO. In that case, the answer is definitely yes. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, October 26, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history [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.] On Mon, 26 Oct 2020 14:33:38 +, Allan Staller wrote: > >Type 30 is generated at address space creation for all work. > Does that include OMVS fork()? Seems like overkill given that some jobs may do copious forks. Does ATTACH, which doesn't create an address space, get logged likewise? -- gil -- 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 attachments, please check them for viruses and other defects. -- 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: SMF to capture user login history
A multiuser address space like CICS or Wylbur will not cut type 30 records for users logging on and logging off. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jake Anderson [justmainfra...@gmail.com] Sent: Monday, October 26, 2020 9:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Hello Thank you. What If the end user is using an SNA application without tso ? Can I still use record 30 ? On Mon, 26 Oct, 2020, 4:58 pm Allan Staller, wrote: > Classification: Internal > > Type 30 subtype 4 or 5 > > Will be generated for each TSO LOGON. Also SMF type 4, SMF type 5, could > be used as an alternative (if you still have them). > > Parsing out the 1 section of the type 30 , subtype 4 or 5 is pretty > trivial. Althoulg variable in format, that section of the record is pretty > much fixed. > > HTH, > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Lizette Koehler > Sent: Sunday, October 25, 2020 1:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > [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.] > > Which SMF Records are you going to use? > > I would say in general without a 3rd part product (like SAS) it will be a > challenge to parse through MOST SMF records without something that can > handle the record section offsets > > Lizette > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Jake Anderson > Sent: Saturday, October 24, 2020 11:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMF to capture user login history > > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > -- > 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 attachments, please check them for viruses and > other defects. > > > -- > 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: SMF to capture user login history
Yes, and that may be the most reasonable way to go for some installations; the devil is in the details. -- 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, October 26, 2020 12:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Curious question. Is it possible to have a single user ID with different privileges depending on what group you specify when logging in (to TSO, for example)? From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Sunday, October 25, 2020 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history > two sets of IDs Multiple ids can be very usefull. If you have a lot of privileges and write code that is supposed to work without those privileges, it's useful to have a bare bones userid. If you have work that requires privileges that you consider too dangerous for normal work, it's nice to have a more privileged userid and proxy permission. BTDT, GTTS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Horein [steve.hor...@gmail.com] Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > Meh. The first shop I worked in implemented something like that to track the use of privileged IDs that had elevated permissions to update production resources. At the time, the scope had been TSO, so I wrote some automation that would send an email to the "security operations center" if RACF IDs matching specific patterns generated an IEF125I, IEF126I, or an IEF45* message. The time frames from logon to logoff/abend needed to be justified with a change request or incident, otherwise it would be considered suspicious activity. Yes, it meant having to maintain two sets of IDs - a BAU ID for day to day work, and the privileged ID for changes or recovery support, but it satisfied someone's requirement. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Classification: Internal I believe it does. However, the OP was asking about TSO. In that case, the answer is definitely yes. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, October 26, 2020 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history [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.] On Mon, 26 Oct 2020 14:33:38 +, Allan Staller wrote: > >Type 30 is generated at address space creation for all work. > Does that include OMVS fork()? Seems like overkill given that some jobs may do copious forks. Does ATTACH, which doesn't create an address space, get logged likewise? -- gil -- 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 attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
GTF -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Monday, October 26, 2020 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Mon, 26 Oct 2020 14:33:38 +, Allan Staller wrote: > >Type 30 is generated at address space creation for all work. > Does that include OMVS fork()? Seems like overkill given that some jobs may do copious forks. Does ATTACH, which doesn't create an address space, get logged likewise? -- gil -- 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: SMF to capture user login history
No. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, October 26, 2020 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Mon, 26 Oct 2020 14:33:38 +, Allan Staller wrote: > >Type 30 is generated at address space creation for all work. > Does that include OMVS fork()? Seems like overkill given that some jobs may do copious forks. Does ATTACH, which doesn't create an address space, get logged likewise? -- gil -- 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: SMF to capture user login history
Curious question. Is it possible to have a single user ID with different privileges depending on what group you specify when logging in (to TSO, for example)? From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Sunday, October 25, 2020 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history > two sets of IDs Multiple ids can be very usefull. If you have a lot of privileges and write code that is supposed to work without those privileges, it's useful to have a bare bones userid. If you have work that requires privileges that you consider too dangerous for normal work, it's nice to have a more privileged userid and proxy permission. BTDT, GTTS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Horein [steve.hor...@gmail.com] Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > Meh. The first shop I worked in implemented something like that to track the use of privileged IDs that had elevated permissions to update production resources. At the time, the scope had been TSO, so I wrote some automation that would send an email to the "security operations center" if RACF IDs matching specific patterns generated an IEF125I, IEF126I, or an IEF45* message. The time frames from logon to logoff/abend needed to be justified with a change request or incident, otherwise it would be considered suspicious activity. Yes, it meant having to maintain two sets of IDs - a BAU ID for day to day work, and the privileged ID for changes or recovery support, but it satisfied someone's requirement. -- 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: SMF to capture user login history
On Mon, 26 Oct 2020 14:33:38 +, Allan Staller wrote: > >Type 30 is generated at address space creation for all work. > Does that include OMVS fork()? Seems like overkill given that some jobs may do copious forks. Does ATTACH, which doesn't create an address space, get logged likewise? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Classification: Internal Type 30 is generated at address space creation for all work. This would not apply to (e.g. CICS logons). That information would be provided by CICS. CICS Would cut type 30's, but those would be for the CICS address space, not the individual logons within the address space. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: Monday, October 26, 2020 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history [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.] Hello Thank you. What If the end user is using an SNA application without tso ? Can I still use record 30 ? On Mon, 26 Oct, 2020, 4:58 pm Allan Staller, wrote: > Classification: Internal > > Type 30 subtype 4 or 5 > > Will be generated for each TSO LOGON. Also SMF type 4, SMF type 5, > could be used as an alternative (if you still have them). > > Parsing out the 1 section of the type 30 , subtype 4 or 5 is pretty > trivial. Althoulg variable in format, that section of the record is > pretty much fixed. > > HTH, > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Lizette Koehler > Sent: Sunday, October 25, 2020 1:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > [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.] > > Which SMF Records are you going to use? > > I would say in general without a 3rd part product (like SAS) it will > be a challenge to parse through MOST SMF records without something > that can handle the record section offsets > > Lizette > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jake Anderson > Sent: Saturday, October 24, 2020 11:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMF to capture user login history > > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's > logon history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to > use any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > -- > 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 attachments, please check them for viruses and other defects. > > > -- > 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: SMF to capture user login history
Classification: Internal YES -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: Monday, October 26, 2020 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history [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.] Hello Thank you. What If the end user is using an SNA application without tso ? Can I still use record 30 ? On Mon, 26 Oct, 2020, 4:58 pm Allan Staller, wrote: > Classification: Internal > > Type 30 subtype 4 or 5 > > Will be generated for each TSO LOGON. Also SMF type 4, SMF type 5, > could be used as an alternative (if you still have them). > > Parsing out the 1 section of the type 30 , subtype 4 or 5 is pretty > trivial. Althoulg variable in format, that section of the record is > pretty much fixed. > > HTH, > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Lizette Koehler > Sent: Sunday, October 25, 2020 1:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > [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.] > > Which SMF Records are you going to use? > > I would say in general without a 3rd part product (like SAS) it will > be a challenge to parse through MOST SMF records without something > that can handle the record section offsets > > Lizette > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jake Anderson > Sent: Saturday, October 24, 2020 11:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMF to capture user login history > > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's > logon history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to > use any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > -- > 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 attachments, please check them for viruses and other defects. > > > -- > 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: SMF to capture user login history
Probably not, but more details would be necessary. "An SNA application" is a pretty wide net. APPC transactions are potentially recorded in SMF 30. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson Sent: Monday, October 26, 2020 6:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Hello Thank you. What If the end user is using an SNA application without tso ? Can I still use record 30 ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Hello Thank you. What If the end user is using an SNA application without tso ? Can I still use record 30 ? On Mon, 26 Oct, 2020, 4:58 pm Allan Staller, wrote: > Classification: Internal > > Type 30 subtype 4 or 5 > > Will be generated for each TSO LOGON. Also SMF type 4, SMF type 5, could > be used as an alternative (if you still have them). > > Parsing out the 1 section of the type 30 , subtype 4 or 5 is pretty > trivial. Althoulg variable in format, that section of the record is pretty > much fixed. > > HTH, > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Lizette Koehler > Sent: Sunday, October 25, 2020 1:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > [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.] > > Which SMF Records are you going to use? > > I would say in general without a 3rd part product (like SAS) it will be a > challenge to parse through MOST SMF records without something that can > handle the record section offsets > > Lizette > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Jake Anderson > Sent: Saturday, October 24, 2020 11:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMF to capture user login history > > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > -- > 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 attachments, please check them for viruses and > other defects. > > > -- > 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: SMF to capture user login history
Classification: Internal Type 30 subtype 4 or 5 Will be generated for each TSO LOGON. Also SMF type 4, SMF type 5, could be used as an alternative (if you still have them). Parsing out the 1 section of the type 30 , subtype 4 or 5 is pretty trivial. Althoulg variable in format, that section of the record is pretty much fixed. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Sunday, October 25, 2020 1:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history [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.] Which SMF Records are you going to use? I would say in general without a 3rd part product (like SAS) it will be a challenge to parse through MOST SMF records without something that can handle the record section offsets Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: Saturday, October 24, 2020 11:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF to capture user login history Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. Could someone please share any sample if you have and willing to share ? Jake -- 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 attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Yes, To be correct and accurate: z/OS with RACF. And correct SMF customization - that means SMF30 and SMF80 are collected. And SMF data are archived. That mean one may read SMF archives using IRRADU00. The output is (huge) text file, quite well described in RACF Macros and Interfaces manual. The one can use ICETOOL (separetely another licenced program!) or any other tool to extract relevant records and format the report. Regarding legal point of view - this is another issue, it is not related to mainframe. However I can imagine valid reasons to prepare such report, even just for problem solving. -- Radoslaw Skorupka Lodz, Poland W dniu 25.10.2020 o 16:16, Charles Mills pisze: Also assuming you run RACF, not either of the CA security products. IRRADU00 is technical not "free," it is a part of RACF. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Sunday, October 25, 2020 7:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Yes! Does a good job, again assuming you are collecting the relevant SMF 30 data. IRRADU00 contrary to what you might expect from the name processes SMF 30 as well as RACF SMF 80 (assuming I recall correctly). It solves the "section" problem that @Lizette alludes to. Its output IIRC is a file of huge fixed-layout records. I have never used it; this is from customer discussions and documentation-reading. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Saturday, October 24, 2020 11:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history The answer is IRRADU00 report - standard (free) RACF tool. Then you can write yoour own report. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
In SDSF, &10 or does the job - KB ‐‐‐ Original Message ‐‐‐ On Monday, October 26, 2020 12:17 AM, Tom Brennan wrote: > Reminds me of a co-worker who no matter what time day or night I would > happen to see his online Outlook status, his id was marked as online and > busy. Of course he had some kind of macro or hook running on his PC. > > On 10/24/2020 11:10 PM, kekronbekron wrote: > > > I hope no one encourages this kind of snooping on the list. > > Stinks of an attempt to police working hours. > > > > - KB > > > > ‐‐‐ Original Message ‐‐‐ > > On Sunday, October 25, 2020 11:37 AM, Jake Anderson > > justmainfra...@gmail.com wrote: > > > > > Hello > > > Cross posted. > > > We have a SMF data for some years and I would like to fetch a user's logon > > > history like when he was logged with all time intervals. > > > Is there a sample JCL or process you are following without having to use > > > any third party product to process. > > > Could someone please share any sample if you have and willing to share ? > > > Jake > > > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Of course, I'm just raising a point of being mindful of what the purpose of this may be. Heck, I wrote one myself a few years ago; good thing it wasn't used more than once (the initial test run lol). - KB ‐‐‐ Original Message ‐‐‐ On Sunday, October 25, 2020 8:18 PM, Seymour J Metz wrote: > There are legitimate reasons for that type of report. > > > --- > > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > kekronbekron [02dee3fcae33-dmarc-requ...@listserv.ua.edu] > Sent: Sunday, October 25, 2020 2:10 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Sunday, October 25, 2020 11:37 AM, Jake Anderson > justmainfra...@gmail.com wrote: > > > > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
On 26/10/2020 5:13 am, Charles Mills wrote: I *think* z/OS is now shipping header files for C/C++ for many SMF records. If not, EDCDSECT does a halfway decent job. (I know -- been there, done that, got the T-shirt.) There is someone I think who offers SMF layouts in Java, perhaps at no charge. Google might be your friend. EasySMF has SMF mappings in Java, but not at no charge. There is a lot more to it than just generating the layouts. E.g. each date and time field is available as the appropriate java.time type (up to nanosecond precision) i.e. you don't have to figure out the units. There are methods provided to extract the record sections. Some sample reports to demonstrate the use are available on Github: https://github.com/BlackHillSoftware/easysmf-samples -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
We did not usually see 1.0's for CICS logons. I think there is a caller ability to suppress cutting the record, or perhaps customers don't usually audit successful logons (?) so we found CICS logons to be basically hopeless. There is some other 1.nn that gets cut a lot but it happens on every transaction (?) so customers were reluctant to turn it on due to the volume. Working from two+ year old memory here. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hayim Sokolsky Sent: Sunday, October 25, 2020 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history User logon activity depends upon a combination of which logons you are talking about -and- which OEM security you use - RACF, Top Secret, or ACF2. TSO logon, job start (batch) and Started Task events are SMF type 20 or type 30. Anything else (CICS, Distributed DB2, IMS, etc…) is an SMF type 80 (event code 1 - RACINIT) cut by the security product itself. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
User logon activity depends upon a combination of which logons you are talking about -and- which OEM security you use - RACF, Top Secret, or ACF2. TSO logon, job start (batch) and Started Task events are SMF type 20 or type 30. Anything else (CICS, Distributed DB2, IMS, etc…) is an SMF type 80 (event code 1 - RACINIT) cut by the security product itself. Hayim > On Oct 25, 2020, at 16:36, Seymour J Metz wrote: > > Ouch! > > I meant type 80, but from what you say he may be SOL if he needs more than > TSO. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Charles Mills [charl...@mcn.org] > Sent: Sunday, October 25, 2020 4:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > I lived and breathed z/OS event monitoring via real-time SMF from 2010 to > 2018. CICS and most if not all session managers are pretty much hopeless. > Ditto end-user access to WebSphere, and Db2 if it is three-tier -- i.e., the > user logs onto Linux or Windows and a process there hits Db2. CICS cuts SMF > 110 records but not for logons. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Sunday, October 25, 2020 12:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > I don't know that TSO is all that is of interest. What about, e.g., CICS, > NVAS, TPX? > > -- > 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: SMF to capture user login history
On Sun, 25 Oct 2020 19:21:24 +, Jesse 1 Robinson wrote: >I had that problem in a shop long ago. In defense of the 'perpetrators', if a >user got caught by timeout chopper, getting back on could be long and >difficult. The real culprit was lousy tuning and inadequate resources. The >resource problem eventually got solved by an upgrade. No users were harmed in >the process. > At one time our admin installed a timeout chopper for CMS users. He was generous and naive enough to provide a "two minute warning". The first time I was away from my desk long enough to miss that warning I installed a background process to trap the warning. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Ouch! I meant type 80, but from what you say he may be SOL if he needs more than TSO. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Sunday, October 25, 2020 4:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history I lived and breathed z/OS event monitoring via real-time SMF from 2010 to 2018. CICS and most if not all session managers are pretty much hopeless. Ditto end-user access to WebSphere, and Db2 if it is three-tier -- i.e., the user logs onto Linux or Windows and a process there hits Db2. CICS cuts SMF 110 records but not for logons. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, October 25, 2020 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history I don't know that TSO is all that is of interest. What about, e.g., CICS, NVAS, TPX? -- 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: SMF to capture user login history
I lived and breathed z/OS event monitoring via real-time SMF from 2010 to 2018. CICS and most if not all session managers are pretty much hopeless. Ditto end-user access to WebSphere, and Db2 if it is three-tier -- i.e., the user logs onto Linux or Windows and a process there hits Db2. CICS cuts SMF 110 records but not for logons. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, October 25, 2020 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history I don't know that TSO is all that is of interest. What about, e.g., CICS, NVAS, TPX? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
I don't know that TSO is all that is of interest. What about, e.g., CICS, NVAS, TPX? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Sunday, October 25, 2020 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Trust me, necessary and sufficient for user TSO logon and logoff is SMF 30. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, October 25, 2020 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a small PL/I program to process the SMF data. The records to look at depend on the types of logon you're concerned with, "Note: IBM recommends that you use record type 30 rather than record types 4, 5, 20, 34, 35, and 40." You may also need type 70 (RMF). -- 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: SMF to capture user login history
These days a lot of things depend on Unix System Services. You would need to do something to let them be dubbed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] Sent: Sunday, October 25, 2020 11:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, 25 Oct 2020 15:07:20 +, Seymour J Metz wrote: >Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a >small PL/I program to process the SMF data. The records to look at depend on >the types of logon you're concerned with, > >"Note: IBM recommends that you use record type 30 rather than record types 4, >5, 20, 34, 35, and 40." You may also need type 70 (RMF). > Are there PL/I header files mapping SMF record types? C? Rexx? For Rexx, the ideal would be a facility similar to OMVS ADDRESS SYSCALL which returns not a storage object with mapped offsets but a compound symbol with a programmer-specified stem and tail values mapped by mnemonic SYSCALL_CONSTANTS. Is there (a range of) SMF record types reserved for ISVs? Or even a single type further distinguished by ISV-assigned component prefix? Is it possible to operate z/OS with neither RACF nor a competing product? I'd suspect many SAF calls would need to be stubbed. Data set passwords, UADS, etc.? -- gil -- 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: SMF to capture user login history
I had that problem in a shop long ago. In defense of the 'perpetrators', if a user got caught by timeout chopper, getting back on could be long and difficult. The real culprit was lousy tuning and inadequate resources. The resource problem eventually got solved by an upgrade. No users were harmed in the process. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, October 25, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SMF to capture user login history CAUTION EXTERNAL EMAIL Reminds me of a co-worker who no matter what time day or night I would happen to see his online Outlook status, his id was marked as online and busy. Of course he had some kind of macro or hook running on his PC. On 10/24/2020 11:10 PM, kekronbekron wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Sunday, October 25, 2020 11:37 AM, Jake Anderson > wrote: > >> Hello >> >> Cross posted. >> >> We have a SMF data for some years and I would like to fetch a user's >> logon history like when he was logged with all time intervals. >> >> Is there a sample JCL or process you are following without having to >> use any third party product to process. >> >> Could someone please share any sample if you have and willing to share ? >> >> Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Reminds me of a co-worker who no matter what time day or night I would happen to see his online Outlook status, his id was marked as online and busy. Of course he had some kind of macro or hook running on his PC. On 10/24/2020 11:10 PM, kekronbekron wrote: I hope no one encourages this kind of snooping on the list. Stinks of an attempt to police working hours. - KB ‐‐‐ Original Message ‐‐‐ On Sunday, October 25, 2020 11:37 AM, Jake Anderson wrote: Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. Could someone please share any sample if you have and willing to share ? Jake 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: SMF to capture user login history
I *think* z/OS is now shipping header files for C/C++ for many SMF records. If not, EDCDSECT does a halfway decent job. (I know -- been there, done that, got the T-shirt.) There is someone I think who offers SMF layouts in Java, perhaps at no charge. Google might be your friend. Yes, for "old" SMF records types 128 to 255 are reserved for non-IBM use. There is no official repository of who uses what, but Cheryl Watson has the best list I know of. Google is your friend. For the "new" SMF record format with 16-bit types, yes, there is a large range reserved for non-IBM but I do not have it memorized. Yes, I think it may be possible to run z/OS with no security subsystem but I doubt that anyone does so. Yes, you would need a SAF stub that always said "yes, go ahead, you have access" or perhaps made some very simplistic determination: GILMART is allowed to do anything; anyone else only gets read access to datasets unless they have their HLQ. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, 25 Oct 2020 15:07:20 +, Seymour J Metz wrote: >Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a >small PL/I program to process the SMF data. The records to look at depend on >the types of logon you're concerned with, > >"Note: IBM recommends that you use record type 30 rather than record types 4, >5, 20, 34, 35, and 40." You may also need type 70 (RMF). > Are there PL/I header files mapping SMF record types? C? Rexx? For Rexx, the ideal would be a facility similar to OMVS ADDRESS SYSCALL which returns not a storage object with mapped offsets but a compound symbol with a programmer-specified stem and tail values mapped by mnemonic SYSCALL_CONSTANTS. Is there (a range of) SMF record types reserved for ISVs? Or even a single type further distinguished by ISV-assigned component prefix? Is it possible to operate z/OS with neither RACF nor a competing product? I'd suspect many SAF calls would need to be stubbed. Data set passwords, UADS, etc.? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
On Sun, 25 Oct 2020 15:07:20 +, Seymour J Metz wrote: >Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a >small PL/I program to process the SMF data. The records to look at depend on >the types of logon you're concerned with, > >"Note: IBM recommends that you use record type 30 rather than record types 4, >5, 20, 34, 35, and 40." You may also need type 70 (RMF). > Are there PL/I header files mapping SMF record types? C? Rexx? For Rexx, the ideal would be a facility similar to OMVS ADDRESS SYSCALL which returns not a storage object with mapped offsets but a compound symbol with a programmer-specified stem and tail values mapped by mnemonic SYSCALL_CONSTANTS. Is there (a range of) SMF record types reserved for ISVs? Or even a single type further distinguished by ISV-assigned component prefix? Is it possible to operate z/OS with neither RACF nor a competing product? I'd suspect many SAF calls would need to be stubbed. Data set passwords, UADS, etc.? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Trust me, necessary and sufficient for user TSO logon and logoff is SMF 30. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Sunday, October 25, 2020 8:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a small PL/I program to process the SMF data. The records to look at depend on the types of logon you're concerned with, "Note: IBM recommends that you use record type 30 rather than record types 4, 5, 20, 34, 35, and 40." You may also need type 70 (RMF). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Also assuming you run RACF, not either of the CA security products. IRRADU00 is technical not "free," it is a part of RACF. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Sunday, October 25, 2020 7:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Yes! Does a good job, again assuming you are collecting the relevant SMF 30 data. IRRADU00 contrary to what you might expect from the name processes SMF 30 as well as RACF SMF 80 (assuming I recall correctly). It solves the "section" problem that @Lizette alludes to. Its output IIRC is a file of huge fixed-layout records. I have never used it; this is from customer discussions and documentation-reading. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Saturday, October 24, 2020 11:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history The answer is IRRADU00 report - standard (free) RACF tool. Then you can write yoour own report. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Well, if I didn't have an IBM or third party tool like SAS/MXG, I'd write a small PL/I program to process the SMF data. The records to look at depend on the types of logon you're concerned with, "Note: IBM recommends that you use record type 30 rather than record types 4, 5, 20, 34, 35, and 40." You may also need type 70 (RMF). -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jake Anderson [justmainfra...@gmail.com] Sent: Sunday, October 25, 2020 2:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF to capture user login history Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. Could someone please share any sample if you have and willing to share ? Jake -- 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: SMF to capture user login history
There are legitimate reasons for that type of report. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of kekronbekron [02dee3fcae33-dmarc-requ...@listserv.ua.edu] Sent: Sunday, October 25, 2020 2:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history I hope no one encourages this kind of snooping on the list. Stinks of an attempt to police working hours. - KB ‐‐‐ Original Message ‐‐‐ On Sunday, October 25, 2020 11:37 AM, Jake Anderson wrote: > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > > > 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: SMF to capture user login history
It's as Piece of cake in PL/I, although the OS PL/I "optimizing" compiler generated truly ghastly code for unaligned bit strings. (Has that been fixed in Enterprise PL/I?) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Lizette Koehler [stars...@mindspring.com] Sent: Sunday, October 25, 2020 2:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Which SMF Records are you going to use? I would say in general without a 3rd part product (like SAS) it will be a challenge to parse through MOST SMF records without something that can handle the record section offsets Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: Saturday, October 24, 2020 11:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF to capture user login history Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. Could someone please share any sample if you have and willing to share ? Jake -- 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: SMF to capture user login history
Yes! Does a good job, again assuming you are collecting the relevant SMF 30 data. IRRADU00 contrary to what you might expect from the name processes SMF 30 as well as RACF SMF 80 (assuming I recall correctly). It solves the "section" problem that @Lizette alludes to. Its output IIRC is a file of huge fixed-layout records. I have never used it; this is from customer discussions and documentation-reading. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Saturday, October 24, 2020 11:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history The answer is IRRADU00 report - standard (free) RACF tool. Then you can write yoour own report. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
SMF 30 is sufficient to do this, assuming you have been capturing the start and end events of TSO sessions. There may be a CBT program to report on this; have you searched? It is not impossible to do it yourself with Rexx. @Lizette mentions the problem of SMF "sections." She's right, but it's not impossible. Here is the basic technique: GetSect: Procedure Expose Recd.1 Triplet = Arg(1) If Triplet = "" Then Return "" Num = C2D(Substr(Triplet, 7, 2)) If Num = 0 Then Return "" Len = C2D(Substr(Triplet, 5, 2)) If Len = 0 Then Return "" Off = C2D(Substr(Triplet, 1, 4)) If Off = 0 Then Return "" Return Substr(Recd.1, Off-3, Len) Then you can code, for example Section = GetSect(Substr(Recd.1, 29, 8)) SMF30JBN = Substr(Section, 1,8) Yes, as @KB more or less alluded to, what you propose may be frowned upon in some circles. This kind of reporting is forbidden (by law? by typical union contract?) in Germany (and perhaps elsewhere in the EU and other places?). It is prohibited to routinely process data that could be used to infer working hours. You can collect it, and process it in a specific investigation, but not routinely. (I am not a lawyer, much less a German labor law lawyer, so take what I write as a general hint, not exact legal advice.) This is all right in my wheelhouse because the program I wrote for CorreLog, zDefender, and which was acquired by BMC as AMI Defender, may be and is often used to do exactly what you describe. You use it in conjunction with a collection and reporting tool running on a "small system": either Splunk, or a "SIEM" such as IBM QRadar. I know you said "no third party" but this was a fairly mature market: nearly every shop has either Defender, or one of the two main competitors, IBM zSecure Audit or Syncsort Ironstream (and nearly every company in the world seems to be running Splunk). You might want to check whether your shop already has one of the three mainframe products I mention, and Splunk or a SIEM in your Security Operations Center. If you have one of the mainframe products already, but your organization does not give you access to Splunk, you can download it and run it "full-function" for free, provided only that you keep your data to under 500MB/day. Splunk is really powerful and really easy to use. (That's why everyone it seems runs it.) Yes, this assumes by "logged on" you refer to TSO. CICS does not generate SMF data equivalent to this, nor does IMS, nor do the session manager products AFAIK. If you have not been collecting SMF 30 TSO start and end events, then you may be able to get the logons from SMF 80, but not the log offs. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake Anderson Sent: Saturday, October 24, 2020 11:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF to capture user login history Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
> two sets of IDs Multiple ids can be very usefull. If you have a lot of privileges and write code that is supposed to work without those privileges, it's useful to have a bare bones userid. If you have work that requires privileges that you consider too dangerous for normal work, it's nice to have a more privileged userid and proxy permission. BTDT, GTTS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Horein [steve.hor...@gmail.com] Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > Meh. The first shop I worked in implemented something like that to track the use of privileged IDs that had elevated permissions to update production resources. At the time, the scope had been TSO, so I wrote some automation that would send an email to the "security operations center" if RACF IDs matching specific patterns generated an IEF125I, IEF126I, or an IEF45* message. The time frames from logon to logoff/abend needed to be justified with a change request or incident, otherwise it would be considered suspicious activity. Yes, it meant having to maintain two sets of IDs - a BAU ID for day to day work, and the privileged ID for changes or recovery support, but it satisfied someone's requirement. -- 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: SMF to capture user login history
Nah. This is standard stuff required by auditors to provide artifacts for an audit. Not suspicious at all. Joe On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Sunday, October 25, 2020 11:37 AM, Jake Anderson < > justmainfra...@gmail.com> wrote: > > > Hello > > > > Cross posted. > > > > We have a SMF data for some years and I would like to fetch a user's > logon > > history like when he was logged with all time intervals. > > > > Is there a sample JCL or process you are following without having to use > > any third party product to process. > > > > Could someone please share any sample if you have and willing to share ? > > > > Jake > > > > > > > > > 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: SMF to capture user login history
On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > Meh. The first shop I worked in implemented something like that to track the use of privileged IDs that had elevated permissions to update production resources. At the time, the scope had been TSO, so I wrote some automation that would send an email to the "security operations center" if RACF IDs matching specific patterns generated an IEF125I, IEF126I, or an IEF45* message. The time frames from logon to logoff/abend needed to be justified with a change request or incident, otherwise it would be considered suspicious activity. Yes, it meant having to maintain two sets of IDs - a BAU ID for day to day work, and the privileged ID for changes or recovery support, but it satisfied someone's requirement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Logon to what? Just TSO, or a session manager like TPX? Logon to CICS, IMS, Websphere, MQ, etc. ? And what about logoff -- are you looking for logon duration, or whether a particular user could have initiated some system or application action at a certain time? There are literally dozens of different data sources for these metrics, so how to do it depends upon whether close counts? A very imprecise answer is from an ESM report like IRRADU00 , while a 100% correct answer becomes very difficult to achieve and may require more than SMF data. On Sun, Oct 25, 2020 at 5:08 PM Jake Anderson wrote: > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > -- > 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: SMF to capture user login history
The answer is IRRADU00 report - standard (free) RACF tool. Then you can write yoour own report. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
I believe there are SMF processing examples in the ICETOOL samples > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Lizette Koehler > Sent: Saturday, October 24, 2020 11:29 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SMF to capture user login history > > Which SMF Records are you going to use? > > I would say in general without a 3rd part product (like SAS) it will be a > challenge to parse through MOST SMF records without something that can > handle the record section offsets > > Lizette > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jake Anderson > Sent: Saturday, October 24, 2020 11:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: SMF to capture user login history > > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use any > third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > -- > 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: SMF to capture user login history
Which SMF Records are you going to use? I would say in general without a 3rd part product (like SAS) it will be a challenge to parse through MOST SMF records without something that can handle the record section offsets Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: Saturday, October 24, 2020 11:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF to capture user login history Hello Cross posted. We have a SMF data for some years and I would like to fetch a user's logon history like when he was logged with all time intervals. Is there a sample JCL or process you are following without having to use any third party product to process. Could someone please share any sample if you have and willing to share ? Jake -- 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: SMF to capture user login history
Classification: Public Certainly not my area of expertise, but looks like maybe SMF type 30? https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag200/rec30.htm This may help as well: https://www.ibm.com/support/pages/common-data-provider-tso-logon-successful-event-missing-racf-records-x80 Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: 25 October 2020 06:16 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history -- This email has reached the Bank via an external source -- Unfortunately I can't unfold in detail about our management requirements here but technically looking for some pointers. On Sun, 25 Oct, 2020, 10:14 am Jake Anderson, wrote: > KB, > > Not a stink and it just a requirement. > > On Sun, 25 Oct, 2020, 10:11 am kekronbekron, < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > >> I hope no one encourages this kind of snooping on the list. >> Stinks of an attempt to police working hours. >> >> - KB >> >> ‐‐‐ Original Message ‐‐‐ >> On Sunday, October 25, 2020 11:37 AM, Jake Anderson < >> justmainfra...@gmail.com> wrote: >> >> > Hello >> > >> > Cross posted. >> > >> > We have a SMF data for some years and I would like to fetch a >> > user's >> logon >> > history like when he was logged with all time intervals. >> > >> > Is there a sample JCL or process you are following without having >> > to use any third party product to process. >> > >> > Could someone please share any sample if you have and willing to share ? >> > >> > Jake >> > >> > >> - >> - >> - >> - >> >> > >> > 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 Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 11722983. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by the Financial Conduct Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF to capture user login history
Unfortunately I can't unfold in detail about our management requirements here but technically looking for some pointers. On Sun, 25 Oct, 2020, 10:14 am Jake Anderson, wrote: > KB, > > Not a stink and it just a requirement. > > On Sun, 25 Oct, 2020, 10:11 am kekronbekron, < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > >> I hope no one encourages this kind of snooping on the list. >> Stinks of an attempt to police working hours. >> >> - KB >> >> ‐‐‐ Original Message ‐‐‐ >> On Sunday, October 25, 2020 11:37 AM, Jake Anderson < >> justmainfra...@gmail.com> wrote: >> >> > Hello >> > >> > Cross posted. >> > >> > We have a SMF data for some years and I would like to fetch a user's >> logon >> > history like when he was logged with all time intervals. >> > >> > Is there a sample JCL or process you are following without having to use >> > any third party product to process. >> > >> > Could someone please share any sample if you have and willing to share ? >> > >> > Jake >> > >> > >> >> > >> > 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: SMF to capture user login history
KB, Not a stink and it just a requirement. On Sun, 25 Oct, 2020, 10:11 am kekronbekron, < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Sunday, October 25, 2020 11:37 AM, Jake Anderson < > justmainfra...@gmail.com> wrote: > > > Hello > > > > Cross posted. > > > > We have a SMF data for some years and I would like to fetch a user's > logon > > history like when he was logged with all time intervals. > > > > Is there a sample JCL or process you are following without having to use > > any third party product to process. > > > > Could someone please share any sample if you have and willing to share ? > > > > Jake > > > > > > > > > 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: SMF to capture user login history
I hope no one encourages this kind of snooping on the list. Stinks of an attempt to police working hours. - KB ‐‐‐ Original Message ‐‐‐ On Sunday, October 25, 2020 11:37 AM, Jake Anderson wrote: > Hello > > Cross posted. > > We have a SMF data for some years and I would like to fetch a user's logon > history like when he was logged with all time intervals. > > Is there a sample JCL or process you are following without having to use > any third party product to process. > > Could someone please share any sample if you have and willing to share ? > > Jake > > > > 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
