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.
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..
_______________________________________________
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