[SSSD-users] Re: SSSD setup for authentication against AD using LDAP provider
Hi Jakub, Here's my use case: I'm running Pgpool-II mainly for load balancing requests to PostgreSQL servers. While PgPool-II supports LDAP(AD) or GSSAPI/Kerberos, which I have working, I need PgPool authentication which supports LDAP(AD) via PAM module. PostgreSQL authorization does not utilize LDAP(AD) but database permissions so LDAP(AD) memberships etc. are not needed. cat vi /etc/pam.d/pgpool #%PAM-1.0 authrequiredpam_sss.so account requiredpam_sss.so In addition to auth_provider now I have configured id_provider to be LDAP and I managed to get things to work after setting ldap_id_mapping = true. I'm trying to avoid to join domain which is why I'm using LDAP for AD. One thing that I had to do was to configure ldap_default_bind_dn and ldap_default_authtok, which sucks because I don't want to expose password for some admin account in file. I should be able to get basic info about user using provided credentials using simple non-anonymous bind as I've done in other projects. What is odd is that search queries are performed first and than PAM Authentication with simple bind is done last. In addition, amount of LDAP queries for my simple case is excessive. 5 LDAP queries on objectClass=group for memberships even though I set ldap_group_nesting_level = 0. I have my memberships in memberOf attribute. 1 LDAP query on objectClass=group for ObjectSID 1 LDAP query for my user info 2 LDAP queries for other stuff on objectClass=* Is there a way to avoid using ldap_default_bind_dn and ldap_default_authtok for LDAP? If so, does it mean that user to be authenticated has to have enough permissions to do searches in AD via LDAP? Thank you, Andre On Thu, Aug 9, 2018 at 1:19 PM Jakub Hrozek wrote: > > On Thu, Aug 09, 2018 at 10:06:52AM -0700, Andre Piwoni wrote: > > There does not seem to be much documentation how to make > > authentication work without any extras. All I need is a simple > > non-anonymous bind using provided credentials without any searches. My > > understanding is that I don't need NSS for this only PAM with > > auth_provider set to ldap. However, without id_provider set in > > sssd.conf SSSD does not start at all. This has been reported as a bug > > and supposedly have been fixed before SSSD 1.16.0 version that I'm > > using. I have tried to set id_provider to none but I'm getting some > > indications in logs that id provider is needed. Is it possible to do > > simple non-anonymous bind without anything extra, not even chpass? > > I'm not sure this is possible. One of the core design decisions of SSSD > was that a domain ties authentication and identity source -- so you do > need an id_provider to fetch the identity from somewhere. > > That somewhere might not be the same server or not a remote server at > all, there is also the proxy id_provider that is able to wrap any nss > module, but there needs to be some ID provider. > > What is the use-case you are trying to solve? > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BKVIAMB6KYGJTXNECDM5BPHWP3XE4JTG/ -- Andre Piwoni Sr. Software Developer, BI/Database WebMD Health Services Mobile: 801.541.4722 www.webmdhealthservices.com ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/765EVHKNCV576BM5T72OVQJMVSKJKBLK/
[SSSD-users] Re: SSSD setup for authentication against AD using LDAP provider
On Thu, Aug 09, 2018 at 10:06:52AM -0700, Andre Piwoni wrote: > There does not seem to be much documentation how to make > authentication work without any extras. All I need is a simple > non-anonymous bind using provided credentials without any searches. My > understanding is that I don't need NSS for this only PAM with > auth_provider set to ldap. However, without id_provider set in > sssd.conf SSSD does not start at all. This has been reported as a bug > and supposedly have been fixed before SSSD 1.16.0 version that I'm > using. I have tried to set id_provider to none but I'm getting some > indications in logs that id provider is needed. Is it possible to do > simple non-anonymous bind without anything extra, not even chpass? I'm not sure this is possible. One of the core design decisions of SSSD was that a domain ties authentication and identity source -- so you do need an id_provider to fetch the identity from somewhere. That somewhere might not be the same server or not a remote server at all, there is also the proxy id_provider that is able to wrap any nss module, but there needs to be some ID provider. What is the use-case you are trying to solve? ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BKVIAMB6KYGJTXNECDM5BPHWP3XE4JTG/
[SSSD-users] Re: 1.16.2 test failure: sss_nss_idmap-tests
> > Thank you for figuring out the linker option which caused the issue and > for the suggestions. > > I've opened https://pagure.io/SSSD/sssd/issue/3801 to track the issue > and also created https://github.com/SSSD/sssd/pull/632. Thanks. I commented in the PR. The test now passes on Ubuntu with -Wl,-Bsymbolic-functions enabled. \o/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/HPPLNT4Y4JG4UY4OCO3FDFOCRMJTWA2S/
[SSSD-users] SSSD setup for authentication against AD using LDAP provider
There does not seem to be much documentation how to make authentication work without any extras. All I need is a simple non-anonymous bind using provided credentials without any searches. My understanding is that I don't need NSS for this only PAM with auth_provider set to ldap. However, without id_provider set in sssd.conf SSSD does not start at all. This has been reported as a bug and supposedly have been fixed before SSSD 1.16.0 version that I'm using. I have tried to set id_provider to none but I'm getting some indications in logs that id provider is needed. Is it possible to do simple non-anonymous bind without anything extra, not even chpass? Here's domain log: [sssd[be[fqdn_domainname]]] [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][name=username@fqdn_domainname] [sssd[be[fqdn_domainname]]] [sss_domain_get_state] (0x1000): Domain fqdn_domainname is Active [sssd[be[fqdn_domainname]]] [dp_attach_req] (0x0400): DP Request [Initgroups #1]: New request. Flags [0x0001]. [sssd[be[fqdn_domainname]]] [dp_attach_req] (0x0400): Number of active DP request: 1 [sssd[be[fqdn_domainname]]] [sss_domain_get_state] (0x1000): fqdn_domainname is Active [sssd[be[fqdn_domainname]]] [dp_find_method] (0x0100): Target [id] is not initialized [sssd[be[fqdn_domainname]]] [_dp_req_recv] (0x0400): DP Request [Initgroups #1]: Receiving request data. [sssd[be[fqdn_domainname]]] [dp_req_reply_gen_error] (0x0080): DP Request [Initgroups #1]: Finished. Target is not supported with this configuration. [sssd[be[fqdn_domainname]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:3::fqdn_domainname:name=username@fqdn_domainname] from reply table Why initgroups would be called for authentication? Can I or should I disable it and how? Why target [id] is not initialized? I have disabled id provider (see below). Here's relevant PAM log: [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE [pam_print_data] (0x0100): domain: not set [sssd[pam]] [pam_print_data] (0x0100): user: username [sssd[pam]] [pam_print_data] (0x0100): service: pgpool [pam_print_data] (0x0100): logon name: username [pam_initgr_check_timeout] (0x4000): User [username] not found in PAM cache [cache_req_set_plugin] (0x2000): CR #1: Setting "Initgroups by name" plugin [cache_req_send] (0x0400): CR #1: New request 'Initgroups by name' [cache_req_process_input] (0x0400): CR #1: Parsing input name [username] [sss_parse_name_for_domains] (0x0200): name 'username' matched without domain, user is username [cache_req_set_name] (0x0400): CR #1: Setting name [username] [cache_req_select_domains] (0x0400): CR #1: Performing a multi-domain search [cache_req_search_domains] (0x0400): CR #1: Search will bypass the cache and check the data provider [cache_req_validate_domain_type] (0x2000): Request type POSIX-only for domain fqdn_domainname type POSIX is valid [cache_req_set_domain] (0x0400): CR #1: Using domain [fqdn_domainname] [cache_req_prepare_domain_data] (0x0400): CR #1: Preparing input data for domain [fqdn_domainname] rules [cache_req_search_send] (0x0400): CR #1: Looking up username@fqdn_domainname [cache_req_search_ncache] (0x0400): CR #1: [username@fqdn_domainname] is not present in negative cache [cache_req_search_dp] (0x0400): CR #1: Looking up [fqdn_domainname] in data provider [sss_dp_issue_request] (0x0400): Issuing request for [0x55a33da304c0:3:username@fqdn_domainname@fqdn_domainname] [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [fqdn_domainname][0x3][BE_REQ_INITGROUPS][name=username@fqdn_domainname:-] [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x55a33da304c0:3:username@fqdn_domainname@fqdn_domainname] [sss_dp_get_reply] (0x0100): Data Provider does not support this operation. [cache_req_common_dp_recv] (0x0040): CR #1: Data Provider Error: 3, 5, Failed to get reply from Data Provider [cache_req_common_dp_recv] (0x0400): CR #1: Due to an error we will return cached data [pam_reply] (0x0200): pam_reply called with result [10]: User not known to the underlying authentication module. Why Data Provider does not support this operation? Verification that only auth provider is enabled: [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [none] provider for [id] [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [ldap] provider for [auth] [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [none] provider for [access] [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [none] provider for [chpass] [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [none] provider for [sudo] [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [none] provider for [autofs] [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [none] provider for [selinux] [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [none] provider for [hostid] [sssd[be[fqdn_domainname]]] [dp_load_
[SSSD-users] Re: 1.16.2 test failure: sss_nss_idmap-tests
On Tue, Aug 07, 2018 at 10:38:59PM +0200, Lukas Slebodnik wrote: > On (07/08/18 15:48), Andreas Hasenack wrote: > >On Tue, Aug 7, 2018 at 10:19 AM Sumit Bose wrote: > >> > >> > But something is still unexplained: the same test works just fine in > >> > debian, and doesn't try to connect to that socket. > >> > >> This is just linker magic. Due to my fault > >> sss_nss_make_request_timeout() is defined twice and which symbol is > >> picked might depend on specific linker options used. > > > >I just found out what option that was. Ubuntu, since many years, uses > >-Wl,-Bsymbolic-functions in its default linker flags. Debian doesn't. > > > >The moment I strip this flag from the build, the test passes. I can't > >do that for the official package build, but it's good to know what > >option was causing the test to fail. > > That would need to be disabled just for make check. > Because libsss_nss_idmap_tests.so which is used for testing is not the same > as libsss_nss_idmap.so which is used in reality. > > libsss_nss_idmap_tests.so also export function sss_nss_make_request_timeout > which is not exported in libsss_nss_idmap.so > > sh-4.4$ nm --defined-only --dynamic .libs/libsss_nss_idmap.so | grep request > sh-4.4$ nm --defined-only --dynamic .libs/libsss_nss_idmap_tests.so | grep > request > 4290 T sss_nss_make_request_timeout > > It was done to make testing possible and avoid copy&paste mistakes > > libsss_nss_idmap_tests_la_SOURCES = $(libsss_nss_idmap_la_SOURCES) > libsss_nss_idmap_tests_la_LIBADD = $(libsss_nss_idmap_la_LIBADD) > libsss_nss_idmap_tests_la_LDFLAGS = \ > $(libsss_nss_idmap_la_LDFLAGS) \ > -shared \ > -rpath $(libdir) \ > > -Wl,--version-script,$(srcdir)/src/sss_client/idmap/sss_nss_idmap.unit_tests > > > Other option would be to "include" all sources from library to test. > + use -Wl,-wrap,sss_nss_make_request_timeout > > > Or another hacky way to use weak symbols Thank you for figuring out the linker option which caused the issue and for the suggestions. I've opened https://pagure.io/SSSD/sssd/issue/3801 to track the issue and also created https://github.com/SSSD/sssd/pull/632. I preferred using -Wl,-wrap to make it more consistent with other tests and hopefully also easier to understand. bye, Sumit > > diff --git a/Makefile.am b/Makefile.am > index ea7648bcd..7216561fb 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -2600,12 +2600,13 @@ test_authtok_LDADD = \ > $(NULL) > > sss_nss_idmap_tests_SOURCES = \ > -src/tests/cmocka/sss_nss_idmap-tests.c > +src/tests/cmocka/sss_nss_idmap-tests.c \ > +$(libsss_nss_idmap_la_SOURCES) > sss_nss_idmap_tests_CFLAGS = \ > $(AM_CFLAGS) > sss_nss_idmap_tests_LDADD = \ > $(CMOCKA_LIBS) \ > -libsss_nss_idmap_tests.la \ > +$(libsss_nss_idmap_la_LIBADD) \ > $(NULL) > > deskprofile_utils_tests_SOURCES = \ > diff --git a/src/sss_client/common.c b/src/sss_client/common.c > index 67a460705..a93aaff16 100644 > --- a/src/sss_client/common.c > +++ b/src/sss_client/common.c > @@ -718,6 +718,7 @@ static enum sss_status sss_cli_check_socket(int *errnop, > > /* this function will check command codes match and returned length is ok */ > /* repbuf and replen report only the data section not the header */ > +__attribute((weak)) > enum nss_status sss_nss_make_request_timeout(enum sss_cli_command cmd, > struct sss_cli_req_data *rd, > int timeout, > > LS > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/E2FPZZCLH6YOL2I3FC5R77GFQXZDHRKT/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/LJX5IDXRZDNSQ5U3DJWLVIOZ3DLZE2QA/
[SSSD-users] Re: SSSD cache security
On 8/9/18 11:50 AM, q8ztv...@posteo.de wrote: We are deploying SSSD for authentication with an LDAP backend, and we are getting pushback from our Security colleagues about using SSSD to cache user credentials.. I would like to have some documentation to show them how this cache is kept secure...where can I find information to support this? The sssd developers can answer the technical details in a much better way. But I'd recommend to consider your real requirements: My customer is running sssd on ~ 15000 servers in various data centers (backed by an user management based on OpenLDAP based). The admins are telling me that for them password caching is not useful at all. Because e.g. if the network is down they cannot access the hosts anyway and are just lurking in a telco until the network guys fixed the issue. And even if they can access their hosts it's very unlikely that the admin on duty has used his password on a automatically installed host before. So enabling password caching does not help in this case either. Thus for me the only reasonable use-case for password caching is user login at normal laptops. So they can re-login later while being off-line during a travel. Of course YMMV especially since you did not mention details about your deployment. The above is just meant as food-for-thought. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/UVWYXP3KMYMRC2UWVT6CEX4CVEAMUDS5/
[SSSD-users] Re: SSSD cache security
Hello K., SSSD implements 2 different caching options, one to allow offline logins, and one to allow to grab a kerberos ticket after offline login, once a KDC is reachable, this second option is krb5 specific. To allow offline logins, after a successful authentication attempt against a remote server, the user password is hashed with a strong hash and stored in a dedicated database that is accessible only by SSSD. The password is never stored on disk in the clear and is not directly accessible to users, only root can retrieve the hash, which then has to be brute forced. To allow acquiring an online krb5 ticket when authentication happened offline, you can optionally turn on credential caching. In this case the actual user password is stored securely in the kernel keyring. Only SSSD can access it and the password is removed permanently as soon as a ticket is successfully acquired or the server returns an authentication error that indicates the credentials are invalid (may happen if the user changes their password via a second device, while the first is offline). In this case the password is protected by the kernel in memory and is never swapped to disk. HTH, Simo. On Thu, 2018-08-09 at 11:50 +0200, q8ztv...@posteo.de wrote: > Hello! > > We are deploying SSSD for authentication with an LDAP backend, and we > are getting pushback from our Security colleagues about using SSSD to > cache user credentials.. > > I would like to have some documentation to show them how this cache is > kept secure...where can I find information to support this? > > Thanks! > > K. > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/3TDNX6UVAB3TT25UHVJPT2NRDOJLO4EM/ ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/RJFRKFQ45SMVSEZXNJICSQEYJXGECYEA/
[SSSD-users] Re: SSSD cache security
I would recommend your security department to instead of focusing on Linux/SSSD to take a look at Windows/lsass - Windows is caching user credentials as well and it's not a problem for them? O. -Original Message- From: q8ztv...@posteo.de [mailto:q8ztv...@posteo.de] Sent: Thursday, August 09, 2018 11:51 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] SSSD cache security Hello! We are deploying SSSD for authentication with an LDAP backend, and we are getting pushback from our Security colleagues about using SSSD to cache user credentials.. I would like to have some documentation to show them how this cache is kept secure...where can I find information to support this? Thanks! K. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/3TDNX6UVAB3TT25UHVJPT2NRDOJLO4EM/ - The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/VR6G6WPG2XHSZCCKQDEN5WQL3VFPBIPN/
[SSSD-users] SSSD cache security
Hello! We are deploying SSSD for authentication with an LDAP backend, and we are getting pushback from our Security colleagues about using SSSD to cache user credentials.. I would like to have some documentation to show them how this cache is kept secure...where can I find information to support this? Thanks! K. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/3TDNX6UVAB3TT25UHVJPT2NRDOJLO4EM/
