Run a domain without Active Directory (UCS)

Dieselboy · April 30, 2019, 08:17:37 PM

Have been doing some research lately and came across this UCS server (not Cisco UCS).

It uses Samba 4.x managed via web browser. The VM can be installed with a desktop or with CLI but you dont need either after setup. You can browse to the system, log in and configure domain using point and click. They have a wizard that they explain can migrate your AD to UCS in a few clicks although that does sound scary

I think this would be great for home use as it's free. Like things Open Source it comes with bolt-ons from their "app store". You can click "install" on a number of apps such as Colabora (the open source, online document tool like "google docs") as well as the owncloud (open source google drive). There is mail servers in there, tons of things.
As you can replace AD with this, you can join Windows computers to the UCS domain. But in addition you can also join Linux systems to the domain. Although from what I could find out, the only way to manage Linux systems with a GPO is using a system called "PBIS Enterprise".

https://www.univention.com/

deanwebb · May 13, 2019, 12:22:47 PM

It's definitely a fun thing, but I have to have a for-reals DC in my lab so I can reproduce customer issues...

wintermute000 · May 15, 2019, 02:59:57 AM

Samba4 underpins AWS Simple AD and is definitely 'good enough' if you tick off your use-cases and required features very carefully.
Problem is most businesses are headlocked in the MS ecosystem so rapidly it becomes not good enough, however, for a point solution it works great (like Simple AD). You can even manage it via pointing a windows server to it and using the regular tooling, it has no idea its not talking to 'real' AD under the hood.

Linux management is an entirely different question. I would stay the heck away from anything further than simple user/LDAP join with SSSD or any 'standard' linux method/library. GPO what are you smoking lol. Ansible/Puppet/Chef that shiz. OFC IANA linux engineer so you probably know a lot more than me on this topic, seeing as you run your own openstack

Dieselboy · May 16, 2019, 01:37:43 AM

All good points made there wintermute

GPO is a requirement for us for DLP (Data loss prevention). Research on that item is something that will be done in the future but it looks like the best way forward for that is an installable agent from a 3rd party. Compared with Windows server and windows domain-joined computers, no agent required there. You can use GPO. Down side is if those machines leave the corp. network, then updates cannot be pushed. Unlike with an agent which would be cloud-managed in 2019.

Regarding linux joining domains, historically I have been manually configuring the SSSD krb etc but I found some software called PBIS Open. This gives you a CLI that you can use to join the linux system to the domain with a single line. The tool then goes and configures all of those config files. I took a look at the files afterwards and the level of config applied there is very comprehensive. Compared to my own doc I wrote, it's not as in-depth. So I hope the PBIS software prevents the odd issue I have sometimes where the system kind of leaves the domain and becomes disconnected. I've seen this with apple mac and rhel.

I do run openstack but my ansible skills are shallow and my puppet/chef skills are non-existent! I was reading a doc yesterday on how to update rhel7 to rhel8 and it mentioned in there to stop chef or puppet so that it does not roll back the filesystem (downgrading the upgrade) while the upgrade is going ahead. Didn't even realise that capability until I read it there.

deanwebb · May 19, 2019, 02:33:54 PM

Quote from: Dieselboy on May 16, 2019, 01:37:43 AM
I was reading a doc yesterday on how to update rhel7 to rhel8 and it mentioned in there to stop chef or puppet so that it does not roll back the filesystem (downgrading the upgrade) while the upgrade is going ahead. Didn't even realise that capability until I read it there.

Otanx · May 20, 2019, 09:21:04 AM

Quote from: Dieselboy on May 16, 2019, 01:37:43 AM
I was reading a doc yesterday on how to update rhel7 to rhel8 and it mentioned in there to stop chef or puppet so that it does not roll back the filesystem (downgrading the upgrade) while the upgrade is going ahead. Didn't even realise that capability until I read it there.

This has bit me in the butt more than I care to admit. Not on full system upgrades, but changing a config file, and have it overwritten in the middle of the night by an automated job. This wouldn't be a major problem except that our old automation would update the files, but not restart the service. So the system would work until it was rebooted which could be weeks later.

-Otanx

deanwebb · May 22, 2019, 06:47:42 AM

^ Question: how many other automated processes out there are doing dumb things?

We dream of AI, but don't really stop to ask ourselves, "Hey, are we weaponizing stupidity?"

Dieselboy · May 23, 2019, 01:38:41 AM

Quote from: Otanx on May 20, 2019, 09:21:04 AM
Quote from: Dieselboy on May 16, 2019, 01:37:43 AM
I was reading a doc yesterday on how to update rhel7 to rhel8 and it mentioned in there to stop chef or puppet so that it does not roll back the filesystem (downgrading the upgrade) while the upgrade is going ahead. Didn't even realise that capability until I read it there.

This has bit me in the butt more than I care to admit. Not on full system upgrades, but changing a config file, and have it overwritten in the middle of the night by an automated job. This wouldn't be a major problem except that our old automation would update the files, but not restart the service. So the system would work until it was rebooted which could be weeks later.

-Otanx

Ouch but I understand. I had something similar happen. I have a server instance (VM) running in google cloud. The server was shutdown because the account ran out of PAYG credit. So we sorted out the billing issue and booted up the server - failed to boot. Then spent most of the day in a P1 scenario trying to get it booted while another team worked on restoring a backup. Eventually got it booted, which was a huge learning experience. I had to get into the grub menu which doesnt display by default on the cloud instance.
Turns out that someone had done a yum update -y and not rebooted to update the kernel. The kernel might have been deleted after that so it was unable to load the kernel when rebooting.
I initially blamed google for killing the instance when the credit ran out

which turned out to be incorrect, issue was there since whenever.

Otanx · May 23, 2019, 12:03:03 PM

Ouch. It sucks when that kind of stuff happens. The system being down was already an issue, and then you hit one of these issues on top of it making it worse. We started monitoring uptime of servers, and alerting on over 45 days. Nobody should be scared of rebooting a single server, and regular reboots will catch issues like these in a controlled way. Plus patching of course.

-Otanx

Dieselboy · May 23, 2019, 09:26:59 PM

Yep! I've started managing VMs in my work place similarly to how AWS manage their customer VMs. They will send a notification that maintenance is going ahead and the VMs might be rebooted. What I think is actually going on in the back end is migration of VMs to other hardware so they can do the maintenance. If live migration is not working for any reason then shut down, migrate, boot up. Customer just sees it as a reboot.

I've surmised this becaue my openstack env. sometimes has an issue with live migration due to the running VM being allocated HDD space on the hypervisor host (either for HDD or swap etc).

I had an issue this week where a VM was rebooted and after boot up had an issue with a service starting. Turns out the system is running docker with non-persistant storage. After reboot the data was missing.