Hey Andy,

Ah, a proxy server does not forward the client's credentials

Then I might be misinterpreting this section in https://xrootd.slac.stanford.edu/doc/gsidocs/XRootDGSIProtocolSpecifications.html ?

"For gsi the goal of the handshake is to mutually verify the credentials - the server verifies the client proxy certificate, the client verifies the server certificate, and to create a shared secret to encrypt the rest of the handshake and further communication.
Optionally, after a successful handshake, a delegate client proxy certificate can be produced to enable further authentication handshakes initiated by the server on behalf of the client, for example in the case of a Third Party Copy."

The best you can do it proxy the proxy's credentials and the proxy server needs to be configured to do that (only the client side part needs to enabled).

Could you point me to some documentation of the required configuration for this?

Cheers and thanks
Dirk


On 6/11/21 9:45 PM, Andrew Hanushevsky wrote:
[log in to unmask]">Hi Dirk,

Ah, a proxy server does not forward the client's credentials. The best you can do it proxy the proxy's credentials and the proxy server needs to be configured to do that (only the client side part needs to enabled).

Andy


On Fri, 11 Jun 2021, Dirk Sammel wrote:

Hey Petr,

I'm not talking about the server configuration of the exernal site (Munich), but about the configuration of the forward proxy server I have set up in Freiburg.
Sorry if this wasn't clear.

Cheers
Dirk

On 6/11/21 6:06 PM, Petr Vokac wrote:
This doesn't look like server configuration issue, because transfers works for me from lxplus.cern.ch with same client, e.g.
*$ source /cvmfs/sft.cern.ch/lcg/views/setupViews.sh LCG_99 x86_64-centos7-gcc8-opt****$ voms-proxy-init -voms atlas***Enter GRID pass phrase for this identity:
Contacting voms2.cern.ch:15001 [/DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch] "atlas"...
Remote VOMS server contacted succesfully.
Created proxy in /tmp/x509up_u45277.
Your proxy is valid until Sat Jun 12 06:01:58 CEST 2021
*$ which xrdcp***/cvmfs/sft.cern.ch/lcg/views/LCG_99/x86_64-centos7-gcc8-opt/bin/xrdcp
*$ ls -la /cvmfs/sft.cern.ch/lcg/views/LCG_99/x86_64-centos7-gcc8-opt/bin/xrdcp***lrwxrwxrwx. 1 cvmfs cvmfs 85 Jan 10 23:07 /cvmfs/sft.cern.ch/lcg/views/LCG_99/x86_64-centos7-gcc8-opt/bin/xrdcp -> /cvmfs/sft.cern.ch/lcg/releases/xrootd/4.12.3-61acf/x86_64-centos7-gcc8-opt/bin/xrdcp
*$ xrdcp root://lcg-lrz-rootd.grid.lrz.de:1094/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasscratchdisk/rucio/user/dsammel/04/71/large.root .***[12.16GB/12.16GB][100%][==================================================][136.9MB/s]

Petr

On 6/11/21 5:09 PM, Dirk Sammel wrote:
Dear experts,

I'm having trouble with using the proxy delegation feature. My setup is as follows:

I have a client that wants to download files from an external site, therefore authentication is required. The request is forwarded to a proxy server (which is running in forwarding mode and also caches the files). I see the following error in the proxy server log (the full log is attached):

ofs_open: [log in to unmask]">ds1034.9382:[log in to unmask] Unable to open /root:/lcg-lrz-rootd.grid.lrz.de:1094/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasscratchdisk/rucio/user/dsammel/04/71/large.root; invalid exchange

At one point before that, the proxy server tries to create a user proxy for user xrootd. If I put my userkey and usercert on the proxy server and manually create a user proxy for user xrootd, the authentication works, but this is of course not a reasonable solution.

Client:

XRootD version: 4.12.3

$XrdSecGSIDELEGPROXY=2
$XrdSecGSIPROXYDEPLEN=-1
$X509_USER_PROXY=/tmp/x509up_u52246
$X509_USER_KEY=/home/ds1034/.globus/userkey.pem
$X509_USER_CERT=/home/ds1034/.globus/usercert.pem

Server:

XRootD version: 5.1.1

xrootd.seclib libXrdSec.so
sec.protocol gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -dlgpxy:request -d:3


The complete server config is attached.


I also attached the debug logs for the client and the server when running

xrdcp -f -d 3 root://lcg-lrz-rootd.grid.lrz.de:1094/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasscratchdisk/rucio/user/dsammel/04/71/large.root .

Two things I noticed: in the client log "Proxy delegation option: 0", in the server log "Secgsi Proxy delegation option: ignore", it seems that these settings are not applied?

Is anything missing in my configuration or is anything wrong?
Just tell me if I need to provide any missing information!

Cheers
Dirk

########################################################################
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



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