Hi all,
If anyone can assist with this, that would be appreciated. I have a AD-joined OpenSUSE server, running the latest version, and we were able to join it to AD via the windows domain membership module (user logon management doesn’t seem to exist contrary to what documentation would have one reading it believe, though that might have been just us, for it’s been at least six years since I’ve touched OpenSUSE). and when logging in, you can login, but that’s it. The groups don’t show up under the user and group management module of YaST. Basically, any AD user that can login, can’t do anything once they get inside, even if they have permissions in AD itself. Not sure what we’re missing (we were able to get root access using the normal (non YaST method of editing the config files directly, but we would rather be able to employ the simplicity that YaST provides, if possible.) So, two questions. How does one add a user to groups properly so that only the needed members have root access, and we don’t have to edit the config files manually to get root, and two, why aren’t we able to do anything under the user and group management module with any of the AD groups that already exist? To make things even more detailed, the Active Directory environment is running Windows Server 2016.
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.
It is not so much a user with username “root”, but the user with UID “0”.
And I assume it is better to have that only defines in your /etc/passwd. To more bells and whistles connected to it, the more problems you will have when your system breaks down and you have to login as root from e.g. runlevel 1 to repair it.
I definitely know what the root user is. I think I misspoke, perhaps (posting this on behalf of another administrator in my group who wants to use his AD account with root privileges.) If it’s better just to Sudo everything, then I’ll let him know (I found the SUSE documentation on that and sent it to him). Basically, wants to know how being an admin in AD on some of our Windows machines will translate simply into the Linux machines he wants to manage. The question is two-fold, as well, for the other issue we ran into is pertaining to the user and group management module; upon going in there, after the machine was AD joined via the Windows Domain Membership module, none of the groups show up for management in users and groups.
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.
If it helps, this server is in text mode only, and has no graphical components. Not sure if that changes anything. I definitely understand what you’re saying here … Both myself and him are relatively new to OpenSUSE (he’s used to CentOS and that kind of AD join), and I’m just starting, so, both of us are trying to figure out the best way to administer a SUSE-based server. YaST is quite nice, but I think we’re too new to it in order to properly judge it. I think what might help here is some extra information on how SUSE handles AD joins; how groups translate and what not … so, how to specify say, members of the domain admins group to be administrators of the particular SUSE server (seems more manual than Windows does it where all members of that group have a blanket set of permissions), and so on. I looked through chapter 7 of the security guide, and it’s not clear how groups translate. Because if we can do this without root, then, better for us and for everyone involved. Is there an automated YaST-based way of managing this?
In addition, this still doesn’t answer the question as to why none of the AD groups are showing up in the user and group management module (if the two of them have anything to do with one another at all). I’m assuming it’s because of how management of AD groups are handled? I hope this clarifies things a bit. I wish I had more experience with CentOS so that I can explain how things are set up there in our environment. I will get some more information for comparison if needed, though.
I do not use Active Directory, so do not await much from me. About Windows I do know almost nothing, thus compairing something with how it is done there does not work with me.
I assume your last paragraph shops the real question you now have. But the thread title does not cover this. To draw the attention of those who know how those AD users and groups are to be handled, it maybe better to start a new thread where the title tells this in a few keywords.
About YaST, it is certainly a major incentive that comes with openSUSE. It does have a ncurses interface, thus there is no need for a GUI to work with it. YaST certainly covers most of the important system management tasks you will encounter. But a fall back to good old basic commands might be needed. After all, when a system management tool would cover all possibilities of all areas it would most probable grow out of proportions and it’s screens would become ununderstandably cluttered for most of the audience.
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).
Thanks … I think I will start another one; the lack of being able to see those groups is bothering me. LOL. But at least I think we know what to do, now.
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.
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
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.
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.
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.
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.
