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.fedorah...
>>
>>>
> 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(a)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$(a)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$(a)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