On Tue, Jun 26, 2018 at 05:14:13PM -0400, [email protected] wrote: > sssd login fails for some user when point to ldaps://127.0.0.1 > > I checked the accounts with ldapsearch -D and there is no issue > > ldapsearch -LLL -x -W -D ou=People,dc=example.dc=net -H ldaps://127.0.0.1 > uid=johnny > Enter LDAP Password: (pass) > gets the ldap entry fine > > When I point sssd to ldaps://corporate.ip all account login works fine > > Log shows .. > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler] > (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][name=johnny@ldap] > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sss_domain_get_state] > (0x1000): Domain LDAP is Active > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): DP > Request [Initgroups #27]: New request. Flags [0x0001]. > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): > Number of active DP request: 1 > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sss_domain_get_state] > (0x1000): Domain LDAP is Active > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP > Request [Initgroups #27]: Receiving request data. > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_reply_gen_error] > (0x0080): DP Request [Initgroups #27]: Finished. Backend is currently > offline. > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_table_value_destructor] > (0x0400): Removing [0:1:0x0001:3::LDAP:name=johnny@ldap] from reply table > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): > DP Request [Initgroups #27]: Request removed. > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): > Number of active DP request: 0 > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_pam_handler] (0x0100): Got > request with the following data > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > command: SSS_PAM_ACCT_MGMT > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > domain: LDAP > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > user: johnny@ldap > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > service: sshd > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): tty: > ssh > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > ruser: > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > rhost: localhost > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > authtok type: 0 > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > priv: 1 > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > cli_pid: 16946 > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): > logon name: not set > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): DP > Request [PAM Account #28]: New request. Flags [0000]. > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): > Number of active DP request: 1 > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sss_domain_get_state] > (0x1000): Domain LDAP is Active > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sdap_access_send] (0x0400): > Performing access check for user [johnny@ldap] > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sdap_access_filter_send] > (0x0400): Performing access filter check for user [johnny@ldap] > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sdap_access_decide_offline] > (0x0400):* Access denied by cached credentials* > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sdap_access_done] > (0x0400): *Access > was denied*.
Looks like the backend is currently in the offline state and tries to grant or deny access based on cached data. The result of the last online check is stored in the ldap_access_filter_allow attribute in the cached user object. If this attribute does not exist the default is 'false' i.e. deny access. So you should check in the logs why the backend is offline and what was the state of the last online access control check for this user. bye, Sumit > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP > Request [PAM Account #28]: Request handler finished [0]: Success > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP > Request [PAM Account #28]: Receiving request data. > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): > DP Request [PAM Account #28]: Request removed. > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400): > Number of active DP request: 0 > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_method_enabled] (0x0400): > Target selinux is not configured > (Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_pam_reply] (0x1000): DP > Request [PAM Account #28]: Sending result [6][LDAP] > > Jun 26 18:48:10 host sshd[16946]: pam_sss(sshd:auth): authentication > success; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=blodgen > Jun 26 18:48:10 host sshd[16946]: pam_sss(sshd:account): Access denied for > user blodgen: 6 (Permission denied) > Jun 26 18:48:10 host sshd[16938]: error: PAM: User account has expired for > blodgen from localhost > > Here is the sssd config and using sssd version 1.16 > > [sssd] > config_file_version = 2 > reconnection_retries = 3 > sbus_timeout = 30 > services = nss,pam,sudo > domains = LDAP > homedir_substring = undef > > [nss] > reconnection_retries = 3 > filter_groups = root,wheel > filter_users = root > > [pam] > reconnection_retries = 3 > offline_credentials_expiration = 0 > > [sudo] > > [domain/LDAP] > debug_level = 7 > chpass_provider = ldap > access_provider = ldap > id_provider = ldap > auth_provider = ldap > ldap_schema = rfc2307bis > ldap_id_use_start_tls = true > ldap_search_base = ou=People,dc=example,dc=net > #ldap_uri = ldaps://192.168.1.100:1636 > ldap_uri = ldaps://127.0.0.1 > ldap_access_order = filter > ldap_access_filter = objectClass=mnetperson > ldap_user_uid_number = mnetid > ldap_user_gid_number = mnetid > ldap_group_gid_number = mnetid > ldap_group_object_class = inetOrgPerson > ldap_user_object_class = mnetPerson > ldap_user_fullname = uid > ldap_group_name = uid > ldap_network_timeout = 3 > ldap_tls_reqcert = allow > ldap_tls_cacert = /etc/ssl/certs/host.cer > ldap_chpass_update_last_change = true > ldap_pwd_policy = none > ldap_account_expire_policy = none > ldap_default_authtok_type = password > ldap_default_bind_dn = uid=binduid,ou=People,dc=example,dc=net > ldap_default_authtok = secret > enumerate = false > > sudo_provider = ldap > ldap_sudo_search_base = ou=People,dc=example,dc=net > ldap_sudorule_object_class = mnetperson > > cache_credentials = true > default_shell = /bin/bash > fallback_homedir = /home/%u > > > > -- > Asif Iqbal > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/A4FD6EE2T2WTU5MB2AB6CVSZOUFAISWC/ _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/PMQWQN6X2B5EUO4FENQTRXBNUS2KVLPA/
