Could use tools like ansible, chef, etc.
Why aren't they part of a domain?
this post was submitted on 07 Aug 2023
13 points (78.3% liked)
Sysadmin
7664 readers
1 users here now
A community dedicated to the profession of IT Systems Administration
No generic Lemmy issue posts please! Posts about Lemmy belong in one of these communities:
!lemmy@lemmy.ml
!lemmyworld@lemmy.world
!lemmy_support@lemmy.ml
!support@lemmy.world
founded 1 year ago
MODERATORS
Even if they weren't, could use something like Chocolatey to automate updates, along with ansible, chef, etc.
Yeah for sure. From a security perspective s domain acts as a boundary though and when done correctly adds protection. 15 VMs all windows based would benefit from this and would add very little overhead.
Creating an AD domain carries a substantial amount of extra overhead that they might not want to deal with. The basics of setting one up are simple enough but actually building out/maintaining the infrastructure the correct way can be a lot of extra work (2 DCs for redundancy, sites configuration, users, groups, initial GPOs). There are also licensing and CAL considerations (bare metal and hypervisor, both different), domain and forest options that can paint you into a nasty corner of you're not careful, and a whole host of other things to think about and plan around. I'm not arguing that a domain is bad, on the whole I agree 100%. I just like to set the record straight that building a new production domain isn't as simple as a lot of people would have you believe, and OP might not have the time to go through all that.
I think you're blowing this way out of proportion. It's literally not a substantial amount of extra overhead, it's minimal and for what one would provide in the long run it is worth mentioning.
Well by the sounds of it, he has multiple clients. So then we're talking multiple domains in a forest. Securing it all and doing it properly.
So it's a bit more than just running the domain setup wizard and joining the servers.
Why would there be more than a single domain and forest? Client size does not dictate the architecture and joining a client to the domain takes a few minutes manually. I don't see what you're getting at, sorry.
Edit: instead of being upset and downvoted, whoever disagrees can provide an argument. I'm all for discussing this, I've been doing it for a long time and enjoy different opinions.
He said 15 VM's running for clients. Now you would want to secure these clients from each other, restrict east to west movement. Adding them all on the same domain introduces security risk, reducing them risk and hiding clients from one and other in the same domain would take lots of effort. So just don't put yourself in that situation and use multiple domains one domain for each client.
Lol you can absolutely control E/W movement without needing multiple domains..
Worst case you use a red forest as the admin forest, but with an environment that small there are plenty of other things you can do without making it that complicated while providing similar protection.
Then you start getting things like Azure AD Sync etc. It's best practice one domain per client. Not trying to make one domain work for multiple different clients.
You don't need anything from Azure to do that. Authentication policy and silos are what enforces multi tenancy east west boundaries (among many, many other layers outside of the scope of this conversation).
But it looks like I misread what the "client" context was initially. So that's my bad. That does muddy the waters and would depend on what the agreements are between the companies and OP have. But this isn't a technical constraint rather a business and legal decision.
We are using Tanium, just put the agent on the servers and you are good to go...build your packages and set up deployment jobs.
It also handles Windows patching, and can do system inventory, among other features.
It's also great for software deployments to you remote workforce systems that are rarely/never on the corporate network.
And seriously, you want a domain. GPOs are incredibly useful for pushing out a huge variety of Windows config changes extremely easily.
Does it handle application updates as well?
Tanium has some common apps pre-packaged and regularly updated, you could just setup an ongoing deployment for those to automate keeping them up to date with minimal work on your part.
If you need to update something not on that list, you will need to make an upgrade package yourself with the updated installer or files.
Whether this is actually easy or not really depends on the app vendor and the software. It's usually straight forward, but not always. But that's the case with literally any software deployment solution.
I have one app in particular who's install and config essentially un-automateable. But it's a shitty LOB app that was written in the 90's to be intentionally obtuse to prevent privacy, hopefully that's not an issue in your case.
PDQ Deploy and Inventory. Simple and effective.
Tactical RMM works well for me. You also can use ssh.
You will need a software manager such as Ruckzuck or scoop