Re: FTP userid propagation
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills [ snip ] but what I would REALLY like is what I asked for: some automated way of getting a user here signed on automatically there. It looks like PassTicket will do exactly that but I am a little boggled by all of the details - it would be great to have a Redbook-style cookbook - and I'd really like to understand the possible applicability of SSL/TLS. This is OPINION based primarily on research and VERY LITTLE experience (so far) with digital certificates and SSL/TLS: For what you propose, I believe digital certificates (and optionally SSL/TLS) would be simpler than Passtickets. My perception of Passtickets is that they are better suited for live sign-on since there is a unique Passticket generated every time a logon or sign-on is attempted, AND both the originating and target systems must have their clocks pretty-well synchronized for a generated Passticket to be considered valid by the target system. I believe digital certificates (with or without SSL/TLS) are better suited for batch-type sign-on, because a digital certificate is valid for a much longer time than ten minutes (normally) and the disparate system clocks need not be synchronized. And depending on the relationships between your prospect's system(s) and the target system(s), your prospect *may* be able to use self-signed certificates (i.e., your prospect could be its own certificate authority). -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
On 1/5/2006 12:30 PM, Charles Mills wrote: Thanks. Let me echo Bob Lester's request for more pointers if possible and ALSO ask: I ran across the facility called PassTicket. Wouldn't this do the job? The job being letting a program running for user XYZ log on to FTP on a different machine using the same userid (and assuming synchronized passwords and clocks)? Any gotchas with PassTicket? Good question, Charles. PassTickets would work, but you would need to implement some code on the client side to calculate the PassTicket so you could then provide it in response to the password prompt from the server. Prior to z/OS V1R7 that code must run APF-authorized. In z/OS R7 we provide enhanced functions for generating PassTickets that can be used by non-APF programs or Java. See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza360/11.1?SHELF=EZ2ZO10FDT=20050621032554 or http://makeashorterlink.com/?H2A842C6C for more information. On z/OS V1R7 or later using PassTickets for functions like this has thus become more feasible. However, it still does require some programming around the FTP process. You can't simply run the standard FTP client. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
On 1/5/2006 9:57 AM, Lester, Bob wrote: This does sound a lot better that the .netrc approach (which we've been using). Can you point me to the relevent manuals? Redbooks? What level of info do you need? If you're already using digital certificates then you have some basic info and infrastructure setup already. If you're not using them, then (a) you should be; but (b) you'll need to do a lot more reading and experimenting. Some information sources that should help: (a) RACF Security Administrator's Guide chapter 21, at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA760/21.0?SHELF=EZ2ZO10FDT=20050713233738 or http://makeashorterlink.com/?P44925C6C (b) z/OS PKI Services Guide and Reference (you may not need to use PKI Services, but there's also some good background info in this book) at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKYZA140/CCONTENTS?SHELF=EZ2ZO10FDN=SA22-7693-06DT=20050709135510 or http://makeashorterlink.com/?X1DD242AB (c) The RACF Presentations page at http://www-03.ibm.com/servers/eserver/zseries/zos/racf/presentations.html where you will find presentations on RACF and the Digital Certificate and some on security for z/OS Communications Server (d) The z/OS Communications Server IP Configuration Guide and Reference books: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B350/CCONTENTS?SHELF=EZ2ZO10FDN=SC31-8775-07DT=20050708113621 or http://makeashorterlink.com/?N25921C6C and http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B450/CCONTENTS?SHELF=EZ2ZO10FDN=SC31-8776-08DT=20050707162049 or http://makeashorterlink.com/?J16962C6C (e) The z/OS Communications Server IP User's Guide and Commands, at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B950/CCONTENTS?SHELF=EZ2ZO10FDN=SC31-8780-05DT=20050708142126 or http://makeashorterlink.com/?B47932C6C Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
| -Original Message- | From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] | Behalf Of Walt Farrell | Sent: Friday, January 06, 2006 6:47 AM | To: IBM-MAIN@BAMA.UA.EDU | Subject: Re: FTP userid propagation | | | On 1/5/2006 9:57 AM, Lester, Bob wrote: | | This does sound a lot better that the .netrc | approach (which we've been using). Can you point me to the | relevent manuals? Redbooks? | | | What level of info do you need? If you're already using digital | certificates then you have some basic info and | infrastructure setup already. | | If you're not using them, then | (a) you should be; but | (b) you'll need to do a lot more reading and experimenting. Hi Walt, I've got ported tools installed in my test LPAR (V1R4), and can do SSL over TN3270 (Extra emulator) so I think I've got the basics. I'm more interested in securing FTP via SSL/TLS. SCP would also seem to be an option for transferring files. Thanks for all the references! *BobL* -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
On 1/6/2006 9:47 AM, Lester, Bob wrote: I've got ported tools installed in my test LPAR (V1R4), and can do SSL over TN3270 (Extra emulator) so I think I've got the basics. I'm more interested in securing FTP via SSL/TLS. SCP would also seem to be an option for transferring files. Yes, if you've got the Ported Tools for z/OS installed then using scp (or, perhaps, sftp) should also provide a better way for you to go than using FTP with passwords. You can set that up to not require a password, but instead to use public/private key technology. If you want more discussion about the Ported Tools I would suggest the MVS-OE mailing list rather than IBM-MAIN. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
Walt, thanks very much. As mentioned in the OP, the FTP INPUT (command) file is totally built by a fairly complex program, so adding the logic to call an address in MVS, pass two parameters, and get back 8 bytes in 2 registers is almost trivial. I will definitely look at the 1.7 docs. I was a little put off by the need for Key 0 (authorization, in other words) - or rather, by the need to sell authorization to customers - so I am glad to hear you have loosened things up a little. Obviously not all of our customers are on 1.7, but they will be someday. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell Sent: Friday, January 06, 2006 5:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP userid propagation On 1/5/2006 12:30 PM, Charles Mills wrote: Thanks. Let me echo Bob Lester's request for more pointers if possible and ALSO ask: I ran across the facility called PassTicket. Wouldn't this do the job? The job being letting a program running for user XYZ log on to FTP on a different machine using the same userid (and assuming synchronized passwords and clocks)? Any gotchas with PassTicket? Good question, Charles. PassTickets would work, but you would need to implement some code on the client side to calculate the PassTicket so you could then provide it in response to the password prompt from the server. Prior to z/OS V1R7 that code must run APF-authorized. In z/OS R7 we provide enhanced functions for generating PassTickets that can be used by non-APF programs or Java. See http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza360/11.1?SHE LF=EZ2ZO10FDT=20050621032554 or http://makeashorterlink.com/?H2A842C6C for more information. On z/OS V1R7 or later using PassTickets for functions like this has thus become more feasible. However, it still does require some programming around the FTP process. You can't simply run the standard FTP client. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
I don't think anyone suggested generic IDs. The NETRC data set should be specific to each user authorized to do this, the same way each user has an ISPPROF if they are authorized to use ISPF. Charles Mills [EMAIL PROTECTED] wrote: I'm not a security guy. I have no idea what the exposures are. I suspect they are between minimal and none. The prospect has simply stated that generic userids are unacceptable and that the remote process must be run under the ID of the originator. That's what I am responding to. I am not in the business of arguing with prospects. You don't make sales arguing with prospects who raise security objections. We have multiple customers doing it the way we do it now with a single highly-restricted generic (to use this prospect's term) ID and no one has reported any problems. No one has had any objections until now. Perhaps I am not understanding you. If you are saying give each user their own NETRC file with UACC(NONE) I think the objection would be the maintenance headache. Each user's password would have to be maintained once in RACF (two instances) and once in their NETRC. I can try proposing that, but what I would REALLY like is what I asked for: some automated way of getting a user here signed on automatically there. It looks like PassTicket will do exactly that but I am a little boggled by all of the details - it would be great to have a Redbook-style cookbook - and I'd really like to understand the possible applicability of SSL/TLS. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Greg Saccomanno Sent: Thursday, January 05, 2006 2:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP userid propagation Charles, I am curious what security disaster exists with each of the users that will use this process having a userid.NETRC file with a UACC(NONE) be? If -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Yahoo! DSL Something to write home about. Just $16.99/mo. or less -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills I just posted the NETRC question but perhaps I should instead ask the fundamental underlying question. Here is what I want to do. I want to have a program ABC running in a normal batch job that might be submitted by any of a large number of TSO users invoke FTP and have it log on to a remote z/OS FTP server and, among other things, submit a job. I have complete control over the INPUT (command) file which is built on the fly. Here is the key question: I would like the FTP logon to be with the userid of the original user who submitted the batch job. Do any of you creative souls want to suggest a reasonable way to do this? Digital certificates? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
An additional consideration is do individual users have non-expiring passwords on the remote system? If the password expires, then NETRC or any other automatic procedure becomes more difficult. Craig -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Wednesday, January 04, 2006 5:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FTP userid propagation I just posted the NETRC question but perhaps I should instead ask the fundamental underlying question. Here is what I want to do. I want to have a program ABC running in a normal batch job that might be submitted by any of a large number of TSO users invoke FTP and have it log on to a remote z/OS FTP server and, among other things, submit a job. I have complete control over the INPUT (command) file which is built on the fly. Here is the key question: I would like the FTP logon to be with the userid of the original user who submitted the batch job. Do any of you creative souls want to suggest a reasonable way to do this? A file with possible userids and the associated remote passwords fulfills the letter of the above specs but is obviously totally unacceptable from a security point of view. I don't think NETRC does the job because a local NETRC is a security disaster and a global NETRC file would only provide one userid and password for the remote machine -- my whole point is I want to propagate each individual user id. Please don't ask why do you want to do it that way? The answer is I don't, the customer does. Charles Mills -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
On 1/4/2006 5:43 PM, Charles Mills wrote: I just posted the NETRC question but perhaps I should instead ask the fundamental underlying question. Here is what I want to do. I want to have a program ABC running in a normal batch job that might be submitted by any of a large number of TSO users invoke FTP and have it log on to a remote z/OS FTP server and, among other things, submit a job. I have complete control over the INPUT (command) file which is built on the fly. Here is the key question: I would like the FTP logon to be with the userid of the original user who submitted the batch job. Do any of you creative souls want to suggest a reasonable way to do this? The z/OS FTP server and client both support authentication via digital certificates (client authentication functions of SSL or TLS). I suggest you use that approach. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
Walt Farrell said: | | The z/OS FTP server and client both support authentication | via digital | certificates (client authentication functions of SSL or | TLS). I suggest | you use that approach. | | Walt Farrell, CISSP | z/OS Security Design, IBM | Hi Walt, This does sound a lot better that the .netrc approach (which we've been using). Can you point me to the relevent manuals? Redbooks? Thanks! *BobL* -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
Thanks. Let me echo Bob Lester's request for more pointers if possible and ALSO ask: I ran across the facility called PassTicket. Wouldn't this do the job? The job being letting a program running for user XYZ log on to FTP on a different machine using the same userid (and assuming synchronized passwords and clocks)? Any gotchas with PassTicket? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell Sent: Thursday, January 05, 2006 6:21 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP userid propagation On 1/4/2006 5:43 PM, Charles Mills wrote: I just posted the NETRC question but perhaps I should instead ask the fundamental underlying question. Here is what I want to do. I want to have a program ABC running in a normal batch job that might be submitted by any of a large number of TSO users invoke FTP and have it log on to a remote z/OS FTP server and, among other things, submit a job. I have complete control over the INPUT (command) file which is built on the fly. Here is the key question: I would like the FTP logon to be with the userid of the original user who submitted the batch job. Do any of you creative souls want to suggest a reasonable way to do this? The z/OS FTP server and client both support authentication via digital certificates (client authentication functions of SSL or TLS). I suggest you use that approach. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
As I keep saying, the problem is that the customer does not want to do that, and arguing with the customer is not sales-enhancing. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barry Schwarz Sent: Thursday, January 05, 2006 12:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP userid propagation What is the problem with a userid.NETRC with a UACC of NONE [and maybe an additional PE ID(*) ACC(NONE)]? Except for someone with OPERATIONS, everyone but the user should be locked out. Charles Mills [EMAIL PROTECTED] wrote: I just posted the NETRC question but perhaps I should instead ask the fundamental underlying question. Here is what I want to do. I want to have a program ABC running in a normal batch job that might be submitted by any of a large number of TSO users invoke FTP and have it log on to a remote z/OS FTP server and, among other things, submit a job. I have complete control over the INPUT (command) file which is built on the fly. Here is the key question: I would like the FTP logon to be with the userid of the original user who submitted the batch job. Do any of you creative souls want to suggest a reasonable way to do this? A file with possible userids and the associated remote passwords fulfills the letter of the above specs but is obviously totally unacceptable from a security point of view. I don't think NETRC does the job because a local NETRC is a security disaster and a global NETRC file would only provide one userid and password for the remote machine -- my whole point is I want to propagate each individual user id. Please don't ask why do you want to do it that way? The answer is I don't, the customer does. Charles Mills -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Yahoo! DSL Something to write home about. Just $16.99/mo. or less -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
Charles, I am curious what security disaster exists with each of the users that will use this process having a userid.NETRC file with a UACC(NONE) be? If it is the OPERATIONS ATTRIBUTE users being able to access the files that is hte problem, if they are all in a single group (or limited groups) give that group(s) access of NONE and even the users with OPERATIONS attributes will not be able to access the NETRC files. I am not trying to be difficult but we currently do something very much like this and I can't see where this causes any security exposure. It is a little bit of a pain for the users to maintain the password in the NETRC file but so far they are living with that. What did I miss and what exposure do I now have? Thank you, Greg -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barry Schwarz Sent: Thursday, January 05, 2006 12:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP userid propagation What is the problem with a userid.NETRC with a UACC of NONE [and maybe an additional PE ID(*) ACC(NONE)]? Except for someone with OPERATIONS, everyone but the user should be locked out. I don't think NETRC does the job because a local NETRC is a security disaster and a global NETRC file would only provide one userid and password for the remote machine -- my whole point is I want to propagate each individual user id. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
I'm not a security guy. I have no idea what the exposures are. I suspect they are between minimal and none. The prospect has simply stated that generic userids are unacceptable and that the remote process must be run under the ID of the originator. That's what I am responding to. I am not in the business of arguing with prospects. You don't make sales arguing with prospects who raise security objections. We have multiple customers doing it the way we do it now with a single highly-restricted generic (to use this prospect's term) ID and no one has reported any problems. No one has had any objections until now. Perhaps I am not understanding you. If you are saying give each user their own NETRC file with UACC(NONE) I think the objection would be the maintenance headache. Each user's password would have to be maintained once in RACF (two instances) and once in their NETRC. I can try proposing that, but what I would REALLY like is what I asked for: some automated way of getting a user here signed on automatically there. It looks like PassTicket will do exactly that but I am a little boggled by all of the details - it would be great to have a Redbook-style cookbook - and I'd really like to understand the possible applicability of SSL/TLS. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Greg Saccomanno Sent: Thursday, January 05, 2006 2:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP userid propagation Charles, I am curious what security disaster exists with each of the users that will use this process having a userid.NETRC file with a UACC(NONE) be? If -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
Charles, Thank you for your reply. It sounds like the individual NETRC files may not really be a security disaster but more of a maintenance disaster. I would agree, it is very inconvenient to require each user to update the NETRC file each time the password(s) on the remote system(s) change. Not perfect but so far not causing that much pain here (at least not that I am aware of). I hope as you progress through your solution I see more details here on IBM MAIN. Who knows, maybe I'll get a chance to change our process once you work out all the details and create the cook book for me :) Regards, Greg Perhaps I am not understanding you. If you are saying give each user their own NETRC file with UACC(NONE) I think the objection would be the maintenance headache. Each user's password would have to be maintained once in RACF (two instances) and once in their NETRC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
IMHO, a flaw in your thinking is your wanting to use someone else's ID for some security related activity. Have the users stow their data in staging files. Upon some event (timer, file creation, etc) a production job (the FTP) kicks off and does the transfer under its own ID. There is a protected NETRC file that contains the id/password for the remote site. If there is a need for the originating user ID, then embed that in the data. This does not solve your problem, but it does reduce the scope to a single ID/password to manage. This is an interesting case that demonstrates how encryption does not add any security. All that would have need for the NETRC file would also have to have the keys. The keys could then be easily compromised since you cannot control what a user does with those keys. Only the Lone Ranger has silver bullets. And even those only worked for a few years. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Wednesday, January 04, 2006 4:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FTP userid propagation I just posted the NETRC question but perhaps I should instead ask the fundamental underlying question. Here is what I want to do. I want to have a program ABC running in a normal batch job that might be submitted by any of a large number of TSO users invoke FTP and have it log on to a remote z/OS FTP server and, among other things, submit a job. I have complete control over the INPUT (command) file which is built on the fly. Here is the key question: I would like the FTP logon to be with the userid of the original user who submitted the batch job. Do any of you creative souls want to suggest a reasonable way to do this? Charles Mills -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
That's sort-of how it works now. But the customer (prospect, actually) wants individual userids. I agree with you, but arguing with a prospect is not sales-enhancing. BTW, it's not really someone else's ID - it's the ID of the submitting user. I have known all along what you are saying about encryption, etc., etc. That's why I posted the question here - I'm looking for new clues. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday, January 04, 2006 3:27 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP userid propagation IMHO, a flaw in your thinking is your wanting to use someone else's ID for some security related activity. Have the users stow their data in staging files. Upon some event (timer, file creation, etc) a production job (the FTP) kicks off and does the transfer under its own ID. There is a protected NETRC file that contains the id/password for the remote site. If there is a need for the originating user ID, then embed that in the data. This does not solve your problem, but it does reduce the scope to a single ID/password to manage. This is an interesting case that demonstrates how encryption does not add any security. All that would have need for the NETRC file would also have to have the keys. The keys could then be easily compromised since you cannot control what a user does with those keys. Only the Lone Ranger has silver bullets. And even those only worked for a few years. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP userid propagation
Instead of using the originating user, use a special ID for the batch process. Then permit a surrogat profile(RACF) or permit the ACID(Top Secret) to the large number of TSO users who need to run this job. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Wednesday, January 04, 2006 4:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FTP userid propagation I just posted the NETRC question but perhaps I should instead ask the fundamental underlying question. Here is what I want to do. I want to have a program ABC running in a normal batch job that might be submitted by any of a large number of TSO users invoke FTP and have it log on to a remote z/OS FTP server and, among other things, submit a job. I have complete control over the INPUT (command) file which is built on the fly. Here is the key question: I would like the FTP logon to be with the userid of the original user who submitted the batch job. Do any of you creative souls want to suggest a reasonable way to do this? A file with possible userids and the associated remote passwords fulfills the letter of the above specs but is obviously totally unacceptable from a security point of view. I don't think NETRC does the job because a local NETRC is a security disaster and a global NETRC file would only provide one userid and password for the remote machine -- my whole point is I want to propagate each individual user id. Please don't ask why do you want to do it that way? The answer is I don't, the customer does. Charles Mills --- --- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
