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_configuration] (0x0100): Using [none] provider for [subdomains] [sssd[be[fqdn_domainname]]] [dp_load_configuration] (0x0100): Using [none] provider for [session]
Andre Piwoni
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?
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 auth required pam_sss.so account required pam_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 jhrozek@redhat.com 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-leave@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....
On 10 Aug 2018, at 02:29, Andre Piwoni apiwoni@webmd.net wrote:
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 auth required pam_sss.so account required pam_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.
I’m not sure this is permitted by AD by default. I think AD requires you to authenticate in one way or another.
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.
This might be https://pagure.io/SSSD/sssd/issue/3425 ?
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?
For generic LDAP yes, as a matter of fact, this is the default, but the client can only do what the server allows it to do.
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 jhrozek@redhat.com 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-leave@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....
--
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-leave@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....
AD allows simple authentication via simple non-anonymous bind with user credentials (https://msdn.microsoft.com/en-us/library/cc223499.aspx) and this is enough to get at least user account information, which includes basic group memberships. Most ADs that I worked with, in addition to authenticated user info, allow other browsing after this step. This includes extended group membership, like nested groups and info.
Anyway, I have decided to join server to AD domain since this does not require elevated admin account with password.
Thank you, Andre
On Tue, Aug 14, 2018 at 3:20 AM Jakub Hrozek jhrozek@redhat.com wrote:
On 10 Aug 2018, at 02:29, Andre Piwoni apiwoni@webmd.net wrote:
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 auth required pam_sss.so account required pam_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.
I’m not sure this is permitted by AD by default. I think AD requires you to authenticate in one way or another.
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.
This might be https://pagure.io/SSSD/sssd/issue/3425 ?
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?
For generic LDAP yes, as a matter of fact, this is the default, but the client can only do what the server allows it to do.
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 jhrozek@redhat.com 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-leave@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....
--
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-leave@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....
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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....
On Wed, Aug 22, 2018 at 09:42:55AM -0700, Andre Piwoni wrote:
AD allows simple authentication via simple non-anonymous bind with user credentials (https://msdn.microsoft.com/en-us/library/cc223499.aspx) and this is enough to get at least user account information, which includes basic group memberships. Most ADs that I worked with, in addition to authenticated user info, allow other browsing after this step. This includes extended group membership, like nested groups and info.
Ah, sorry, yes, I misread your earlier e-mail. You wrote:
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.
And I skipped the 'admin' word and thought you dislike having a password in the config file at all and were looking for using an anonymous bind.
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.
And this should be possible using ldap_default_bind_dn and ldap_default_authtok
sssd-users@lists.fedorahosted.org
-
Andre Piwoni -
Jakub Hrozek