I've been trying to figure out why sometimes authentication to our XRootD storage still fails whenever the VOMS-role "production" is required - which we require for writing.

With debugging active and also dbg for XrdSecgsiVOMSFun, I finally found this in the logs:

secgsi_Authenticate: WARNING: user mapping lookup failed - use DN or DN-hash as name
secgsiVOMS_Fun: proxy: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=ddmadmin/CN=531497/CN=Robot: ATLAS Data Management/CN=1987664213/CN=3833218252/CN=1560720301
secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=ddmadmin/CN=531497/CN=Robot: ATLAS Data Management
secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=ddmadmin/CN=531497/CN=Robot: ATLAS Data Management/CN=1987664213
secgsiVOMS_Fun: adding cert: /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=ddmadmin/CN=531497/CN=Robot: ATLAS Data Management/CN=1987664213/CN=3833218252
secgsiVOMS_Fun: retrieval successful
secgsiVOMS_Fun: found VO: atlas
secgsiVOMS_Fun:  ---> group: '/atlas', role: 'production', cap: 'NULL'
secgsiVOMS_Fun:  ---> group: '/atlas', role: 'NULL', cap: 'NULL'
secgsiVOMS_Fun:  ---> group: '/atlas/lcg1', role: 'NULL', cap: 'NULL'
secgsiVOMS_Fun:  ---> group: '/atlas/usatlas', role: 'NULL', cap: 'NULL'
secgsiVOMS_Fun:  ---> fqan: '/atlas/Role=production/Capability=NULL'
secgsiVOMS_Fun:  ---> fqan: '/atlas/Role=NULL/Capability=NULL'
secgsiVOMS_Fun:  ---> fqan: '/atlas/lcg1/Role=NULL/Capability=NULL'
secgsiVOMS_Fun:  ---> fqan: '/atlas/usatlas/Role=NULL/Capability=NULL'
secgsi_Authenticate: VOMS: Entity.vorg:         atlas
secgsi_Authenticate: VOMS: Entity.grps:         /atlas
secgsi_Authenticate: VOMS: Entity.role:         NULL
secgsi_Authenticate: VOMS: Entity.endorsements: /atlas/Role=production/Capability=NULL,/atlas/Role=NULL/Capability=NULL,/atlas/lcg1/Role=NULL/Capability=NULL,/atlas/usatlas/Role=NULL/Capability=NULL

So it seems the VOMS proxy authenticating to us has the production role and XrdSecgsiVOMSFun sees it just fine, but it does not show up in secgsi_Authenticate.
It rather seems that the role NULL is used here.

Now I am unsure whether the loss of information happens in the vomsxrd library (pinging @gganis on this) or later in XrdSecGSI.

Our config file contains:

sec.protocol /usr/lib64 gsi -dlgpxy:1 -exppxy:=creds -ca:1 -crl:3 -gridmap:/dev/null -cert:/etc/grid-security/hostcert.pem -key:/etc/grid-security/hostkey.pem -certdir:/etc/grid-security/certificates -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so -vomsfunparms:certfmt=raw|vos=atlas,ops|grps=/atlas,/ops

Any ideas what is going wrong here?
Or is there a different library that should be used as drop-in replacement for libXrdSecgsiVOMS (is that one still maintained)?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/1006?email_source=notifications\u0026email_token=AA7NRDX23DVDGGQVMH3FN33P3GKMRA5CNFSM4HZFJLZ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G2JDILA", "url": "https://github.com/xrootd/xrootd/issues/1006?email_source=notifications\u0026email_token=AA7NRDX23DVDGGQVMH3FN33P3GKMRA5CNFSM4HZFJLZ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G2JDILA", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1