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