Hi all,
We have recently set up a new OpenSUSE server running in text only mode. I’m brand new to managing Linux servers, especially those joined to Active Directory. I have a couple of questions that are hopefully all related. The first is: How do AD group permissions translate to people logging into Linux servers? Such that groups are created, so then how do we associate the permissions with the groups? Our standard Linux server is running CentOS, which uses the system commands common to all Linuxes. We’re wondering how to do this with YaST; last night, for instance, after adding himself to one of the AD groups, not sure which one it was, another administrator was able to bring up the user and group management module in YaST, but nothing whatsoever showed up. Is that by design? are we supposed to manage groups from Windows, in this case? We would be interested to find out. Thanks a lot, everyone.
Permissions for what? If you mean file ACL - Linux file systems do not have NT ACL so question is meaningless.
how do we associate the permissions with the groups?
Again - permission for what? You need to explain what you are trying to achieve.
are we supposed to manage groups from Windows, in this case?
Yes.
I think part of this could be that SUSE is new to us, so we’re not used to the way it works. Most of the members of my group are used to one flavour of Linux, and one flavour only.
this question is more towards Linux in general; in other words, is creating a group and adding all the users to the group enough to grant them permissions on the system… When the domain admins group was added to this server at first, the members weren’t able to do anything, and my associate’s question is whether or not this is manageable via YaST or whether normal system commands have to be used in addition to Windows via the attributes for Unix from the Windows consoles. It sounds like the latter, and that the users and groups module in YaST is more for local groups, or groups managed via 389 Directory server or something similar?
Hi,
Your questions about Linux and Active Directory integration should be asked more often, at least far more often than I see questions asked.
It’s a pretty big area, let me start by pointing you to the current openSUSE documentation on Active Directory support and integration
https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-security-ad.html
From the above link, if you’re setting up Member Servers and adding Domain Controllers to an existing AD, you can backup up pages to the LDAP page and start from there.
If you’re joining client hosts to the Domain, you can start on this page.
I see that the content seems to have been lifted from some Gnome Desktop source and those references haven’t been removed. I recommend you ignore references to Gnome, Nautilus, GDM, etc unless you are running a Gnome Desktop.
So, let me describe some other things where you shouldn’t take the openSUSE documentation at its word or clarify some points…
Linux today supports two ways of Active Directory integration or emulation,
- SAMBA4 which is more often used to set up Servers in small networks
- LDAP which is seen more often both as clients and servers in more “Enterprise” networks. Keep in mind that both LDAP and Active Directory are built on the same LDAP Directory Services, the only thing that really differentiates Active Directory is its structure and objects.
If you have any NAS devices in your network, there is a good chance that the device will have SAMBA3 and not SAMBA4 and even if installed with SAMBA4 might not support more features than exposed through webpage tools. NAS devices often are designed to be deployed with or without joining a Domain and overlay an independent layer supporting Windows style credentials. This often means that without Directory Services integration, you may have to duplicate User accounts on your NAS when Users don’t have automatic access to Windows network shares… This is different from a Domain Member server when User accounts are stored locally and instead a query is sent to a DC asking for authentication and authorization.
AFAIK the section about winbindd is outdated. It describes an old way to setup which is still supported but is no longer recommended (If anyone knows I’m wrong about this, am open to correction). This winbindd setup’s main value is supporting the predecessor to Active Directory, NT4 Domain services.
Generally speaking,
Most Network Admins are mainly interested in just having Users logon to their Linux machines and then enjoy single sign-on access to network resources like Windows Network Shares. The openSUSE documentation seems to provide this information, in particular you should use the “Join Windows Domain” YaST module only if you’re joining a Workgroup or SAMBA based NT4 Domain utilizing services that utilize NetBIOS based services. If you are joining a modern Active Directory which may or may not involve any kind of mixture of Windows and Linux Domain Controllers, then you should <not> use the YaST “Join Windows Domain” module, instead you should use the YaST “LDAP and Kerberos Client” module.
Once your Domain User has logged in to your Linux box, the User experience accessing Domain resources including Windows Network Shares should be identical to logging in on a Windows box… Windows Network Share access is managed on the Server, not the client.
Regarding your question about viewing Domain Users on an openSUSE client…
Yes, your Admin won’t see any Domain Users, and that would be the case if your Linux box is a fully integrated member of the Domain… If you know AD/LDAP architecture, you’ll know that Domain hashes/credentials aren’t stored locally in the client machine, every Domain authentication/authorization including logons and access to resources always involves querying a DC. And, the YaST Users and Groups module is able to look only at local system accounts.
Now,
As for provisioning an Active Directory Member Server or setting up even an AD client machine to serve network resources…
If you set up a Windows Networking Share, aka CIFS, SMB…
I haven’t found setting up any different than on a Windows machine. You have your lower level file permissions and you have your higher level Network Share permissions. Each layer is distinctly different and through a combination of both sets of permissions manages what the remote User can or can’t see or do with the shared files.
Access to other resources is YMMV and depends on the resource.
If you run into an issue that’s unclear, just post your specific question with details.
Regarding your question about managing your Active Directory,
Yes, using Windows Active Directory Tools is by far the easiest way to manage your AD, just point it to a DC (or PDC as your situation may require) which can be a Windows or Linux box, it just has to be configured with the DC role.
I don’t know that a comparable tool exists in the Linux world yet.
HTH,
TSU
Ok,
Now you’re asking a question that highlights the difference between Windows and Linux security.
Linux like other *NIX systems is fundamentally not built around User permission, is instead built on file system security.
Windows was designed after *NIX and decided to be built around User security instead.
This is why we have only a single root and not “sub-root” User accounts on *NIX systems although systems have often used the wheel group to grant root access to multiple non-root accounts. In a nutshell, I personally feel the wheel group can be used safely only with non-interactive accounts (eg services that perform only limited functions), adding regular User accounts to the wheel group is akin to logging in with the root account if you add normal User accounts that humans normally use.
So,
Yes you’ve run into a particular characteristic of Linux… There is only the “god” root account and there is nothing like a demi-god. And without root permissions on a system you cannot perform Administrative functions. You can temporarily elevate a User’s permission with sudo but the security model of a Linux system doesn’t support an always-on set of permissions that can perform only some root required functions but not others.
And, you can’t get around required local permissions… This is the same whether on a Windows or Linux box. For example… Inspect your Windows hosts joined to a Domain. You will find the Domain Administrators group a member of the local Administrators group, that’s what enables Domain Admin Users to perform management functions on Windows boxes. But, we don’t have a “root group” on Linux except for the “wheel group” I’ve described so you can’t do the same thing on Linux that happens on Windows (unless you go ahead and assume the risks of using the wheel group).
TSU
thanks for these clarifications … like I said, the standard on this particular network is CentOS, so SUSE at this point is an unknown quantity until proven otherwise. But it looks like we have some things to watch for. And thanks for letting me know about the winbind module. I never would have guess that it isn’t used as much via the documentation. Now I just need to remind myself of how to get the Unix attributes to show up in Windows. So it looks like we’re on the right track, it’s just the tooling is not as familiar to the rest of my group.
after playing with it a little bit more, we are trying to disjoin and rejoin the server to the modern Windows domain via the LDAP Kerberos module. At first we were getting an error stating “disable SSSD from user and group management”, and after doing so, though we used the etc/sssd/sssd.conf and disabled it manually instead, now no one can login; SSH just doesn’t do anything. What did we do wrong? I ask because we want to disable winbind, not SSSD,so why was it asking us to disable SSSD? I would give you more details if I had them, though the errors are very vague.
I described some basics for different things to be aware of when setting up integration with Active Directory,
But you should really start with whatever you already have set up, understand it and only then determine your options for adding new resources to your Active Directory network.
So,
For instance what did you have set up before anything else?
Did you start off with an Active Directory set up with a schema created by a MSWindows DC? And if so, what version of Windows Server?
You also mention having already added a CentOS server, how was that set up, as a 389 Directory Server? Has it been running well with your Windows Servers?
Do you have any other Active Directory DCs configured?
Then,
If you want to add an openSUSE, what role will it assume and what services will it provide or is it simply a client host and not a server?
All of the above needs to be clarified… What you have and then what you want to add.
Can’t offer an opinion when so much of the picture is unclear.
TSU
To clarify things a bit more:
We have an existing Active Directory setup, schema has a couple of Extensions for Dell OpenManage, and eventually System Center (though that’s just for clarification. not sure if the extensions matter). The network is set up with Windows Server 2019 domain controllers, and then a couple of other things run Windows; backup server runs Windows, our hypervisors run Hyper-V, and a couple of others. We also have some Windows SMB file shares, though those are mostly Windows clients who access them, rarely do we have servers touching them. The rest of them are Linux, all running CentOS because that is the standard distribution chosen for the enterprise. (I didn’t make that decision.)
OpenSUSE is coming into this pre-existing environment to run GnuHealth Server components (and possibly, if this experiment goes well, a fediverse software such as Mastodon or Pleroma on a different install), and we are attempting to join that server to the domain, as well, and here’s where I goof up originally prior to your post about the different modules. I had my associate use the Winbind module instead of the LDAP and Kerberos module, since before you mentioned that it existed, I was not aware at all. Now we are trying to backtrack, removing the server from the domain using the Windows membership module, and re-joining it using LDAP and Kerberos since we seem to be running into issues getting the sudoers file to recognize groups when using Winbind. At this point we’re stuck with the error to disable SSSD from user and group management, though we’ve been having to disable it manually by commenting it out, and now we are no longer able to get the server to join again. My associate now can’t even login.
Just in case the following reference is helpful…
How you added your CentOS to the AD may be important so you can maintain consistency in your network… IMO that should be a main consideration, to minimize complexity. You don’t want every machine in your network connecting to others in a different way. So, my recommendation is to understand your CentOS, are they 389 Directory Servers or something else? I’d recommend however your CentOS are set up should take precedence in how you set up openSUSE and if you need help in that, there are some Forum threads (IIRC in the Networking Forum) on 389 setups.
The YaST modules are there to assist and ease setups, but they are best used when you have no other considerations in your network and you’re setting up for the first time. Because you already have CentOS set up, YaST may be helpful but you first need to know what you already have set up.
If you’re having problems undoing your joining AD and your system is installed on BTRFS, there’s a good chance that you can roll back to a status prior to that event by running Snapper, list your history of snapshots and then choose a snapshot prior to the date and time you made any mistakes. This is a relatively risk free thing to do… Although unexpected things can happen so make sure you have backups, BTRFS snapshots have been very reliable and virtually problem free. And, rolling backwards and forwards can be done to undo even your “undo’s” You always move forward historically, and can “roll forward” to undo rolling backwareds or choose another snapshot to roll forward or back.
You can even rol back to before you even installed the packages you installed to connect to AD, and start from acratch.
TSU