On (09/12/13 21:47), Aaron Johnson wrote:
I am trying to get SSSD working with Samba 4 AD including sudo.

I have SSSD working using RFC2307 UNIX attributes which is great.

Now I have extended my AD schema using the schema.ActiveDirectory
ldif that came with my distribution (Debian jessie)

Then I used sudoers2ldif to create an ldif for a simple sudo rule and
imported it into AD using ldifde:

export SUDOERS_BASE='OU=SUDOers,DC=example,DC=com'
./sudoers2ldif sudoers

dn: cn=defaults,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
sudoOrder: 1

dn: cn=%administrators,OU=SUDOers,DC=example,DC=com
objectClass: top
objectClass: sudoRole
cn: %administrators
sudoUser: %administrators
sudoHost: ALL
sudoRunAsUser: ALL
sudoRunAsGroup: ALL
sudoCommand: ALL
sudoOrder: 2

and I am able to browse and edit these entries using ADSI Edit on a
Windows box that is joined to the domain.

My sssd.conf is as follows (I have had to improvise as I have not
found any solid documentation on how to do this using the new AD
provider...):

[sssd]

config_file_version = 2
services = nss, pam, sudo
domains = EXAMPLE.COM
debug_level = 6

[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
filter_groups = root

[pam]

[sudo]

[domain/EXAMPLE.COM]
debug_level = 6

# rely on POSIX attributes defined in Active Directory
ldap_id_mapping = false

ldap_schema = ad
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
sudo_provider = ldap
cache_credentials = true

# enable classic behavior of getent passwd
enumerate = true

ad_hostname = host01.example.com
ad_domain = example.com

krb5_server = example.com
krb5_kpasswd = example.com
krb5_realm = EXAMPLE.COM

ldap_referrals = false

ldap_schema = rfc2307bis
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true

ldap_sasl_mech = GSSAPI

ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com

Also nsswitch.conf is updated by default during the sssd install on
Debian jessie:

sudoers:        files sss

I then restart sssd and clear the cache:

service sssd stop; rm -f /var/lib/sss/db/*; service sssd start

and then attempt to use sudo which fails. Here is the relevent part
of the sssd_EXAMPLE.COM.log file:

(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection
successful
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules
with base [OU=SUDOers,DC=example,DC=com]
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=host01)(sudoHost=host01.example.com)(sudoHost=192.168.0.21)(sudoHost=192.168.0.0/24)(sudoHost=fe80::786b:f4ff:fe87:3314)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))][OU=SUDOers,DC=example,DC=com].
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]] [be_run_online_cb]
(0x0080): Going online. Running callbacks.
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[read_pipe_handler] (0x0400): EOF received, client finished
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_tgt_recv] (0x0400): Child responded: 0
[FILE:/var/lib/sss/db/ccache_EXAMPLE.COM], expired on [1386682572]
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_cli_auth_step] (0x0100): expire timeout is 900
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]] [sasl_bind_send]
(0x0100): Executing sasl bind mech: GSSAPI, user: EXAMPLEDOC01$
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[fo_set_port_status] (0x0100): Marking port 389 of server
'dc01.example.com' as 'working'
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[set_server_common_status] (0x0100): Marking server
'dc01.example.com' as 'working'
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[fo_set_port_status] (0x0400): Marking port 389 of duplicate server
'dc01.example.com' as 'working'
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[objectclass=domain][DC=example,DC=com].
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[objectclass=domain][DC=example,DC=com].
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no
errmsg set
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_users_process] (0x0400): Search for users, returned 0
results.
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_groups_next_base] (0x0400): Searching for groups with base
[DC=example,DC=com]
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][DC=example,DC=com].
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no
errmsg set
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with
base [OU=SUDOers,DC=example,DC=com]
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_sudo_refresh_load_done] (0x0400): Received 0 rules
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sysdb_sudo_purge_byfilter] (0x0400): No rules matched
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfuly stored
in cache
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_sudo_full_refresh_done] (0x0400): Successful full refresh of
sudo rules
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at:
1386668172
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_sudo_schedule_refresh] (0x0400): Smart refresh scheduled at:
1386647472
(Mon Dec  9 21:36:12 2013) [sssd[be[EXAMPLE.COM]]]
[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no
errmsg set

It appears that it is not even pulling down the rules at all based on
the Received 0 rules line.

Is my config bad? Is there a 'right' way to get this working using
the AD provider?

Aaron Johnson
You wrote that your distribution is Debian(Jessie), but you didn't write
installed packages and their version.

For your information, sudo-ldap is not built with sssd<->sudo integration,
you should install simple version of sudo. I don't know why debian maintainer
decided to build packages in this way.

Details:
http://anonscm.debian.org/gitweb/?p=collab-maint/sudo.git;a=blob;f=debian/rules;h=87d7432e816bcda5845ea661bba3c7a612e72bc0;hb=HEAD

LS
_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Thank you for the response Lukas-

I was already aware of how sudo is packaged on debian and that the sudo-ldap package is not needed. Here is what I have installed:

root@host01:/var/log/sssd# dpkg -l | grep sudo
ii  libsss-sudo                        1.11.2-1                     amd64        Communicator library for sudo
ii  sudo                               1.8.8-2                      amd64        Provide limited super user privileges to specific users