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(a)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