Test PAM config
disneyforward

SSSD config
sssd.conf

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?

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.

I suggest closing this. We have similar tickets that are in deferred bucket.

Fields changed

milestone: NEEDS_TRIAGE => SSSD Deferred
resolution: => duplicate
status: new => closed

Fields changed

rhbz: => 0

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3340

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.