For the sudoRole you can use any name you want - I stick with the computer name since I use per-computer rules. In this case, I create a sudoRole object under the sudoers OU. Let's assume I have a computer named foo32linux, a user called iffin and I want to let him run all commands with sudo on that comp. To create the sudoRole object you have to use ADSI Edit, but once created, you can use Active Directory Users and Computers to modify it. Now create the sudoers OU on your domain root, this OU will hold all the sudo settings for all your Linux workstations. Verify it with ADSI Edit: open the Schema naming context and look for the sudoRole class. Grab the latest release of sudo, get the doc/schema.ActiveDirectory file, then import it (make sure to modify the domain path according to your domain name): ldifde -i -f schema.ActiveDirectory -c 'CN=Schema,CN=Configuration,DC=X' 'CN=Schema,CN=Configuration,DC=ad,DC=foobar,DC=com' -j. Integrating Ubuntu with Active Directory.The exact tutorial is way too long to explain here, but you can find the step-by-step guide and some scripts to help with automation here:

The sudo rules are then stored in AD objects, where you can restrict rules to computers, users and commands, even - all that without ever touching a sudoers file on the workstations. This way SSSD fetches sudo settings and user credentials periodically from AD and maintains a local cache of them. The actual solution is using SSSD and extending the AD schema.

caches both the credentials and the sudo access.

as a bonus, they didn't work for me - at all.

you have to maintain the sudoers file on each and every computer all the time.

they only work when you have access to the corporate LAN (or VPN).

The problem with the other suggestions is that

Add user to sudo