4 ms·

I'm not real familiar with this stuff but I could've sworn that linux has been able to join Active Directory domains via samba for a long time.

ocdtrekkie 6y ago
I know you can, in a very basic sense, such that one can log in, after both setting up the OS, and then configuring the domain join after installing additional components. But there's two key things here: > Ubuntu machines can join an Active Directory (AD) domain at installation for central configuration. This means it's now a ready-to-go functionality of the OS, and can be done simply without going to read a blog article on how to do it, post-setup. > Ubuntu 21.04 adds the ability to configure system settings from an AD domain controller. Using a Group Policy Client, system administrators can specify security policies on all connected clients And this means one can deploy Ubuntu machines on an Active Directory network at scale. Rather than hand-crafting one Ubuntu server that connects to your AD, ability to set policies with GPOs is the baseline to be able to say, deploy Ubuntu desktops to an entire department. Group Policy is the "pets vs cattle" difference in a Windows-based network.
- vetinari 6y ago
  > This means it's now a ready-to-go functionality of the OS, Fedora did this few releases ago, as a part of the new-at-the time OOB wizard (you could use AD or FreeIPA, autodetected). Good to see that Ubuntu does similarly. > can be done simply without going to read a blog article on how to do it, post-setup. I never had a problem with setting up AD membership after-the-fact, except for three things that bothered me: 1) you still needed a local (root or sudoer) account in Ubuntu (but not in Fedora), 2) the setup didn't set up domain admins (or other group) neither as sudoers, nor as PolicyKit admins (these GUI prompts for admin password that you get from Gnome Software or Disks, or other privileged apps). These had to be done manually, 3) Files doesn't use AD Kerberos ticket when accessing file shares. It will just asks the user again; kind of defeats the point of Kerberos. I'm really interested whether these are fixed.
- Spivak 6y ago
  > I know you can, in a very basic sense, such that one can log in. Log in, get group and netgroup membership, apply GPO based access control, access ssh keys, apply sudo rules. > after both setting up the OS, and then configuring the domain join realmd join ad.example.com Just the same as joining the domain on a Windows machine. Add-Computer -Domain ad.example.com > Rather than hand-crafting one Ubuntu server that connects to your AD... And this means one can deploy Ubuntu machines on an Active Directory network at scale Huh?!? Are you manually joining every machine to the domain and manually configuring every machine by hand? Even if you don't want to bother with config management like Chef/Puppet/Ansible for post-install config you at very least could have leveraged preseed files to automate the install, domain join, and applying your configs. Like it's great that Ubuntu is supporting a subset of GPO but just like in the Windows world you can't configure everything with it and still need SCCM and Linux has solutions abound for that functionality.
  - xorcist 6y ago
    > preseed files to automate the install, domain join, Genuine question, wouldn't that require a kerberos ticket to work? Or at least some high privilege password that you might not want to keep around your preseed files? Bootstrapping trust is a tricky problem. Most that I've seen tend to go with some custom solution.
    - Spivak 6y ago
      Yes, but you can really tighten that privilege in practice. Yes having the ability to create computers in AD is potentially dangerous but in our deployments all the "AD Join Account" can do is create, delete, and reset computer passwords in one specific OU that new computers are moved out of once provisioned. We don't broadcast the join password and rotate it every so often but we also don't really care if it gets out.
      - x86_64Ubuntu 6y ago
        Hmm, I ran into the same issue too whereby I had a manual step to join the computer to the domain. I only had one computer to join, so I couldn't use anything like a real secrets solution, but I also didn't want the password to be in the Ansible files. Having an OU that computers are provisioned in, and then moved out of later on would have help me a lot.
- lordlimecat 6y ago
  For a very long time the process on Linux has basically been making sure SSSD / SSSD-AD / realmd were installed, and then running, realm join mydomain.fqdn Some distros defaulted to SMB (though which, I dont know), and occasionally the default configs of sssd.conf are not sufficient for your organization (such as if you want to use SSH keys via ldap, sudoers, dynamic dns, etc). But generally you were seeing a bunch of guides because they were referring to truly ancient distros.

ocdtrekkie 6y ago

I know you can, in a very basic sense, such that one can log in, after both setting up the OS, and then configuring the domain join after installing additional components. But there's two key things here: > Ubuntu machines can join an Active Directory (AD) domain at installation for central configuration. This means it's now a ready-to-go functionality of the OS, and can be done simply without going to read a blog article on how to do it, post-setup. > Ubuntu 21.04 adds the ability to configure system settings from an AD domain controller. Using a Group Policy Client, system administrators can specify security policies on all connected clients And this means one can deploy Ubuntu machines on an Active Directory network at scale. Rather than hand-crafting one Ubuntu server that connects to your AD, ability to set policies with GPOs is the baseline to be able to say, deploy Ubuntu desktops to an entire department. Group Policy is the "pets vs cattle" difference in a Windows-based network.

vetinari 6y ago
> This means it's now a ready-to-go functionality of the OS, Fedora did this few releases ago, as a part of the new-at-the time OOB wizard (you could use AD or FreeIPA, autodetected). Good to see that Ubuntu does similarly. > can be done simply without going to read a blog article on how to do it, post-setup. I never had a problem with setting up AD membership after-the-fact, except for three things that bothered me: 1) you still needed a local (root or sudoer) account in Ubuntu (but not in Fedora), 2) the setup didn't set up domain admins (or other group) neither as sudoers, nor as PolicyKit admins (these GUI prompts for admin password that you get from Gnome Software or Disks, or other privileged apps). These had to be done manually, 3) Files doesn't use AD Kerberos ticket when accessing file shares. It will just asks the user again; kind of defeats the point of Kerberos. I'm really interested whether these are fixed.
Spivak 6y ago
> I know you can, in a very basic sense, such that one can log in. Log in, get group and netgroup membership, apply GPO based access control, access ssh keys, apply sudo rules. > after both setting up the OS, and then configuring the domain join realmd join ad.example.com Just the same as joining the domain on a Windows machine. Add-Computer -Domain ad.example.com > Rather than hand-crafting one Ubuntu server that connects to your AD... And this means one can deploy Ubuntu machines on an Active Directory network at scale Huh?!? Are you manually joining every machine to the domain and manually configuring every machine by hand? Even if you don't want to bother with config management like Chef/Puppet/Ansible for post-install config you at very least could have leveraged preseed files to automate the install, domain join, and applying your configs. Like it's great that Ubuntu is supporting a subset of GPO but just like in the Windows world you can't configure everything with it and still need SCCM and Linux has solutions abound for that functionality.
- xorcist 6y ago
  > preseed files to automate the install, domain join, Genuine question, wouldn't that require a kerberos ticket to work? Or at least some high privilege password that you might not want to keep around your preseed files? Bootstrapping trust is a tricky problem. Most that I've seen tend to go with some custom solution.
  - Spivak 6y ago
    Yes, but you can really tighten that privilege in practice. Yes having the ability to create computers in AD is potentially dangerous but in our deployments all the "AD Join Account" can do is create, delete, and reset computer passwords in one specific OU that new computers are moved out of once provisioned. We don't broadcast the join password and rotate it every so often but we also don't really care if it gets out.
    - x86_64Ubuntu 6y ago
      Hmm, I ran into the same issue too whereby I had a manual step to join the computer to the domain. I only had one computer to join, so I couldn't use anything like a real secrets solution, but I also didn't want the password to be in the Ansible files. Having an OU that computers are provisioned in, and then moved out of later on would have help me a lot.
lordlimecat 6y ago
For a very long time the process on Linux has basically been making sure SSSD / SSSD-AD / realmd were installed, and then running, realm join mydomain.fqdn Some distros defaulted to SMB (though which, I dont know), and occasionally the default configs of sssd.conf are not sufficient for your organization (such as if you want to use SSH keys via ldap, sudoers, dynamic dns, etc). But generally you were seeing a bunch of guides because they were referring to truly ancient distros.