Configuring Sudo using SSSD

Trying to Login to Linux systems using windows AD account. Configured successfully using SSSD.

Used LDAP as Identity & Access Providers and Kerberos as the Authentication provider.

I have done all this without joining the linux systems to the domain.

Now I'm trying to configure LDAP as sudo provider. But its not successfull. I'm not able to elevate the sudo permissions to the ad users. I've even tried using sudoers file, there i'm able to elevate permissions to the specific user, but not to the ad group.

Here's the SSSD config w.r.t sudo configuration

**sudo_provider = ldap

ldap_sudo_search_base = ou=groups,dc=ad,dc=example,dc=com
ldap_sudorule_object_class = sudoRole
ldap_sudorule_object_class = top
ldap_sudorule_command = ALL
ldap_sudorule_host = ALL
ldap_sudorule_user = %domain_group
ldap_sudorule_runasuser = ALL
ldap_sudorule_runas = ALL
ldap_sudorule_runasgroup = ALL
ldap_sudorule_option = !authenticate**

I've tried enabling logging at debug level 7, its mentioning that unable to load local rules.

Regards, Uday.

I think you misunderstood the purpose of the config file switches - they serve to map the LDAP values of the queried objects. The directives default to the values specified by the auxiliary object class (schema is in /usr/share/doc/sudo-*/schema.ActiveDirectory on CentOS).

You are supposed to import this schema in your AD, create objects representing sudo roles using this object class and have SSSD query them.

Find an exhaustive example below:

Here's a sample SSSD config querying users, groups, and sudo roles from LDAP. Replace the <> enclosed parts with values fitting your environment:

[domain/default]
id_provider = ldap
auth_provider = ldap
access_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
ldap_uri = ldaps://<ldap-server-address>:636
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_tls_reqcert = demand
ldap_default_bind_dn = <proxy-user-dn>
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = <obfuscated password>                                                                                      
ldap_search_base = <search base for users>
ldap_schema = rfc2307bis
ldap_group_search_base = <search base for groups>
ldap_sudo_search_base = <search base for sudo rules>
cache_credentials = false
enumerate = false

[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
domains = default

[nss]

[pam]

[sudo]

[autofs]

[ssh]

In your LDAP directory, create an object below ldap_sudo_search_base looking something like this:

objectClass: Top
objectClass: sudoRole
sudoRunAsUser: ALL
sudoHost: yourhost.example.com
sudoUser: %wheel
sudoCommand: ALL
description: Allows members of wheel to become root
cn: wheel_group_sudo_role

This allows all members of the group wheel to become root on the host yourhost.example.com.

Running sudo -U testuser -ll as root on the target host should yield:

LDAP Role: wheel_group_sudo_role
    RunAsUsers: ALL
    RunAsGroups: ALL
    Commands:
        ALL

edit:

As you've figured, as SSSD provides users to a Linux box, you may treat them as regular Linux users and thus create a local sudo rule:

/etc/sudoers.d/00-local-admin-rule

%ad-admin-group ALL: (ALL) ALL

This allows members of the ad-admin-group to call sudo to become root.

When talking about *_search_base, the DN of some form of LDAP container object is meant, e.g. an organizational unit like ou=users,o=corg,dc=example,dc=org or whatever hierarchy your directory features. Create the objects of the desired types below the specified container.