Below is the output from the sss_<domain>.log when i ran the sudo
command as the user.  I see things about offline replies and LDAP not
working.  Is this my problem or is this part of a normal series of
items that are tried?



(Mon Aug 25 11:53:23 2014) [sssd[be[server.example.com]]]
[be_get_account_info] (0x0100): Got request for
[4098][1][idnumber=1079600005]

(Mon Aug 25 11:53:23 2014) [sssd[be[server.example.com]]]
[be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast
reply - offline

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_get_account_info] (0x0100): Got request for [3][1][name=tuser2]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler] (0x0100): Got request with the following data

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): command: PAM_AUTHENTICATE

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): domain: server.example.com

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): user: tuser2

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): service: sudo

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): tty: /dev/pts/1

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): ruser: tuser2

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): rhost:

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): authtok type: 1

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): authtok size: 23

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): newauthtok type: 0

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): newauthtok size: 0

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): priv: 0

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): cli_pid: 17822

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[check_for_valid_tgt] (0x0080): TGT is valid.

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[resolve_srv_send] (0x0200): The status of SRV lookup is neutral

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[resolve_srv_cont] (0x0100): Searching for servers via SRV query
'_ldap._tcp.server.example.com'

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[resolv_getsrv_send] (0x0100): Trying to resolve SRV record of
'_ldap._tcp.server.example.com'

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[resolve_srv_done] (0x0020): SRV query failed: [Domain name not found]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as
'not working'

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as
'not resolved'

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_resolve_server_process] (0x0080): Couldn't resolve server (SRV
lookup meta-server), resolver returned (5)

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_resolve_server_process] (0x0200): Found address for server
dir1.server.example.com: [10.10.26.148] TTL 7200

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[krb5_find_ccache_step] (0x0080): Saved ccache
FILE:/tmp/krb5cc_1079600005_Hfzpn4 if of different type than ccache in
configuration file, reusing the old ccache

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[sysdb_cache_auth] (0x0100): Hashes do match!

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler_callback] (0x0100): Backend returned: (1, 9, <NULL>)
[Provider is Offline (Authentication service cannot retrieve
authentication info)]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler_callback] (0x0100): Sending result
[9][server.example.com]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler_callback] (0x0100): Sent result
[9][server.example.com]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler] (0x0100): Got request with the following data

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): command: PAM_ACCT_MGMT

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): domain: server.example.com

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): user: tuser2

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): service: sudo

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): tty: /dev/pts/1

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): ruser: tuser2

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): rhost:

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): authtok type: 0

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): authtok size: 0

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): newauthtok type: 0

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): newauthtok size: 0

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): priv: 0

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[pam_print_data] (0x0100): cli_pid: 17822

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[hbac_get_category] (0x0200): Category is set to 'all'.

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[hbac_get_category] (0x0200): Category is set to 'all'.

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[hbac_get_category] (0x0200): Category is set to 'all'.

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule
[allow_all]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>)
[Success]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success)
[Success]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler_callback] (0x0100): Sending result
[0][server.example.com]

(Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]]
[be_pam_handler_callback] (0x0100): Sent result
[0][server.example.com]

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[get_port_status] (0x0100): Reseting the status of port 389 for server
'dir1.server.example.com'

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[be_resolve_server_process] (0x0200): Found address for server
dir1.server.example.com: [10.10.26.148] TTL 7200

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service
'KERBEROS'

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[be_resolve_server_process] (0x0200): Found address for server
dir1.server.example.com: [10.10.26.148] TTL 7200

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[child_sig_handler] (0x0100): child [17823] finished successfully.

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address]

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[fo_set_port_status] (0x0100): Marking port 389 of server
'dir1.server.example.com' as 'not working'

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[fo_resolve_service_send] (0x0020): No available servers for service
'LDAP'

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[sdap_id_op_connect_done] (0x0020): Failed to connect, going offline
(5 [Input/output error])

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[be_run_offline_cb] (0x0080): Going offline. Running callbacks.

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full
refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily
unavailable)

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[remove_krb5_info_files] (0x0200): Could not remove
[/var/lib/sss/pubconf/kpasswdinfo.server.example.com], [2][No such
file or directory]

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[remove_krb5_info_files] (0x0200): Could not remove
[/var/lib/sss/pubconf/kdcinfo.server.example.com], [2][No such file or
directory]

(Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]]
[remove_krb5_info_files] (0x0200): Could not remove
[/var/lib/sss/pubconf/kpasswdinfo.server.example.com], [2][No such
file or directory]

On Mon, Aug 25, 2014 at 7:08 AM, Alexander Bokovoy <aboko...@redhat.com> wrote:
> On Mon, 25 Aug 2014, Martin Kosek wrote:
>>
>> On 08/25/2014 12:51 PM, Megan . wrote:
>>>
>>> Good Morning,
>>>
>>> I'm very new to freeIPA.
>>
>>
>> Welcome on board!
>>
>>> I'm running centOS 6.5 with freeIPA v3
>>>
>>> I have the freeIPA server up but i'm working on getting SUDO
>>> configured.  Currently i'm having problems getting sudo commands to
>>> work on the client.  I'm a bit unclear if i have everything configured
>>> correctly.  The only thing that I can figure out might be an issue, is
>>> when i try the sudo command i see a filter search with
>>> objectclass=sudoRule but when i check the ldap server it has
>>> objectclass=sudoRole, so there are no results.
>>
>>
>> According to
>> http://www.sudo.ws/sudoers.ldap.man.html
>>
>> the objectclass in the schema should really read "sudoRole" (I know, may
>> be
>> confusing).
>>
>>> Any ideas?  Thank you in advance for any advice.
>>
>>
>> Where do you see the filter?
>>
>>>
>>> [tuser2@map1 ~]$ sudo /sbin/iptables -L
>>> Enter RSA PIN+token:
>>> tuser2 is not allowed to run sudo on map1.  This incident will be
>>> reported.
>>>
>>>
>>> CLIENT:
>>>
>>> yum installed libsss_sudo
>>>
>>> I added "nisdomainname dir1.server.example.com" to /etc/rc.d/rc.local
>>>
>>> **still not sure what this is for **
>>
>>
>> This is for setting the NIS domain permanently. sudo uses NIS domains when
>> it
>> uses sudo rules with host groups instead of individual host names.
>>
>>> Created a sudo user on ldap server
>>> ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D "cn=Directory
>>> Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com
>>> **
>>>
>>>
>>> [root@map1 sssd]# cat /etc/nsswitch.conf
>>> #
>>> passwd:     files sss
>>> shadow:     files sss
>>> group:      files sss
>>> sudoers:    files sss
>>> sudoers_debug: 1
>>> #sudoers:    files
>>> hosts:      files dns
>>> bootparams: files
>>> ethers:     files
>>> netmasks:   files
>>> networks:   files
>>> protocols:  files
>>> rpc:        files
>>> services:   files sss
>>> netgroup:   files sss
>>> publickey:  files
>>> automount:  files ldap
>>> aliases:    files
>>> [root@map1 sssd]#
>>>
>>>
>>>
>>>
>>>
>>> [root@map1 sssd]# cat sssd.conf
>>> [domain/server.example.com]
>>>
>>> debug_level = 5
>>> cache_credentials = True
>>> krb5_store_password_if_offline = True
>>> ipa_domain = server.example.com
>>> id_provider = ipa
>>> auth_provider = ipa
>>> access_provider = ipa
>>> ipa_hostname = map1.server.example.com
>>> chpass_provider = ipa
>>> ipa_server = _srv_, dir1.server.example.com
>>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=server,dc=example,dc=com
>>> ldap_tls_cacert = /etc/ipa/ca.crt
>>>
>>> sudo_provider = ldap
>>> ldap_uri = ldap://dir1.server.example.com
>>> ldap_sudo_search_base = ou=sudoers,dc=server,dc=example,dc=com
>>> ldap_sasl_mech = GSSAPI
>>> ldap_sasl_authid = host/dir1.server.example.com
>>> ldap_sasl_realm = server.example.com
>>> krb5_server = dir1.server.example.com
>>>
>>> [sssd]
>>> services = nss, pam, ssh, sudo
>>> config_file_version = 2
>>>
>>> domains = server.example.com
>>> [nss]
>>>
>>> [pam]
>>>
>>> [sudo]
>>> debug_level=5
>>>
>>> [autofs]
>>>
>>> [ssh]
>>>
>>> [pac]
>>>
>>>
>>>
>>>
>>> from the sssd_sudo.log
>>>
>>> (Mon Aug 25 10:36:31 2014) [sssd[sudo]]
>>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>>
>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408962991)))]
>>> (Mon Aug 25 10:36:31 2014) [sssd[sudo]]
>>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>>>
>>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*)))]
>>> (Mon Aug 25 10:36:33 2014) [sssd[sudo]] [client_recv] (0x0200): Client
>>> disconnected!
>>
>>
>> I do not understand why it searches with "sudorule" objectclass. According
>> to
>> sssd-ldap man page, ldap_sudorule_object_class should default to
>> "sudoRole".
>> Jakub or Pavel, any idea?
>
> It is a search against SSSD's local cache where the object class is
> sudoRule. A correct entry for searching against LDAP server should be in the
> sss_<domain>.log
>
> --
> / Alexander Bokovoy

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to