Would like to use SSSD for auithentication forwarding ONLY #3340
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2298
I would like to use SSSD for authentication forwarding ONLY. I want to use the 389 LDAP server to hold local information about users of my site. Some of the users are not in my company, and their company would like us to be able to set up authentication forwarding to their own LDAP servers. Given this, I have absolutely NO control over how users are defined in the remote LDAP, and if they are not defined with posixUser attributes (i.e. gidNumber) then the forwarded authentication fails in SSSD with:
The bind and search for the user worked fine:
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
Is there any way to have the authentication return a good return code, even if the user cannot be stored in the cache?
Comments
Comment from gretchch at 2014-04-02 16:27:15
Test PAM config
disneyforward
Comment from gretchch at 2014-04-02 16:28:16
SSSD config
sssd.conf
Comment from jhrozek at 2014-04-02 17:18:53
I'm afraid this is currently not possible, the SSSD internally relies on some kind of ID. The ID can either be read from LDAP, which is the default or mapped from a SID in the case of AD. The only hack I can think about is to use another nss module wrapped in the proxy provider..
But I wonder if this use-case is something adelton, who is working on web apps integration would consider interesting?
cc: => adelton
description: I would like to use SSSD for authentication forwarding ONLY. I want to use the 389 LDAP server to hold local information about users of my site. Some of the users are not in my company, and their company would like us to be able to set up authentication forwarding to their own LDAP servers. Given this, I have absolutely NO control over how users are defined in the remote LDAP, and if they are not defined with posixUser attributes (i.e. gidNumber) then the forwarded authentication fails in SSSD with:
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_save_user] (0x0400): Processing user gretchen.chiaramonte@cloudpay.net
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSID] attribute while id-mapping. [0][Success]
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_save_user] (0x4000): objectSID: not available for group [gretchen.chiaramonte@cloudpay.net].
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_save_user] (0x0020): no gid provided for [gretchen.chiaramonte@cloudpay.net] in domain [cloudpay.net].
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_save_user] (0x0020): Failed to save user [gretchen.chiaramonte@cloudpay.net]
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0)
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_id_op_done] (0x4000): releasing operation connection
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,22,Init group lookup failed
The bind and search for the user worked fine:
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
Is there any way to have the authentication return a good return code, even if the user cannot be stored in the cache? => I would like to use SSSD for authentication forwarding ONLY. I want to use the 389 LDAP server to hold local information about users of my site. Some of the users are not in my company, and their company would like us to be able to set up authentication forwarding to their own LDAP servers. Given this, I have absolutely NO control over how users are defined in the remote LDAP, and if they are not defined with posixUser attributes (i.e. gidNumber) then the forwarded authentication fails in SSSD with:
{{{
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_save_user] (0x0400): Processing user gretchen.chiaramonte@cloudpay.net
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSID] attribute while id-mapping. [0][Success]
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_save_user] (0x4000): objectSID: not available for group [gretchen.chiaramonte@cloudpay.net].
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_save_user] (0x0020): no gid provided for [gretchen.chiaramonte@cloudpay.net] in domain [cloudpay.net].
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_save_user] (0x0020): Failed to save user [gretchen.chiaramonte@cloudpay.net]
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [ldb] (0x4000): cancel ldb transaction (nesting: 0)
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_id_op_done] (0x4000): releasing operation connection
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,22,Init group lookup failed
}}}
The bind and search for the user worked fine:
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Wed Apr 2 10:09:28 2014) [sssd[be[cloudpay.net]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
Is there any way to have the authentication return a good return code, even if the user cannot be stored in the cache?
Comment from dpal at 2014-04-04 22:58:50
May be you should try to use PAM proxy capability of the 389 DS server. SSSD will be configured against 389 and then 389 would be configured to use pam to proxy mind operations for particular users.
See http://port389.org/wiki/Howto:PAM_Pass_Through for more details.
Comment from dpal at 2014-04-04 23:00:11
I suggest closing this. We have similar tickets that are in deferred bucket.
Comment from dpal at 2014-04-10 15:23:33
Fields changed
milestone: NEEDS_TRIAGE => SSSD Deferred
resolution: => duplicate
status: new => closed
Comment from dpal at 2014-04-10 18:13:04
Fields changed
rhbz: => 0
Comment from gretchch at 2017-02-24 14:47:06
Metadata Update from @gretchch:
The text was updated successfully, but these errors were encountered: