As we learn more about immy.bot we are excited to make the domain join process more seemless and automated. However we are extremely nervous about installing the immy agent to DCs where any technican could accidentally select “Server” as the target for a deployment (it’s one click above Workstation) and before we know it we have Revit, AutoCAD installed on our severs or worse, users/groups.
From a security best practice I think it would be ideal if there was a check box when creating installer that puts the agent in “Domain Join Only Mode” where that is the only task it’s allowed to do. Then not as a replacement, but in addition to, there should be user security granularity that allows us to prevent 99% of our techs from being able to see or select “Server” as a target. For us it’s very rare to automate anything on a server and potentially very dangerous. Lastly, having a fully functioning immy.bot agent on a server just for domain joins is another possible attack vector that we would rather not have there, so if we can have a locked down version that could do very little damage if compromised would allow us to sleep better at night as well.
If the only task you want ImmyBot to do on a server is join the domain, then perhaps ImmyBot is the wrong tool for this job. The effort required to install the ImmyBot agent is roughly the same as the effort required to join the domain, right? Even more so with the security risk you are managing in mind.
ImmyBot can do more than deployments though. It can also manage software updates, eg if you have Putty or other software on servers, ImmyBot can keep that up to date too. You might have servers with Chrome or Firefox installed (less common now that Edge is everywhere), but it’s out of date because nobody ever logs in. ImmyBot can keep that up to date for you too!
Hi James,
I don’t think I was clear. We are using immy to do all kinds of configuration and installation items on laptops and desktops, the list is long and great time saving once set up. One of those tasks is to name the machine and add it to Active Directory, this requires us to have the agent running on the server. However we don’t want immy to be able to do anything on the server, just act as the broker for the offline domain join process.
So yes we could add laptop to domain in same time it takes to install immy on the server but that’s only one server it’s needed on, eventually we want to have 1000+ laptops and desktops getting domain joined (and apps installs and confides set) . The one thing we don’t want is Revit installed on our DC because a tech clicked Server instead of Workstaion right below, or selected No Filter at all.
Hope that clarifies.
Yeah that makes perfect sense - you only have it on the DC to do the other part of the offline join. I don’t know why I even thought otherwise!
Technically, you should only need ImmyBot on a server (or workstation?) with the AD management tools on it, not necessarily the DC itself. A lot of tools that do this kind of thing overlook that, and also assume that a DC always includes the AD management tools (Windows Server Core does not - this bit us just recently).
So if you have capacity and licensing you could just spin up a tiny server and install ImmyBot and the AD management tools (inc powershell module), and not install ImmyBot on any actual DC’s, then tell ImmyBot that your management server is the DC in the deployment options. There’s still the risk that someone might install unwanted software on it, but at least that won’t damage your production servers.
I think you could instead spin up a Windows 10 VM and install the management tools on that, but then you have to exclude that from maintenance, which isn’t a scenario ImmyBot manages well. And with all its bells and whistles Windows 10 probably has more OS overhead these days than a WIndows Server OS anyway.
It’s not a complete solution, but it does reduce the risk
You need it on the DC itself because that’s the only way you can get an offline domain join token without the need to supply domain credentials for the join.
That’s not happened to us in 2.5 years–I don’t think that mistake is that easy to make considering “Workstations and Portables” is selected by default.
Have we had mistakes in deployments? Yes, but NEVER this mistake.
Correct. If the only permission it needs is “add device to the domain” then you might be able to grant this to the computer account. If other AD permissions are required then this might start to go down the rabbit hole of complexity…
Yes, and before 2FA was a common thing people used to say their accounts were never compromised until they were. We’re just not fans of the general lack of security granularity in immy.bot, seems like a real weak point. To me this is a no brainer, we don’t even like the idea that we have to have immy.bot on a DC at all to do this as it’s yet another piece of software that can be a vector, add to that users that are learning the platform can make mistakes. They may not even realize there are DCs with immy agent so they think there’s no harm and just select “no filter”. Yes we need to train them but as with our RMM, GDAP/365, you only give staff the access they need, not the power to do everything and hope they never make a mistake. Seems like a bad take if you ask me.
@PBNJ_Phill Create a user on the domain with just the roles required to create the offline domain join token, and use the credentials for that account to run the service.
That sounds like a plan, it’s what I thought I would have to do originally and couldn’t find anything documented on setting it up properly. I reached out to support and then I was told I was “over thinking it”, I guess it turns out I wasn’t.
I would still like to see this as a feature. I think deploying anything to servers should be something we can lock down to a specific group of staff. As something that is built by MSPs I would think that security and security granularity would be very high on the list, so hopefully this makes it on the to-do list at some point.
Will give the locked down account a try and see how that goes. Thanks.