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(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?
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..