Hacker News Reader

Comment by ocdtrekkie | Hacker News Reader

Holy crud, I can just straight up join this to my domain? This is world-changing.

There is a GPO template. I think I'm in love.

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.

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.

> 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.

> 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

    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.

> 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.

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.

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.

with azure ad (even hybrid) you can let your oem make a oem autopilot domain join, thus it will be registered even bevore you have the device.

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.

You always could! sssd’s ad integration has been really solid for years and if you have a huge number of machines you can stand up FreeIPA establish a trust between them.

The thing that’s changing with this release is the ability to support some GPOs with adsys. sssd has/had some basic gpo support as it relates to auth but not really for system config.

FWIW, GPO templates are what I consider the minimum to call something manageable, which is most of why I want things on Active Directory.

This definitely moves this into "I might introduce this to our environment" level.

The problem is that GPOs are really a terrible way to do configuration, and people (like myself) who grew up on them simply were Stockholm'd into accepting them.

The moment you learn about things like Ansible, and then ask "wait, what if I want to programatically make GPOs"-- and try to do so-- you realize just how horrendously bad they are.

Their permissions inheritance is terrible, so trying to do least-privelege / granular rights for admins is awful.

Their supercedence structure is confusing, overly complex, and naturally inclines people towards abusing "enforce" and "block" in the worst possible ways.

Un-screwing GPO inheritance messes is essentially impossible, so in production the answer is generally "create a new GPO" rather than "clean up the old mess".

And the settings structure itself is a terrible organizational mess; things "sort of" have a logical structure, except for the thousand odd exceptions. You can't set preferences on items that may not exist (such as disabling insecure services from old OSes) without generating a bunch of logged errors. You can't really target your GPO without some rather expensive client-side queries.

Logging what is actually happening (e.g. why did that printer mapping fail) is awful, which I have generally seen solved by writing one's own drive and printer mapping scripts.

The whole thing is a relic of the 90s that never quite got finished, polished, or maintained and mostly exists because it was "good enough" and there were no real alternatives. There still aren't, really, unless you want a third-party solution which is inevitably almost as big of a maintenance burden as GPO-- and GPO being free and mostly reliable makes it easy to just accept its awfulness.

"GPOs is the worst form of policy management, except for all the others."

I've yet to see something as comprehensive, navigable, and flexible. Sure, it can be horrendously complicated, especially if you chose not to clean up the old mess, but it's still... basically better than everything else.

In the Windows world — SCCM!

Setting up SCCM is an exercise in hating your life but once you have the servers up it’s stupidly powerful.

In the Linux world — Ansible if you want push, Puppet if you want pull.

I've never worked somewhere with SCCM money, that crud's expensive. I've used some more affordable third party tools which I find quite serviceable. And WSUS. Which is beautiful in it's simplicity, yet horrifying once you stray from the narrow path.

Novell had it 20 years ago. Zenworks!

I would say the same but for authentication.

We have linux servers on our domain, specifically becaeuse there are certain things they do better than windows, and im a tool for a trade kinda guy.

But authentication and management of creds is a hard requirement.

The rest i can work with. We setup Ansible to handle much of the day to day config things. GPO"s might be nice.

At one and for years i was using PBIS, and whatever it was called before it was bought out, forked and named PBIS - https://github.com/BeyondTrust/pbis-open

I liked it because it kept GID/UID's consistent across the domain. But it was flaky for samba shares specifically ad group enumeration. There are paid add-ons that leverage GPO but never went that route.

More recently we are just leveraging SSSD/Chrony/Smb/Nmb to do the same, there are a few tweaks, but its solid. Its actually more stable now.

Some GPO's would be nice I supposed.

Fantastic! This brings Ubuntu in front of macOS.

Does anyone know why I can find the admx and get going or is it reading the standard windows policies? Can't seem to find any articles/documentation.

Reply on news.ycombinator.com