On 12/21/2014 01:39 PM, Brendan Kearney wrote:
> i have sssd working with nss, pam, sudo and autofs against openldap and
> mit kerberos, using the rfc2307 schema for posix account types. with
> it, i am able to sudo without passwords as i have a sudoOption set to "!
> authenticate".
>
> i am building a new, parallel environment updated to use rfc2307bis, and
> have sssd working with nss, pam, sudo and autofs, but when i attempt
> sudo, i am prompted for my password. i have checked the sudoOption, and
> it is set to "!authenticate". i am allowed to sudo if i enter my
> password, but it seems the NOPASSWD equivalent is not being picked up
> for some reason.
>
> another interesting tidbit is that when i run "sudo -l" in the old
> environment, the output ends with:
>
> User brendan may run the following commands on desktop:
> (ALL) NOPASSWD: ALL
>
> when i run "sudo -l" in the new environment, the output ends with:
>
> User brendan may run the following commands on server1:
> (ALL) ALL
> (ALL) ALL
> (ALL) NOPASSWD: ALL
>
> it seems to me that sudoHost, sudoCommand or some other objects are
> causing conflict and something does not compute correctly. why are
> there 3 lines of access rules, when only one exists for my ID.
>
> oddly enough, i just found this behavior: when i first attempt to sudo,
> i am prompted for my password. if i enter it, and gain sudo access, any
> subsequent requests for sudo are not authenticated, per session. if i
> logout/end my ssh session, and go back in i have to enter my password
> once for sudo access and again subsequent sudo requests do not prompt
> for a password.
>
> is there a setting that i need to change other than ldap_schema? the
> ldap_sudo_search_base is set to the correct location in the directory,
> since i am not using the default.
>
> selinux is disabled
>
> my sssd.conf
> ------------
>
> [sssd]
> domains =
bpk2.com
> services = nss, pam, sudo, autofs
> config_file_version = 2
> #debug_level = 4
>
> [nss]
> filter_groups = root
> filter_users = root
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [
domain/bpk2.com]
> #debug_level = 4
> id_provider = ldap
> ldap_schema = rfc2307bis
> ldap_uri =
_srv_,ldap://ldap1.bpk2.com,ldap://ldap2.bpk2.com
> ldap_search_base = dc=bpk2,dc=com
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid =
host/server1.bpk2.com
> ldap_sasl_realm =
BPK2.COM
>
> auth_provider = krb5
> krb5_server =
_srv_,kerberos.bpk2.com
> krb5_realm =
BPK2.COM
> krb5_renewable_lifetime = 7d
> krb5_lifetime = 24h
> krb5_renew_interval = 1h
> krb5_store_password_if_offline = true
> cache_credentials = true
>
> sudo_provider = ldap
> ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com
> #ldap_sudo_full_refresh_interval = 86400
> #ldap_sudo_smart_refresh_interval = 3600
>
> autofs_provider = ldap
> ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,dc=com
> ldap_autofs_map_object_class = automountMap
> ldap_autofs_entry_object_class = automount
> ldap_autofs_map_name = automountMapName
> ldap_autofs_entry_key = automountKey
> ldap_autofs_entry_value = automountInformation
>
> #min_id = 1000
> #max_id = 2000
> enumerate = false
>
> /var/log/sssd/sssd_nss.log contains some lines:
> (Sun Dec 21 12:02:58 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 12:07:59 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:19:33 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:21:36 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:21:51 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:22:09 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:22:30 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:22:45 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:23:21 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:23:41 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:29:53 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:31:42 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
> (Sun Dec 21 13:32:09 2014) [sssd[nss]] [nss_cmd_getgrgid_search]
> (0x0010): getgrgid call returned more than one result !?!
>
> i am also seeing in /var/log/sssd/sssd_bpk2.com.log:
> (Sun Dec 21 11:24:31 2014) [sssd[be[bpk2.com]]] [load_backend_module]
> (0x0010): Error (22) in module (ldap) initialization
> (sssm_ldap_sudo_init)!
> (Sun Dec 21 11:24:31 2014) [sssd[be[bpk2.com]]] [be_process_init]
> (0x0010): fatal error initializing data providers
> (Sun Dec 21 11:24:31 2014) [sssd[be[bpk2.com]]] [main] (0x0010): Could
> not initialize backend [22]
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Sorry for a delayed response.
22 is probably EINVAL which means there something invalid passed into a
some of the API functions i.e. something is configured in an unexpected way.
getgrgid returning more than one result indicates that you got more than
one group entry for a single group search.
That might end up causing the EINVAL though I am not 100% sure.
I suggest checking your openLDAP server.
Do you have more than one subtree? Can it be that you have duplicate
data (2307 and 2307 bis in the same server just different sub trees)?
May be you need to adjust ldap_search_base to pick a subset of entries
to avoid duplicates?
i found my issue. i had my user id defined as a sudo ID, and as a
member of the wheel group, which had sudo rules assigned to it. because
the wheel group processed in the rules before my id, i got the access
granted to the wheel group, and the rest was "fall through" and
ineffective. i have fixed the issue, and now get the proper behavior.
PEBKAC - Problem Exists Between Keyboard And Chair.