Hi Albert, Good that you reiterated that section because it has an error in it. “-exppxy:creds” should be “-exppxy:=creds”. The dashes are also using a strange character. Anyway, we can put a back reference in the security reference but we generally don’t repeat section acrfoss manuals because they invarfiably drift apart over time and cause more confusion than not. Andy From: Albert Rossi Sent: Tuesday, March 12, 2019 6:46 AM To: Andrew Hanushevsky ; Yang, Wei ; xrootd-l Subject: Re: setting up server for delegation Hi Andy/Wei, I just discovered the following in the OFS configuration file, 3.11.1 Third Party Copy Using Delegated Credentials Third party copy can use delegated credentials to perform the copy for those authentication protocols that support delegation. Currently, only gsi authentication supports delegation. Normally, when you specify that delegated credentials are to be used via the fcreds option, the client is required to supply such credentials. If the client does not supply delegated credentials, the copy request is rejected. You may specify a fallback by prefixing the auth specified with a question mark. The fallback uses the server’s credentials and is backward compatible with earlier versions of tpc. Be aware that the server must have usable credentials for the copy to succeed in such a case (e.g. gsi proxy credentials). In order to successfully use delegation three conditions must be met: 1.. The client must enable credential delegation. 2.. The server’s authentication protocol must be configured for delegation. 3.. The ofs.tpc directive must enable server-side delegation. Typically, the client enables delegation by using the delegate argument of the –tpc command line option; for example, xrdcp –tpc delegate only sourcefile destinationfile Configuring the server’s authentication protocol to use delegated credentials is largely dependent on the protocol being used. Since delegation is currently only supported by gsi authentication you should specify sec.protocol gsi –dlgpxy:1 –exppxy:creds any_additional_options etc. This is actually the information I was looking for. I would suggest it be made available in the Security configuration as well. I personally did not think to look for it here; perhaps others would make the same mistake. -Al ________________________________________________ Albert L. Rossi Application Developer & Systems Analyst III Scientific Computing Division, Data Movement Development FCC 229A Mail Station 369 (FCC 2W) Fermi National Accelerator Laboratory Batavia, IL 60510 (630) 840-3023 -------------------------------------------------------------------------------- From: Andrew Hanushevsky <[log in to unmask]> Sent: Monday, March 11, 2019 7:19 PM To: Yang, Wei; Albert Rossi; xrootd-l Subject: Re: setting up server for delegation Indeed, the authzpxy option was meant to be used with the authz plugin, AFAIK. I would stay away from that and for what Wei indicates. Andy From: Yang, Wei Sent: Monday, March 11, 2019 1:17 PM To: Albert Rossi ; xrootd-l Subject: Re: setting up server for delegation Hi Andy, This particular question of authzpxy:opt is probably for you. I never seriously used it (but it is probably OK for Aląs test). I only used vomsxrd and lcmaps-xrootd. regards, -- Wei Yang | [log in to unmask] | 650-926-3338(O) From: Albert Rossi <[log in to unmask]> Date: Monday, March 11, 2019 at 12:51 PM To: Wei Yang <[log in to unmask]>, xrootd-l <[log in to unmask]> Subject: Re: setting up server for delegation Hi Wei, Ah, OK. So is there anything else that needs to be configured when using that option? For instance, what should authzpxy:opt Defines if and how the user proxy information is exported in the XrdSecEntity for authorization. Options are entered in the form opt = what * 10 + where with what possibly taking the following values 0 full proxy chain (CA, certificate, proxies) 1 last user proxy only and where 1 in the XrdSecEntity.creds field 2 in the XrdSecEntity.endorsements field Default is 0, i.e. no export. Be set to ... 1 ? Thanks, Al ________________________________________________ Albert L. Rossi Application Developer & Systems Analyst III Scientific Computing Division, Data Movement Development FCC 229A Mail Station 369 (FCC 2W) Fermi National Accelerator Laboratory Batavia, IL 60510 (630) 840-3023 -------------------------------------------------------------------------------- From: Yang, Wei <[log in to unmask]> Sent: Monday, March 11, 2019 2:47 PM To: Albert Rossi; xrootd-l Subject: Re: setting up server for delegation Hi Albert, I never tried using -exppxy:/tmp/x509up_u<uid>. I don?t know if this has been verified. In most cases, we use =creds instead of /tmp/? regards, -- Wei Yang | [log in to unmask] | 650-926-3338(O) From: <[log in to unmask]> on behalf of Albert Rossi <[log in to unmask]> Date: Monday, March 11, 2019 at 7:52 AM To: xrootd-l <[log in to unmask]> Subject: setting up server for delegation I am having a little difficulty getting tpc proxy delegation to work between the xrdcp client and two xrootd servers. I have the 4.9 client running on my desktop, and two 4.9 servers running on a testbed machine, one on the default port 1094 and one on port 1095. In the client environment, export XrdSecGSIDELEGPROXY=1 is set (I also set it on the server side, though it should not be necessary there). In the server configs: sec.protocol gsi -cert:/etc/grid-security/xrootd/hostcert.pem -key:/etc/grid-security/xrootd/hostkey.pem -dlgpxy:2 -exppxy:/tmp/x509up_u<uid> This does not seem to be either correct or sufficient. Doing xrdcp49 --tpc only root://fndcatemp2.fnal.gov:1094//data/xrootdfs/testdata root://fndcatemp2.fnal.gov:1095//data/xrootdfs/testdata-from-fndcatemp1-`date | tr ' ' '.'` ends with: Run: [ERROR] Server responded with an error: [3005] [FATAL] Auth failed What I see at the beginning of the server logs in this case: secgsi_InitOpts: Proxy delegation option: 0 The tpc transfer between the two servers fails because there is no proxy found: TPC job 8: 190311 09:07:15 30920 cryptossl_X509ParseFile: unable to open file (errno: 2) TPC job 8: 190311 09:07:15 30920 secgsi_QueryProxy: proxy files must have at least two certificates (found: 0) TPC job 8: 190311 09:07:15 30920 secgsi_InitProxy: Not a tty: cannot prompt for proxies - do nothing TPC job 8: 190311 09:07:15 30920 secgsi_QueryProxy: problems initializing proxy via external shell TPC job 8: 190311 09:07:15 30920 secgsi_getCredentials: error getting user proxies CF: 0x7f5fb4362940 TPC job 8: secgsi: error getting user proxies I also tried this with: sec.protocol gsi -cert:/etc/grid-security/xrootd/hostcert.pem -key:/etc/grid-security/xrootd/hostkey.pem -dlgpxy:1 There I see at the beginning of the server log secgsi_InitOpts: Proxy delegation option: 1 but with precisely the same error on the destination side: TPC job 8: 190311 09:40:46 20495 cryptossl_X509ParseFile: unable to open file (errno: 2) TPC job 8: 190311 09:40:46 20495 secgsi_QueryProxy: proxy files must have at least two certificates (found: 0) TPC job 8: 190311 09:40:46 20495 secgsi_InitProxy: Not a tty: cannot prompt for proxies - do nothing TPC job 8: 190311 09:40:46 20495 secgsi_QueryProxy: problems initializing proxy via external shell TPC job 8: 190311 09:40:46 20495 secgsi_getCredentials: error getting user proxies CF: 0x7fcbbede2940 TPC job 8: secgsi: error getting user proxies NOTE: If I set: export X509_USER_PROXY=/etc/grid-security/xrootd/fndcatemp2-proxy on the servers as we have been doing in order to use the robocert, the transfer succeeds without authentication issues. What magic needs to be done to get this to work? There must be something missing from the configuration which I have not taken into account. Thanks, Al ________________________________________________ Albert L. Rossi Application Developer & Systems Analyst III Scientific Computing Division, Data Movement Development FCC 229A Mail Station 369 (FCC 2W) Fermi National Accelerator Laboratory Batavia, IL 60510 (630) 840-3023 -------------------------------------------------------------------------------- Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 -------------------------------------------------------------------------------- Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1