-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
webdav door reports a login error when trying to request a macaroon #7533
Comments
Hi Arpad, dCache will provide a detailed explanation of a login failure in the log file (of the domain hosting gPlazma) the first time gPlazma sees a failed login attempt. Subsequent failed login attempts (with the same credentials and door-supplied principals) are not logged. My guess is that there was a login attempt (possible from a macaroon request) that failed some point in the past. gPlazma will reset the login failures (and so, provide a detailed log report on failures) when it reloads its configuration. The easiest way to do that is to update the last-modified time of the gPlazma configuration file (e.g., So, HTH, |
Hi Paul, Thanks. |
Hi Arpad, Could you copy (into this issue) the login failure report, as recorded in the domain log file (from the domain hosting gPlazma)? It should look like the Cheers, |
Here there is no username given because "map optional gridmap" is deactivated. It seems like we don't staging requests when it's active. |
I activated it to produce the log and then deactivated it again:
|
In your
However, for the Macaroon request, you are presenting your EEC. There's no VOMS proxy, so the This should explain the discrepancy between Removing the FQAN principal from the If you want to support EEC-based AuthN then the problem you're facing is from the gridmap plugin adding a username. The kpwd plugin requires exactly one mapping principal: either a Login name, an X.509 DN, a Kerberos principal, a username principal or a gid principal. So, you should be able to configure the kpwd plugin to support X.509 DN and omit the gridmap plugin. Alternatively, don't use kpwd plugin, but use something else to map the username principal to uid and gid. The authzdb plugin should work. HTH, |
Hello,
I'm out of ideas about this one. Maybe it's a bug, maybe I'm doing something wrong, but here we go.
We have a webdav door which I want to use to request macaroons.
The layout of it is:
in /etc/grid-security/grid-mapfile and grid-vorolemap I have the line
"/C=DE/O=GridGermany/OU=Forschungszentrum Juelich GmbH/CN=Arpad Miskolczi" lofar001
and
"/C=DE/O=GridGermany/OU=Forschungszentrum Juelich GmbH/CN=Arpad Miskolczi" "/lofar/ops" lofar001
When I try to request a macaroon using curl, I used:
curl -vvv -k --cert ./grid_cert.pem --key ./grid_key.pem -X POST -H 'Content-Type: application/macaroon-request' -d '{"caveats": ["activity:LIST","path:/pnfs/fz-juelich.de/data/utr2/"]}' https://dcache-lofar.fz-juelich.de:2893
where grid_cert/key.pem is the certificate and key that corresponds to the line in the files.
I also tried adding --capath /etc/grid-security/certificates/ to the command, but it has no effect.
After the request, I see in the log:
level=WARN ts=2024-03-15T13:12:42.358+0100 event=org.dcache.webdav.request request.method=POST request.url=https://dcache-lofar.fz-juelich.de:2893/ response.code=401 response.reason="login failed" socket.remote=134.94.0.52:45536 user-agent=curl/7.29.0 user.dn="CN=Arpad Miskolczi,OU=Forschungszentrum Juelich GmbH,O=GridGermany,C=DE" duration=0
Now what I noticed is that the order of the dn entries is different and the fields are delimited by a comma instead of a dash. I don't know if that is important. But in case it is not, I also put in this version of the dn in to the above mentioned files, exactly how the log says.
Then I used "explain login" from the gPlazma domain:
So the login using this dn is working according to gPlazma. But yet again, requesting the macaroon results in an login failed error.
Even if the group or user id, or a path would be wrong, I would expect a permission denied instead of a login failed.
If some firewall issue would be present, I would expect a connection error. Though I'm trying this from the same server where the door is on.
If I enable basic authorization and use a username and password it works flawlessly.
We use dcache 7.2.12
I did try to set the logging verbosity to DEBUG, but then it's so many lines that I can't make heads or tails of it.
Is this some bug? Am I missing something? Do you need more information from other files?
Thanks!
Cheers,
Arpad
The text was updated successfully, but these errors were encountered: