I want to know how to set up Sudoers in Active Directory? I know that you can have it with full root or only which certain commands. Is there a great link that shows how to do it in detail or can anyone show me?
On 2015-01-16 15:26, dtimmel wrote:
>
> I want to know how to set up Sudoers in Active Directory?
Sorry, I miss the relation of sudo to AD.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
I haven’t heard this request before.
In principle, it’s something you shouldn’t do, it’s similar to granting your AD Users Group local Admin permissions which is of course clearly a violation of fundamental Windows rights policy in general.
But, as I’ve described if you understand how Windows AD security works it would also be clear how to do so.
TSU
On Fri, 16 Jan 2015 14:26:02 +0000, dtimmel wrote:
> I want to know how to set up Sudoers in Active Directory? I know that
> you can have it with full root or only which certain commands. Is there
> a great link that shows how to do it in detail or can anyone show me?
I’m guessing you mean that you want to integrate authentication with an
AD environment and enable an AD-defined group to perform certain
operations via sudo?
That is possible - you’ll want to read up on PAM, and how to configure
sudo to work with PAM.
You might be able to do the integration with AD specifically, but if it
were me, I’d be more inclined to probably look at using LDAP rather than
anything AD-specific.
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
If you’ve joined the Linux box to the AD you can define in /etc/sudors something like this;
%domain\ admins ALL=(ALL) ALL
Note, this would alllow any user in the “Domain Admins” group to execute ANY command with their own password if you also remove the targetpw parameter from sudoers (so it’ll function like Debian or Redhat).
\ is required so it’ll understand there’s a space in the group. If you have multiple places, like; Awesome\ Users\ Group, you’ll need to remember it.
sudoers schema for Active Directory is installed as /usr/share/doc/packages/sudo/schema.ActiveDirectory; you can use any standard AD tool to import it (do not forget to edit it for your domain). More information is in “man sudoers.ldap”. Some hints are in http://www.sudo.ws/sudo/readme_ldap.html
It’s been awhile since I’ve looked at issues related to Windows AD on Linux (specifically openSUSE) but I can’t remember having to configure these kinds of things… which may again be related to just not wanting to bend/break fundamental AD concepts.
When an openSUSE box is joined to an AD, I don’t remember there should be any need to modify User permissions.
When you logon to an openSUSE box, you would of course do so with a Windows AD User and not a local machine account (this would be the same whether you’re talking about an openSUSE host or a Windows host).
If logged in with a Windows Domain Admin account, IIRC the last time I did so, you should have root access (or did I add that Windows Domain Admin account to the requisite Linux User Groups manually, I can’t remember).
In any case, I don’t remember configuring anything special like modifying sudo, probably because if the User account already has the required permissions, there would not be a need.
As I described, IMO modifying to elevate a normal User Account is an almost uniquely Linux concept and although nowadays can be done in home Windows has never been acceptable in a proper Enterprise AD policy.
TSU
It reminds me old story about blind men and elephant … 
The OP question could mean any of
a) how to authenticate Linux user via AD
b) how to store Linux sudoers content in AD
c) how to use sudo on Windows for Windows users
We have seen stab at answers to each of three variants. Personally I vote for b) but let’s wait for OP to clarify
“runas” was available since at least Windows Server 2000.
IIRC “runas” preceded AD, was often used managing NT4/Win9x.
But, like many old practices “runas” has since been strongly discouraged, primarily because “runas” requires storing and sending credentials in clear text. In 1994 this might not have been that big an issue, today it is.
There are plenty of things in both life and computing where things are possible but doesn’t mean that’s the way things should be done.
Expounding a little more on this idea of using “sudo”
IMO it’s a primary way of granting elevated (or more precisely alternative) permissions while still preserving accountability. An example of this is that you would never want to give multiple people (particularly non-admins) the root account credentials because then anyone who knows those credentials could do anything and later there is no way to know which person did what because to the computer everyone’s actions would be “root.” Sudo only temporarily grants root permissions while preserving the identity of the User.
In Windows AD, User Groups work differently but used properly should also preserve the true identity of a User so that actions are accountable. Instead of temporarily elevating permissions, each User is configured with a specific set of permissions across the organization. Properly implemented, there is no temporary elevation of permissions, if you need something done which you are not able to perform, you’re supposed to ask someone with authorized permissions to perform that task.
In fact, although the exact details of the Sony compromise is quite murky (and who knows, maybe even they might not know exactly what happened), if they were running some kind of network security like AD, this whole concept of how to implement security and what kinds of compromises become common practice in the company could easily have contributed to what happened. Whatever technologies in your company are implemented (eg AD, LDAP, Linux and Windows OS, apps), the people running IT should be as highly educated as possible to make the right decisions because it’s <very easy> to make poor decisions.
TSU