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
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/ru...
LS
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/ru...
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
On Mon, Dec 09, 2013 at 09:47:48PM -0600, Aaron Johnson wrote:
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...):
Hi Aaron,
I believe your config can be trimmed further. The AD provider already defaults to several directives you've listed explicitly (the config is not wrong as-is, but could be made leaner).
[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 already defaults to this value of ldap_schema. The only ldap (well, non-ad) provider that you need is sudo and that doesn't really care about schema.
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
^^ The values of krb5_server and krb5_passwd are probably a victim of sanitization? If not, they should be the hostname of AD DC you want to be using. Also I think you only need to use the KDC values for GSSAPI-encrypted access to the sudo rules via the sudo LDAP provider, so the krb5_kpasswd is not needed. The server specified in ad_hostname would be used for password changes instead.
ldap_referrals = false
^^ AD provider already defaults to "no referrals". I don't think it's likely to encounter referrals with your custom SUDO tree.
ldap_schema = rfc2307bis
Here you overwrite the ldap_schema from ad to rfc2307bis.
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true
^ These are already the defaults of AD provider.
ldap_sasl_mech = GSSAPI
ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com
On Mon, Dec 09, 2013 at 09:47:48PM -0600, Aaron Johnson wrote:
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...):
Hi Aaron,
I believe your config can be trimmed further. The AD provider already defaults to several directives you've listed explicitly (the config is not wrong as-is, but could be made leaner).
[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 already defaults to this value of ldap_schema. The only ldap (well, non-ad) provider that you need is sudo and that doesn't really care about schema.
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
^^ The values of krb5_server and krb5_passwd are probably a victim of sanitization? If not, they should be the hostname of AD DC you want to be using. Also I think you only need to use the KDC values for GSSAPI-encrypted access to the sudo rules via the sudo LDAP provider, so the krb5_kpasswd is not needed. The server specified in ad_hostname would be used for password changes instead.
ldap_referrals = false
^^ AD provider already defaults to "no referrals". I don't think it's likely to encounter referrals with your custom SUDO tree.
ldap_schema = rfc2307bis
Here you overwrite the ldap_schema from ad to rfc2307bis.
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true
^ These are already the defaults of AD provider.
ldap_sasl_mech = GSSAPI
ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Thank you for the response Jakob-
Here is my config now:
[sssd]
config_file_version = 2 services = nss, pam, sudo domains = EXAMPLE.COM # Set this to troubleshoot; 0-10 are valid values 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
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 = dc01.example.com ad_domain = example.com
krb5_server = dc01.example.com krb5_realm = EXAMPLE.COM
ldap_sasl_mech = GSSAPI
ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com
I don't understand why we need to 'pick' a specific domain controller for the ad_hostname and krb5_server configuration which leaves you with a single point of failure... Why not just use the AD domain name as it will reliably resolve to an AD DC within your AD site?
After the config change sudo rules still do not get pulled down from ldap:
(Tue Dec 10 06:32:59 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]. (Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]] [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base [OU=SUDOers,DC=example,DC=com] (Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]] [sdap_sudo_refresh_load_done] (0x0400): Received 0 rules (Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]] [sysdb_sudo_purge_byfilter] (0x0400): No rules matched (Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]] [sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfuly stored in cache (Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]] [sdap_sudo_full_refresh_done] (0x0400): Successful full refresh of sudo rules (Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1386700379 (Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]] [sdap_sudo_schedule_refresh] (0x0400): Smart refresh scheduled at: 1386679679
On Tue, Dec 10, 2013 at 06:41:23AM -0600, Aaron Johnson wrote:
On Mon, Dec 09, 2013 at 09:47:48PM -0600, Aaron Johnson wrote:
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...):
Hi Aaron,
I believe your config can be trimmed further. The AD provider already defaults to several directives you've listed explicitly (the config is not wrong as-is, but could be made leaner).
[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 already defaults to this value of ldap_schema. The only ldap (well, non-ad) provider that you need is sudo and that doesn't really care about schema.
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
^^ The values of krb5_server and krb5_passwd are probably a victim of sanitization? If not, they should be the hostname of AD DC you want to be using. Also I think you only need to use the KDC values for GSSAPI-encrypted access to the sudo rules via the sudo LDAP provider, so the krb5_kpasswd is not needed. The server specified in ad_hostname would be used for password changes instead.
ldap_referrals = false
^^ AD provider already defaults to "no referrals". I don't think it's likely to encounter referrals with your custom SUDO tree.
ldap_schema = rfc2307bis
Here you overwrite the ldap_schema from ad to rfc2307bis.
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true
^ These are already the defaults of AD provider.
ldap_sasl_mech = GSSAPI
ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Thank you for the response Jakob-
Here is my config now:
[sssd]
config_file_version = 2 services = nss, pam, sudo domains = EXAMPLE.COM # Set this to troubleshoot; 0-10 are valid values 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
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 = dc01.example.com ad_domain = example.com
krb5_server = dc01.example.com krb5_realm = EXAMPLE.COM
ldap_sasl_mech = GSSAPI
ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com
I don't understand why we need to 'pick' a specific domain controller for the ad_hostname and krb5_server configuration which leaves you with a single point of failure... Why not just use the AD domain name as it will reliably resolve to an AD DC within your AD site?
My fault, sorry, I confused ad_hostname and ad_server..
After the config change sudo rules still do not get pulled down from ldap:
(Tue Dec 10 06:32:59 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].
(Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]]
Can you run this ldapsearch manually? Maybe the sudo host is just not matching. I would start with:
ldapsearch -h yourad -Y GSSAPI -b OU=SUDOers,DC=example,DC=com 'objectclass=sudoRole'
and then I'd add more of the filter components..
On 2013-12-10 06:52, Jakub Hrozek wrote:
On Tue, Dec 10, 2013 at
06:41:23AM -0600, Aaron Johnson wrote:
On Mon, Dec 09, 2013 at
09:47:48PM -0600, Aaron Johnson wrote:
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...):
Hi
Aaron, I believe your config can be trimmed further. The AD provider already defaults to several directives you've listed explicitly (the config is not wrong as-is, but could be made leaner).
[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 already defaults to this value
of ldap_schema. The only ldap (well, non-ad) provider that you need is sudo and that doesn't really care about schema. ldap_schema = rfc2307bis Here you overwrite the ldap_schema from ad to rfc2307bis. ldap_access_orde
dy the defaults of AD pr
ckquote
type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">ldap_sasl_mech = GSSAPI ldap_sudo_search_base = OU=SUDOers,DC=
"mailto:sssd-users@lists.fedorahosted.org">sssd-users@lists.fedorahosted.org
dorahosted.org/mailman/listinfo/sssd-users">https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Thank you for the response Jakob- Here is my config now:
[sssd] config_file_version = 2 services = nss, pam, sudo domains = EXAMPLE.COM # Set this to troubleshoot; 0-10 are valid values 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 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 = dc01.example.com ad_domain = example.com krb5_server = dc01.example.com krb5_realm = EXAMPLE.COM ldap_sasl_mech = GSSAPI ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com I don't understand why we need to 'pick' a specific domain controller for the ad_hostname and krb5_server configuration which leaves you with a single point of failure... Why not just use the AD domain name as it will reliably resolve to an AD DC within your AD site?
My fault, sorry, I confused ad_hostname and
ad_server..
After the config change sudo rules still do not get
pulled down from ldap: (Tue Dec 10 06:32:59 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].
(Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]]
Can you run
this ldapsearch manually? Maybe the sudo host is just not
matching. I
would start with:
ldapsearch -h yourad -Y GSSAPI -b
OU=SUDOers,DC=example,DC=com
'objectclass=sudoRole'
and then I'd
add more of the filter components..
_______________________________________________
sssd-users mailing
list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I had ran similar ldapsearch queries before and was confused by the output... When I run the above command I get 1 response (the base OU itself):
root@dc01:~# ldapsearch -h example.com -Y GSSAPI -b OU=SUDOers,DC=example,DC=com 'objectclass=sudoRole' SASL/GSSAPI authentication started SASL username: DC01$@EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <OU=SUDOers,DC=example,DC=com> with scope subtree # filter: objectclass=sudoRole # requesting: ALL #
# search result search: 4 result: 0 Success
# numResponses: 1
Then if I specify * for objectclass I get 5 total results but it doesn't return any attributes for the sudoRole objects I've created...
I'm not sure what would cause this behavior but it doesn't look right to me:
root@dc01:~# ldapsearch -h example.com -Y GSSAPI -b OU=SUDOers,DC=example,DC=com 'objectclass=*' SASL/GSSAPI authentication started SASL username: DC01$@EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <OU=SUDOers,DC=example,DC=com> with scope subtree # filter: objectclass=* # requesting: ALL #
# SUDOers, example.com dn: OU=SUDOers,DC=example,DC=com objectClass: top objectClass: organizationalUnit ou: SUDOers instanceType: 4 whenCreated: 20131210013846.0Z whenChanged: 20131210013846.0Z uSNCreated: 4297 uSNChanged: 4297 name: SUDOers objectGUID:: b0ZyjKhkMEmja1g1SPdgwQ== objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=thejohnso
ns,DC=com distinguishedName: OU=SUDOers,DC=example,DC=com
# root, SUDOers, example.com dn: CN=%root,OU=SUDOers,DC=example,DC=com
# sudo, SUDOers, example.com dn: CN=%sudo,OU=SUDOers,DC=example,DC=com
# defaults, SUDOers, example.com dn: CN=defaults,OU=SUDOers,DC=example,DC=com
# search result search: 4 result: 0 Success
# numResponses: 5 # numEntries: 4
On (10/12/13 20:38), Aaron C Johnson wrote:
On 2013-12-10 06:52, Jakub Hrozek wrote:
On Tue, Dec 10, 2013 at
06:41:23AM -0600, Aaron Johnson wrote:
On Mon, Dec 09, 2013 at
09:47:48PM -0600, Aaron Johnson wrote:
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...):
Hi
Aaron, I believe your config can be trimmed further. The AD provider already defaults to several directives you've listed explicitly (the config is not wrong as-is, but could be made leaner).
[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 already defaults to this value
of ldap_schema. The only ldap (well, non-ad) provider that you need is sudo and that doesn't really care about schema. ldap_schema = rfc2307bis Here you overwrite the ldap_schema from ad to rfc2307bis. ldap_access_orde
dy the defaults of AD pr
ckquote
type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%">ldap_sasl_mech = GSSAPI ldap_sudo_search_base = OU=SUDOers,DC=
"mailto:sssd-users@lists.fedorahosted.org">sssd-users@lists.fedorahosted.org
dorahosted.org/mailman/listinfo/sssd-users">https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Thank you for the response Jakob- Here is my config now:
[sssd] config_file_version = 2 services = nss, pam, sudo domains = EXAMPLE.COM # Set this to troubleshoot; 0-10 are valid values 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 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 = dc01.example.com ad_domain = example.com krb5_server = dc01.example.com krb5_realm = EXAMPLE.COM ldap_sasl_mech = GSSAPI ldap_sudo_search_base = OU=SUDOers,DC=example,DC=com I don't understand why we need to 'pick' a specific domain controller for the ad_hostname and krb5_server configuration which leaves you with a single point of failure... Why not just use the AD domain name as it will reliably resolve to an AD DC within your AD site?
My fault, sorry, I confused ad_hostname and
ad_server..
After the config change sudo rules still do not get
pulled down from ldap: (Tue Dec 10 06:32:59 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].
(Tue Dec 10 06:32:59 2013) [sssd[be[EXAMPLE.COM]]]
Can you run
this ldapsearch manually? Maybe the sudo host is just not
matching. I
would start with:
ldapsearch -h yourad -Y GSSAPI -b
OU=SUDOers,DC=example,DC=com
'objectclass=sudoRole'
and then I'd
add more of the filter components..
sssd-users mailing
list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I had ran similar ldapsearch queries before and was confused by the output... When I run the above command I get 1 response (the base OU itself):
root@dc01:~# ldapsearch -h example.com -Y GSSAPI -b OU=SUDOers,DC=example,DC=com 'objectclass=sudoRole' SASL/GSSAPI authentication started SASL username: DC01$@EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <OU=SUDOers,DC=example,DC=com> with scope subtree # filter: objectclass=sudoRole # requesting: ALL #
# search result search: 4 result: 0 Success
# numResponses: 1
Then if I specify * for objectclass I get 5 total results but it doesn't return any attributes for the sudoRole objects I've created...
I'm not sure what would cause this behavior but it doesn't look right to me:
root@dc01:~# ldapsearch -h example.com -Y GSSAPI -b OU=SUDOers,DC=example,DC=com 'objectclass=*' SASL/GSSAPI authentication started SASL username: DC01$@EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <OU=SUDOers,DC=example,DC=com> with scope subtree # filter: objectclass=* # requesting: ALL #
# SUDOers, example.com dn: OU=SUDOers,DC=example,DC=com objectClass: top objectClass: organizationalUnit ou: SUDOers instanceType: 4 whenCreated: 20131210013846.0Z whenChanged: 20131210013846.0Z uSNCreated: 4297 uSNChanged: 4297 name: SUDOers objectGUID:: b0ZyjKhkMEmja1g1SPdgwQ== objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=thejohnso
ns,DC=com distinguishedName: OU=SUDOers,DC=example,DC=com
# root, SUDOers, example.com dn: CN=%root,OU=SUDOers,DC=example,DC=com
^^^^^^^ missing objectclass=sudoRole missing attribute sudoUser missing attribute sudoHost missing attribute sudoCommand
# sudo, SUDOers, example.com dn: CN=%sudo,OU=SUDOers,DC=example,DC=com
The same situation here
# defaults, SUDOers, example.com dn: CN=defaults,OU=SUDOers,DC=example,DC=com
I would suggest to read more about SUDOers ad LDAP http://www.sudo.ws/sudoers.ldap.man.html
SUDOers LDAP container, Differences between LDAP and non-LDAP sudoers
LS
sssd-users@lists.fedorahosted.org
-
Aaron C Johnson -
Jakub Hrozek -
Lukas Slebodnik