On Thu, Feb 27, 2014 at 01:59:57PM +0100, Pavel Březina wrote:
On 02/26/2014 01:54 PM, Sumit Bose wrote:
>Hi,
>
>this patch provides the AD sudo provider and is "inspired" by Lukas'
>"SUDO: IPA provider" patch.
>
>I do not have an AD setup with sudo rules. It would be nice if someone
>with such setup can run some basic test otherwise I can/have to do some
>additional testing.
>
>Patches for master and 1.11 are attached.
>
>bye,
>Sumit
Hi,
<nitpick>
- 'ad': ['id', 'auth', 'access',
'chpass'],
+ 'ad': ['id', 'auth', 'access',
'chpass', 'sudo', 'subdomains'],
subdomains should be added in separate patch
</nitpick>
code-wise ack. I will try to update ad schema and test it.
The patch works fine! ACK from my side, I'll leave it up to you whether
you'd like to split the patch into two or not.
For future reference, if you want to amend the schema, you need to copy
the AD schema file (/usr/share/doc/sudo/schema.ActiveDirectory) from sudo
Then load it on AD:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=DOMAINNAME,dc=LOCAL
Then just add the records. I admit I was lazy and just added the
sudoRole objects to the same subtree as users but that doesn't matter as
SSSD uses the top level base anyway:
(Thu Feb 27 17:03:12 2014) [sssd[be[WIN.EXAMPLE.COM]]]
[common_parse_search_base] (0x0100): Search base added:
[SUDO][DC=WIN,DC=EXAMPLE,DC=COM][SUBTREE][]
To add the records, I used "ADSI Edit". Just right-click the container,
select "New->Object" and then you should see sudoRole in the list of
objectClasses. The name of the user must be non-qualified, so from the
following rule:
dn: CN=lessrule,CN=Users,DC=WIN,DC=EXAMPLE,DC=COM
objectClass: top
objectClass: sudoRole
cn: lessrule
distinguishedName: CN=lessrule,CN=Users,DC=WIN,DC=EXAMPLE,DC=COM
instanceType: 4
whenCreated: 20140226161739.0Z
whenChanged: 20140226163320.0Z
uSNCreated: 274759
uSNChanged: 274760
name: lessrule
objectGUID:: Q44OphStKUaZOkDR9eBs7A==
objectCategory: CN=sudoRole,CN=Schema,CN=Configuration,DC=WIN,DC=EXAMPLE,DC=COM
dSCorePropagationData: 16010101000000.0Z
sudoHost: ALL
sudoCommand: /usr/bin/less
sudoUser: tuser(a)win.example.com
sudoUser: Administrator
Only Administrator worked. So I suspect that in order to support users
from trusted domains, you'd have to make them a member of a group and then
allow the rule for the group. But this is mostly academic as this
problem is present also with sudo using the 'built-in' LDAP support and
not SSSD.