Bug #23091
closedBug #35988: RGW Ldap Authorization fails
rgw + OpenLDAP = Failed the auth strategy, reason=-13
0%
Description
Hello, recently I posted this question to users ML, but don't receive any feedback.
More at ML: http://lists.ceph.com/pipermail/ceph-users-ceph.com/2018-February/024771.html
Updated by Matt Benjamin about 6 years ago
@konstantin, thanks, I'm working on LDAP auth now, I'll take a look.
Matt
Updated by Konstantin Shalygin about 6 years ago
@Matt Li, thanks. I read ldap_set_option(3), and figure out: lib have server_control and client_control. So my reject is (obviously) is client_control. May be this help.
Updated by Yehuda Sadeh about 6 years ago
- Status changed from New to Closed
Closing it, if the issue is not resolved yet then feel free to reopen it.
Updated by Konstantin Shalygin about 6 years ago
@Yehuda Sadeh I don't have 'reopen' button.
This is not resolved for me.
Updated by Anonymous over 5 years ago
I believe that I have run into this issue in the sepia lab.
Running rgw on vpm019 (ceph cluster vpm019 vpm125 vpm153) ldap server vpm169
2018-09-14 18:14:46.797 7efdea2e2700 10 moving default.rgw.meta+users.keys+ewogICAgIlJHV19UT0tFTiI6IHsKICAgICAgICAidmVyc2lvbiI6IDEsCiAgICAgICAgInR5cGUiOiAibGRhcCIsCiAgICAgICAgImlkIjogInRlc3R1c2VyIiwKICAgICAgICAia2V5IjogIi9ldGMvYmluZHBhc3MiCiAgICB9Cn0K to cache LRU end 2018-09-14 18:14:46.797 7efdea2e2700 5 error reading user info, uid=ewogICAgIlJHV19UT0tFTiI6IHsKICAgICAgICAidmVyc2lvbiI6IDEsCiAgICAgICAgInR5cGUiOiAibGRhcCIsCiAgICAgICAgImlkIjogInRlc3R1c2VyIiwKICAgICAgICAia2V5IjogIi9ldGMvYmluZHBhc3MiCiAgICB9Cn0K can't authenticate 2018-09-14 18:14:46.797 7efdea2e2700 20 rgw::auth::s3::LocalEngine denied with reason=-2028 2018-09-14 18:14:46.797 7efdea2e2700 20 rgw::auth::s3::AWSAuthStrategy denied with reason=-13 2018-09-14 18:14:46.797 7efdea2e2700 5 Failed the auth strategy, reason=-13 2018-09-14 18:14:46.797 7efdea2e2700 10 failed to authorize request 2018-09-14 18:14:46.797 7efdea2e2700 20 handler->ERRORHANDLER: err_no=-13 new_err_no=-13 2018-09-14 18:14:46.801 7efdea2e2700 2 req 10:1.019706:s3:PUT /testuser-new-bucket/:create_bucket:op status=0 2018-09-14 18:14:46.801 7efdea2e2700 2 req 10:1.019745:s3:PUT /testuser-new-bucket/:create_bucket:http status=403 2018-09-14 18:14:46.801 7efdea2e2700 1 ====== req done req=0x7efdea2d9830 op status=0 http_status=403 ====== 2018-09-14 18:14:46.801 7efdea2e2700 20 process_request() returned -13 2018-09-14 18:14:46.801 7efdea2e2700 1 civetweb: 0x55bdfea0c000: 172.21.2.19 - - [14/Sep/2018:18:14:45 +0000] "PUT /testuser-new-bucket/ HTTP/1.1" 403 389 - Boto/2.49.0 Python/2.7.12 Linux/4.4.0-24-generic 2018-09-14 18:14:52.165 7efe03efa700 2 RGWDataChangesLog::ChangesRenewThread: start
I can run ldapsearch from vpm019 using the binddn and searchdn that I set in /etc/ceph/ceph.conf and find the user.
Updated by Anonymous over 5 years ago
- Status changed from Closed to Duplicate
- Priority changed from Normal to Low
- Parent task set to #35988
I could not reopen this. So I opened a new report and marked this as a duplicate.