Unsolved Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices
-
Hi Everyone,
I'm just looking for some guidance as to how best to implement Active Directory as well as better manageability in general for my company. We have no on-premises servers or AD right now, and aren't using AD in Azure, either. We use GSuite for our email provider, but we also have O365 Dynamics Online accounts under a different domain name, since it wouldn't let me use the domain name we'd already set up with GSuite. I have experience with upgrading pre-existing on-premises domains, as well as setting up an AD-less Azure Infrastructure from scratch, but I've never set up a new on-prem domain nor extended one from Azure to off-premises client devices. Here's some background info on our current systems:
Main office:
- 100MB symmetrical fiber internet
- pfSense firewall/router
- Dell PowerConnect gigabit PoE switch
- Ubiquiti APs
- Mix of desktops and laptops
- 15-20 full-time users at this location
Satellite office:
- 200MB down/50MB up cable internet
- Netgear consumer firewall/router/access point
- All laptops
- 5-10 full-time users at this location
Field technicians:
- Their own home/cellular ISP and routing solutions
- All laptops
- 10-20 full-time technicians that may only visit an office location a few times per year
Industrial Automation PCs:
- Verizon or AT&T Wireless data plans on public internet (Usually 10GB/mo allocated per modem)
- Sierra Wireless RV50 modem/gateway/router devices
- 120 IPCs are scattered over hundreds of square miles and run a mix of Win7Pro and Win10Ent IoT LTSB 2016
Azure Environment:
- Azure SQL VMs
- Service VMs
- Azure app services
- Redis cache, etc.
I'd like to be able to manage all of these devices in AD, if possible, including activating BitLocker and applying GPOs on all of them. Some groups of users, like DevOps and Developers, will need access to the Azure Infrastructure and the Industrial Automation PCs, while other groups, like Accounting, won't need any Azure or Industrial PC access. SSO would be nice, but probably won't be possible until we migrate our email to O365. Bandwidth usage is only a concern on the IPCs, as cellular data overages aren't cheap. We're open to buying a decent hypervisor for each office location if it's necessary to manage our resources successfully.
What's your take on the best way forward? Thanks for any help you can provide!
-
Hmmm....
I'd probably start with Azure AD and just skip regular AD altogether. Join all of your computers to the AAD. You won't have Group Policy, but can look at Salt or Ansible for a GPO alternative.
-
Your automation equipment will very likely not be able to be joined to a domain.
Using Azure AD is the best wya to handle the authentication for such a mix of not in office computers and laptops. But that doe snot grant you any GPO functionality.
I have no idea what type of hybrid AD environment you could possible setup. It is not something I have had to look into with any of my clients.
-
@jaredbusch said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
Your automation equipment will very likely not be able to be joined to a domain.
The automation PCs are just running WIn7 Pro and Win10 Ent... they'll join a domain no problem.
The issue is keeping all 120 devices on the domain.
I know this can be resolved with something like "Direct Access": https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-ras
It works pretty well in my experience, and is simpler to set up and get working now than it used to be.
This will keep all of your 120 remote Win7Pro and Win10Ent devices connected to your local network for management purposes (AD/GPO/etc), and still give you non Direct Access access to the internet. (keeps it separate if you want)
I'm not saying I agree going the MS route with MS AD and all that, but if you have to, this (above) is one thing I'd consider.
Personally, for something like this project, I'd much more prefer a Linux/SaltStack setup. It would be WAY easier to implement and manage, with more benefits.
-
@tim_g said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
The automation PCs are just running WIn7 Pro and Win10 Ent... they'll join a domain no problem.
Just because they run an OS that is able to be joined to AD, it does not follow that they can be joined to AD.
Equipment like this comes with all kinds of caveats and restrictions from the manufacturers.You don't buy a $4,000,000 printing press controlled by a Windows desktop OS and just join it to AD and apply whatever policies you want.
-
@jaredbusch said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@tim_g said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
The automation PCs are just running WIn7 Pro and Win10 Ent... they'll join a domain no problem.
Just because they run an OS that is able to be joined to AD, it does not follow that they can be joined to AD.
Equipment like this comes with all kinds of caveats and restrictions from the manufacturers.You don't buy a $4,000,000 printing press controlled by a Windows desktop OS and just join it to AD and apply whatever policies you want.
Oh I see, I misread and took it as 120 Win7Pro/Win10Ent laptops scattered across the state/country for users. I didn't realize we were talking about tools/appliances.
IN THAT CASE, you don't take a $4,000,000 printing press and do anything at all to it. You don't join it to AD.
If you NEED to have some kind of central access control, then you use only that... such as Salt/Ansible to control local users.
If there is no AD now, why is it needed for those types of equipment? I'd leave them alone, and hand out some laptops users can use to get what they need.
-
@jaredbusch said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@tim_g said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
The automation PCs are just running WIn7 Pro and Win10 Ent... they'll join a domain no problem.
Just because they run an OS that is able to be joined to AD, it does not follow that they can be joined to AD.
Equipment like this comes with all kinds of caveats and restrictions from the manufacturers.You don't buy a $4,000,000 printing press controlled by a Windows desktop OS and just join it to AD and apply whatever policies you want.
in my experience win on automation is a big headache... moslty automation people don't know anything about IT ADDC and the so. Also windows pcs on board are very ofter a security hole (autologin with no password as admin and so on).
keeping it a far as possible from network is a good idea (source: have been for 7 year with automation firms which sold win pcs on board of machines).
-
@tim_g said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
You don't buy a $4,000,000 printing press controlled by a Windows desktop OS and just join it to AD and apply whatever policies you want.
You pray that it's not network attached or if it is, it's an OK that the vendor has a contractual agreement to maintain for the listed life of the printing press.
-
You're very correct about the automation PCs--they're a horror show as far as security goes.
They autologon with admin privileges, and they rarely get updates due to bandwidth and manageability issues. To be clear, the automation PCs don't actually need to be joined to our organization Active Directory, and it'd probably be best if they weren't. If there's a different solution available to monitor/patch/secure them, I'm all for it. Unfortunately, we're stuck with Windows, as a lot of the automation tools we have to interface with only have Windows drivers and utilities available. -
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
Personally, I like the central logon ability created by AD or AAD, this allows a user account to log them into any business controlled computer. If you have AAD, then you also so SSO to the MS solutions associated with that account.
For Windows 10 machines, you can deploy InTune as a MDM solution. It provides GPO like features. Or you can use other options like Salt and Ansible.
Getting an SSO solution to those Windows 7 machines will be the challenging part.
(don't forget, Windows 7 Support dies Jan 2020 - if these machines aren't already deployed, I'd seriously consider other options). -
@jn19 said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
You're very correct about the automation PCs--they're a horror show as far as security goes.
They autologon with admin privileges, and they rarely get updates due to bandwidth and manageability issues. To be clear, the automation PCs don't actually need to be joined to our organization Active Directory, and it'd probably be best if they weren't. If there's a different solution available to monitor/patch/secure them, I'm all for it. Unfortunately, we're stuck with Windows, as a lot of the automation tools we have to interface with only have Windows drivers and utilities available.unfortunately it is not a good idea to keep them update. unless you can recover them.
In theory if you can filter security updates only, those machines should be NOT subject to relevant alterations, but automation software could relay on specifica behaviours (even if the imolementor doesn't know) and any change can be risky.
at least, if you have access to the machines and vendor doesn't put a veto, just keep an image of the system before any update (with stuff like veeam free agent + a recovery usb pen - made by veeam) and then and only then patch the system.manually.
I mean how many of those systems do you have?! treat them as a server patch manually and never do automatic updates on them.
just my 2 cents.
-
@jn19 said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
What's your take on the best way forward? Thanks for any help you can provide!
If you really want AD for that, having a SDN probably makes sense. Something like ZeroTier that allows your AD to exist on every device, everywhere. But to make this work in a reasonable way, you generally either want to do fancy gateway tricks or you want to use a total SDN that extends to every device you have.
-
@dashrender said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
I agree, if it were me, I'd not look at AD here at all. This is where Salt or Ansible seems like a better fit.
-
@scottalanmiller said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@dashrender said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
I agree, if it were me, I'd not look at AD here at all. This is where Salt or Ansible seems like a better fit.
Can salt and/or ansible be used for user/device authentication?
-
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@scottalanmiller said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@dashrender said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
I agree, if it were me, I'd not look at AD here at all. This is where Salt or Ansible seems like a better fit.
Can salt and/or ansible be used for user/device authentication?
Salt/Ansible is not an authentication platform. It's a systems management or state configuration system.
You can use Salt/Ansible to sync accounts across devices... so that you can control what local users and passwords are on which systems.
-
@tim_g said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@scottalanmiller said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@dashrender said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
I agree, if it were me, I'd not look at AD here at all. This is where Salt or Ansible seems like a better fit.
Can salt and/or ansible be used for user/device authentication?
Salt/Ansible is not an authentication platform. It's a systems management or state configuration system.
You can use Salt/Ansible to sync accounts across devices... so that you can control what local users and passwords are on which systems.
I didn't think it was, but did not know about the account sync functionality. Thanks for the info.
-
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@tim_g said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@scottalanmiller said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@dashrender said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
I agree, if it were me, I'd not look at AD here at all. This is where Salt or Ansible seems like a better fit.
Can salt and/or ansible be used for user/device authentication?
Salt/Ansible is not an authentication platform. It's a systems management or state configuration system.
You can use Salt/Ansible to sync accounts across devices... so that you can control what local users and passwords are on which systems.
I didn't think it was, but did not know about the account sync functionality. Thanks for the info.
WIndows users:
https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.win_useradd.htmlLocal group policy:
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.win_lgpo.htmlAlso, remember you can encrypt stuff in SaltStack Pillars for example, so you don't ever have to provide passwords in plain text.
-
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@scottalanmiller said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@dashrender said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
I agree, if it were me, I'd not look at AD here at all. This is where Salt or Ansible seems like a better fit.
Can salt and/or ansible be used for user/device authentication?
No, but it manages the things that are
-
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@tim_g said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@scottalanmiller said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@dashrender said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
I agree, if it were me, I'd not look at AD here at all. This is where Salt or Ansible seems like a better fit.
Can salt and/or ansible be used for user/device authentication?
Salt/Ansible is not an authentication platform. It's a systems management or state configuration system.
You can use Salt/Ansible to sync accounts across devices... so that you can control what local users and passwords are on which systems.
I didn't think it was, but did not know about the account sync functionality. Thanks for the info.
That's a key feature in SodiumSuite's design. Account management across platforms.
-
@scottalanmiller said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@tim_g said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@wrx7m said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@scottalanmiller said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
@dashrender said in Implement new Active Directory across Azure, on-prem, offsite, and cell-data IoT devices:
I'm with the rest - What are you trying to accomplish with AD? Can it be accomplished with other means?
I agree, if it were me, I'd not look at AD here at all. This is where Salt or Ansible seems like a better fit.
Can salt and/or ansible be used for user/device authentication?
Salt/Ansible is not an authentication platform. It's a systems management or state configuration system.
You can use Salt/Ansible to sync accounts across devices... so that you can control what local users and passwords are on which systems.
I didn't think it was, but did not know about the account sync functionality. Thanks for the info.
That's a key feature in SodiumSuite's design. Account management across platforms.
Is that available in SodiumSuite at this time?
