Replies: 5 comments 3 replies
-
|
We had a similar problem back in June 2019, where the voms server had PostalCode=/STREET=, but the proxy supplied postalCode=/street= which was correct according to @sfayer (there is a standard, I just don't know where). Looking back at the email chain, I have "we filed a ticket", but I cannot find the ticket, Simon might remember. |
Beta Was this translation helpful? Give feedback.
-
|
I found the ticket: https://ggus.eu/index.php?mode=ticket_info&ticket_id=139345 |
Beta Was this translation helpful? Give feedback.
-
|
I can't easily find a place where DIRAC VOMS2CSAgent manipulates the DN recevived by VOMS. Can you let me know:
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Then: |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
Dear all,
We have an issue with certificates having "sn" and "gn" fields, as in the example below:
/C=DE/O=GridGermany/OU=Max-Planck-Gesellschaft/OU=Max-Planck-Institut fuer Kernphysik/sn=Werner/gn=Felix/CN=Felix WernerWhen users issue a proxy with dirac-proxy-init they get:
DN /C=DE/O=GridGermany/OU=Max-Planck-Gesellschaft/OU=Max-Planck-Institut fuer Kernphysik/SN=Werner/GN=Felix/CN=Felix Werner is not registeredI tried to manually change lower case letters to upper case:
/sn=Werner/gn=Felix/->/SN=Werner/GN=Felix/in the CS and it seems to work fine. However, the VOMS2CSAgent then updates again the CS with lower case letters and users cannot issue a proxy anymore.
Is there some fix needed in dirac-proxy-init or in some other component to handle this use case?
Thank you,
Luisa
Beta Was this translation helpful? Give feedback.
All reactions