Unable to Add Active Directory User as root after logon

[hcvv]

If you want to have "Windows Admins" with superuser permissions on your Linux system, you could allow domain users to execute sudo commands without password - this will require some changes to /etc/sudoers.

Mainly, you'll want to remove targetpw by commenting it out so it won't ask for root password and enable domain admins to execute any command with root permissions, for example if you add to sudoers (after commenting targetpw):

# Domain Admins
%domain\ admins ALL=(ALL) ALL

This would allow any user in the Windows AD group Domain Admins to execute commands with sudo without a password (of course it requires for them to login to the system first with their AD password).

To me this sounds like publishing the root password on a billboard above the entrance of your company

[Miuku]

To me this sounds like publishing the root password on a billboard above the entrance of your company

It still requires you to have Domain Admin permissions on Active Directory which means your entire corporate network security has been compromised already :-)

That being said, to the Op: you can check what groups your logged in user is part of in AD with;

wbinfo -g

and you can manipulate things in AD with

net

command from the terminal. For example;

net ads group

lists all groups etc.

This is all with the assumption that you are running with Winbind, if you use SSSD it's a bit different.

[Cambridgeport90]

Upon further discussion with my associate, ,I have discovered that the actual issue lies with listing groups in sudoers. Regardless of how the list in the file is formatted, it doesn't recognize that there are any groups in there; we've tried with caps,without,camelCase, and still nothing works. We're trying to add a group to sudoers called Som-MASiteAdmin. not sure what we're doing here to make things not work

[tsu2]

I never use sudo (I assume you mean that). But I am aware of the "sudo desease". It is well spread. I normally use (in KDE) the Terminal - Super User Mode, which uses

su -

Then I can do as root what I have to do and exit afterwards.

I'd caution that IMO this is one of those cases where "su -" is not desired... You'd probably want "su" which doesn't relogin as the new user (root in this case).

when an Administrator logs in remotely to a machine to do administrative work, usually the only need is to have elevated permissions and couldn't care less about a root home directory or any other user-specific environment variables. And, you really don't want to be re-located to a different location in the file directory, you want to be exactly where you are, and more often than not in the file tree of a specific User on the system.

TSU

[tsu2]

So, the root user can't be one from one of the AD groups? Also, we have discovered that sudo -i doesn't work when logged in under this AD user, either.

As I tried to emphasize in the other related Forum thread,
Windows User security is a different design than *NIX.
There are some similarities (like root and the MSWindows 500 account) but there are also differences... Any of the various Administrator accounts you find in Windows won't be found in 8NIX.

I'd also caution that sudo may not do what you want...
Sudo doesn't truly "change user" to have full capabilities of the new user (su and su - does this), sudo merely allows a user to impersonate another account temporarily. The difference here is that impersonation means that you are still your original account but gains some new capabilities for a period of time. Some functions will notice this difference and refuse to allow any impersonated account to do some things.

A common example that comes to mind is if you try to administer a RDBMS app like PostgreSQL or MySQL... If you sudo, you'll probably be rejected. You'll need to "su" to manage those database apps.

My suggestions...
Primary is to identify, define and declare your objectives.
Active Directory integration with Linux means many things to different people because AD is LDAP extended in so many ways to support a full spectrum of network management far beyond what LDAP by itself does, and is why Active Directory is so popular... The ability to manage your entire network with zero touch.

But, all that functionality to support Windows networks is not always what Admins want or need on Linux boxes... They're often perfectly happy if Users on their Linux boxes can logon with their Domain User Account and access network resources, primarily Windows Network Shares... and that's it. YaST supports this out of the box.

But,
You might be interested in more.
If you're a decent sized Windows shop, you're likely using your Active Directory to maintain your Windows hosts... provisioning machines, ensuring and tracking and maybe even withholding updates. You may be installing apps remotely on machines, debugging problems, tracking resource usage and more.

And, maybe you're interested in doing the same on your Linux hosts.
You should know that this level of granular management of managing Linux hosts using Active Directory isn't usually possible with a single all-encompassing solution but there are Enterprise solutions and some apps that will do some of these things.

Centrify is a commercial solution that extends AD to support doing quite a bit of Linux hosts management. There were some public source projects a few years ago but don't know what may have happened to them, it's not something I kept up on. There is also solution called "Jump Cloud" that integrates heterogenous OS devices into a common directory services.

Puppet and Chef are popular Enterprise device provisioning apps that are cross platform provisioning solutions. Saltstack is another popular solution in this space. To a certain degree they can support some health metrics but probably shouldn't be considered maintenance and monitoring apps.

Since you say you are deployed on virtualization, you can investigate what is available for that technology. In general, AFAIK Hyper-V has cut back practically to nothing assuming that 3rd party apps might pick up the slack, which is a different direction other apps like VMware went. Virtualization usually provides some API or method(s) to have direct access to what is running in a virtual machine.

HTH,
TSU

[hcvv]

I'd caution that IMO this is one of those cases where "su -" is not desired... You'd probably want "su" which doesn't relogin as the new user (root in this case).

when an Administrator logs in remotely to a machine to do administrative work, usually the only need is to have elevated permissions and couldn't care less about a root home directory or any other user-specific environment variables. And, you really don't want to be re-located to a different location in the file directory, you want to be exactly where you are, and more often than not in the file tree of a specific User on the system.

TSU

I think you know I differ here from your opinion very much. Already for ages (from before even Linux existed) it is seen as a great security risk to run processes as root (that is what you call "elevated permissions" if I understand that expression correct) with the process environment of any other user. Alone the fact that a PATH can lead to executing a different program then was intended is hairraising enough.

[arvidjaar]

Already for ages (from before even Linux existed) it is seen as a great security risk to run processes as root (that is what you call "elevated permissions" if I understand that expression correct) with the process environment of any other user.

So giving user carte blanche to do anything as root without any trace or audit log is better than restricting user to perform well defined actions where every such action is logged? We have very different definition of "security" indeed.

Alone the fact that a PATH can lead to executing a different program then was intended is hairraising enough.

If you configure sudo to depend on path it is your fault, not sudo.

[hcvv]

So giving user carte blanche to do anything as root without any trace or audit log is better than restricting user to perform well defined actions where every such action is logged? We have very different definition of "security" indeed.


If you configure sudo to depend on path it is your fault, not sudo.

Sorry, I did NOT discuss sudo with @tsu2, I discussed su vs. su -.