On Sun, Nov 11, 2012 at 04:37:46PM -0600, Anthony Messina wrote:
> After upgrading to freeipa-{client,server}-2.2.1-1.fc17.x86_64 today, my 
> clients are no longer able to login via kdm or ssh (and perhaps others).  The 
> secure log shows the following:
> 
> sshd[28922]: pam_sss(sshd:account): Access denied for user amessina: 4 
> (System 
> error)
> 
> Of note, I have always had the HBAC allow_all rule enabled--I've never done 
> anything with HBAC since I began using IPA.
> 
> The problem and resolution seems to be the same as 
> https://www.redhat.com/archives/freeipa-users/2012-September/msg00016.html
> 
> where if I uninstall IPA on the clients, then remove the host on the IPA 
> server, then reinstall on the client, things work as expected.
> 
> I have done this for all but one of the clients, and of course, the IPA 
> server, which itself is a client.
> 
> I have increased sssd debugging and find that when trying to login to the 
> servers that have not been reinstalled as above, I get the following 
> significant error in sssd_<domain>.log:
> 
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [be_pam_handler] 
> (0x0100): 
> Got request with the following data
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> command: PAM_ACCT_MGMT
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> domain: messinet.com
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> user: amessina
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> service: sshd
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> tty: ssh
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> ruser: 
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> rhost: 2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> authtok type: 0
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> authtok size: 0
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> newauthtok type: 0
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> newauthtok size: 0
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> priv: 1
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [pam_print_data] 
> (0x0100): 
> cli_pid: 9069
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_access_send] 
> (0x0400): Performing access check for user [amessina]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user 
> [amessina]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(objectClass=ipaHost)(fqdn=ds.messinet.com))]
> [cn=accounts,dc=messinet,dc=com].
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [serverHostName]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [fqdn]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipauniqueid]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 15
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [sdap_process_result] 
> (0x2000): Trace: sh[0x7f553cd5a500], connected[1], ops[0x7f553cd653a0], 
> ldap[0x7f553cd56e20]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] 
> [sdap_get_generic_ext_done] (0x1000): Total count [0]
> (Sun Nov 11 15:35:12 2012) [sssd[be[messinet.com]]] [be_pam_handler_callback] 
> (0x0100): Backend returned: (3, 4, <NULL>) [Internal Error (System error)]
> 
> I also find that when I do a manual ldapsearch for the non-upgraded clients 
> as 
> follows:
> 
> ldapsearch -x -D "cn=directory manager" -W -b cn=accounts,dc=messinet,dc=com 
> "(&(objectClass=ipaHost)(fqdn=*))" dn
> 
> the non-upgraded clients DO NOT appear in the list, but if I do the following:
> 
> ldapsearch -x -D "cn=directory manager" -W -b cn=accounts,dc=messinet,dc=com 
> "(&(objectClass=ipaHost))" dn
> 
> the non-upgraded clients DO appear in the list.  Somehow the addition of the 
> fqdn=* in the filter "(&(objectClass=ipaHost)(fqdn=*))" prevents them from 
> being displayed.
> 
> There were no errors on any of the servers or clients during the upgrade.
> 
> Your help is appreciated.  I've tried to get this corrected all day without 
> success.
> 
> Thanks in advance.  -A

Hi,

the SSSD depends on the fqdn attribute being present for the access
control mechanism. Also, the SSSD searches the directory anonymously, so
in order to get the same results, you should simply search the directory
with anonymous bind.

Can you check on the server how the host entries look like? 

For example:
ipa host-show ds.messinet.com --all --raw

Is the FQDN attribute present in the directory at all?

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to