Solved Software restriction policy on Workgroup network ?
-
@openit said in Software restriction policy on Workgroup network ?:
Is Salt/Ansible are alternative kind of software for PDQ Deploy ?
Because I tried to use PDQ Deploy Free, I wondered it was asking for Domain Credentials to setup, so I left it.
Um, sort of. PDQ Deploy is a very simple (but really good) software deployment tool. Salt and Ansible (along with Chef, Puppet, cfEngine and others) are full DevOps style Change Management State Machines. With Salt, as an example, you could manage your servers and never log into a server (or desktop) ever again. Just "define its state" in Salt and let Salt do all of the work. You can do "anything" from Salt.
-
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Is Salt/Ansible are alternative kind of software for PDQ Deploy ?
Because I tried to use PDQ Deploy Free, I wondered it was asking for Domain Credentials to setup, so I left it.
Um, sort of. PDQ Deploy is a very simple (but really good) software deployment tool. Salt and Ansible (along with Chef, Puppet, cfEngine and others) are full DevOps style Change Management State Machines. With Salt, as an example, you could manage your servers and never log into a server (or desktop) ever again. Just "define its state" in Salt and let Salt do all of the work. You can do "anything" from Salt.
This reminds me following article I have read it years ago
-
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
The actual reason why our all pcs not under domain is, "some PC OSes are Home Editions". And I was not willing to bring half pcs to domain and leave remaining under Workgroup, until we buy Pro Versions.
Then you are in a good position to seriously consider never having a domain.
This made me feel Happy !
I always felt bad, when I was not able to do easily due to lack of Domain.
Domains are the panacea that people think that they are. Microsoft's marketing has been very powerful in the SMB. AD Domains are certainly nice and powerful and well integrated into Windows, but we don't use them at NTG for a reason - too much work, too little benefit. We had it and we own the licensing for it, but we removed it and are happier without it. I've worked in companies with hundreds of people not on domains and it worked great. There are lots of cases where they just don't make sense.
Great feedback (with case study
) -
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Whether these Salt/Ansible servers are available for Windows and/or Linux ?
My Linux install guide is like two commands to fully set up Salt on Linux, it's that simple. Would be much harder on Windows and no value to it.
I understand why to run on Linux. How about clients ? do we have any agent installer to get control on Windows machines (windows 7-10) ? or it's an agent-less controller ?
-
@openit said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Whether these Salt/Ansible servers are available for Windows and/or Linux ?
My Linux install guide is like two commands to fully set up Salt on Linux, it's that simple. Would be much harder on Windows and no value to it.
I understand why to run on Linux. How about clients ? do we have any agent installer to get control on Windows machines (windows 7-10) ? or it's an agent-less controller ?
Salt is agent based and has an agent for Windows. Ansible is agentless and I've not used it on Windows.
-
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Whether these Salt/Ansible servers are available for Windows and/or Linux ?
My Linux install guide is like two commands to fully set up Salt on Linux, it's that simple. Would be much harder on Windows and no value to it.
I understand why to run on Linux. How about clients ? do we have any agent installer to get control on Windows machines (windows 7-10) ? or it's an agent-less controller ?
Salt is agent based and has an agent for Windows. Ansible is agentless and I've not used it on Windows.
Great.
Also, can you provide the Salt install guide ?
I guess, it will be on CentOS 7?
-
@openit said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Whether these Salt/Ansible servers are available for Windows and/or Linux ?
My Linux install guide is like two commands to fully set up Salt on Linux, it's that simple. Would be much harder on Windows and no value to it.
I understand why to run on Linux. How about clients ? do we have any agent installer to get control on Windows machines (windows 7-10) ? or it's an agent-less controller ?
Salt is agent based and has an agent for Windows. Ansible is agentless and I've not used it on Windows.
Great.
Also, can you provide the Salt install guide ?
I guess, it will be on CentOS 7?
https://mangolassi.it/topic/11812/installing-salt-master
https://mangolassi.it/topic/11813/installing-a-salt-minion
https://mangolassi.it/topic/11814/adding-a-salt-minion-to-a-salt-master
https://mangolassi.it/topic/11891/deploying-saltstack-on-windows
-
@openit said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
The actual reason why our all pcs not under domain is, "some PC OSes are Home Editions". And I was not willing to bring half pcs to domain and leave remaining under Workgroup, until we buy Pro Versions.
Then you are in a good position to seriously consider never having a domain. Domains can be great, they can also be expensive and are very hard to remove once you implement them. If you look at tools like Salt, you can pretty easily go with a free alternative that is vastly more powerful (in most ways) than a domain while not locking you into anything.
Or if you feel a domain is required, you can do it from the start using Linux and never become encumbered by the enormous "Windows tax".
Is Salt/Ansible are alternative kind of software for PDQ Deploy ?
Because I tried to use PDQ Deploy Free, I wondered it was asking for Domain Credentials to setup, so I left it.
It was asking for Domain Credentials because they offer the easiest way to ensure a universal credential across all machines.
The Salt/Ansible agent on the endpoints have local admin rights, so they can install stuff using that credential.
-
@Dashrender said in Software restriction policy on Workgroup network ?:
It was asking for Domain Credentials because they offer the easiest way to ensure a universal credential across all machines.
So in most cases, what's the benefit to ensuring that? Is that important? Clearly if you have roaming users it can be pretty beneficial. But that is relatively rare, I remember everyone telling me I was crazy for wanting that at NTG because we were the exception case and that normal companies don't need that.
-
Domains are not the only means of having password control. You can ensure that all users have the same password from machine to machine without a domain using Salt. Now this would require some automation to do well, but the tooling is there.
https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.win_useradd.html
-
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Also, just wondering to know, once we setup SRP, what impact will be while installing legitimate software ? (here we have given users a standard account and separate administrator account for admin to install something)
No legitimate business software expects or requires an administration account. If it does, it's a total joke and has no place in a business environment.
What in the f*** [moderated] are you babbling about? FFS. All quality software should ask for proper elevation to install itself into the protected programs directory of the OS.
Stop intentionally misreading and spreading incorrect information.
-
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Also, just wondering to know, once we setup SRP, what impact will be while installing legitimate software ? (here we have given users a standard account and separate administrator account for admin to install something)
No legitimate business software expects or requires an administration account. If it does, it's a total joke and has no place in a business environment.
What in the fuck are you babbling about? FFS. All quality software should ask for proper elevation to install itself into the protected programs directory of the OS.
Stop intentionally misreading and spreading incorrect information.
Exactly - Scott's right that no good software should require local admin rights to function normally. But the OP was asking about deploying software, not using software. In the deployment game, JB is correct, the software will require access to a local admin account to install into protected areas. Sadly, some software (Chrome comes to mind) are purposefully looking for ways to thwart this.
-
@scottalanmiller Stop shoving your current favorite toy down the poor guy's throat.
Salt and Ansible are great tools, but they are not a panacea.
There are many other perfectly viable tools that are much easier to implement for someone with out any experience than trying to shoe horn in dev-ops tools.
-
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Also, just wondering to know, once we setup SRP, what impact will be while installing legitimate software ? (here we have given users a standard account and separate administrator account for admin to install something)
No legitimate business software expects or requires an administration account. If it does, it's a total joke and has no place in a business environment.
What in the fuck are you babbling about? FFS. All quality software should ask for proper elevation to install itself into the protected programs directory of the OS.
Stop intentionally misreading and spreading incorrect information.
To RUN, obviously.
-
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller Stop shoving your current favorite toy down the poor guy's throat.
Salt and Ansible are great tools, but they are not a panacea.
There are many other perfectly viable tools that are much easier to implement for someone with out any experience than trying to shoe horn in dev-ops tools.
I offered several tools, he specifically asked for tools of that nature and I offered a few. But you'll notice that first I offered a few other approaches.
-
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Also, just wondering to know, once we setup SRP, what impact will be while installing legitimate software ? (here we have given users a standard account and separate administrator account for admin to install something)
No legitimate business software expects or requires an administration account. If it does, it's a total joke and has no place in a business environment.
What in the fuck are you babbling about? FFS. All quality software should ask for proper elevation to install itself into the protected programs directory of the OS.
Stop intentionally misreading and spreading incorrect information.
To RUN, obviously.
I realize that, obviously.
But it has nothing to do with the thread or what you replied to.
-
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller Stop shoving your current favorite toy down the poor guy's throat.
Salt and Ansible are great tools, but they are not a panacea.
There are many other perfectly viable tools that are much easier to implement for someone with out any experience than trying to shoe horn in dev-ops tools.
I offered several tools, he specifically asked for tools of that nature and I offered a few. But you'll notice that first I offered a few other approaches.
And then spent 20 posts shoving Salt down everyone's throat.
-
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Also, just wondering to know, once we setup SRP, what impact will be while installing legitimate software ? (here we have given users a standard account and separate administrator account for admin to install something)
No legitimate business software expects or requires an administration account. If it does, it's a total joke and has no place in a business environment.
What in the fuck are you babbling about? FFS. All quality software should ask for proper elevation to install itself into the protected programs directory of the OS.
Stop intentionally misreading and spreading incorrect information.
His question was about end users accounts, not accounts for installation. I was answering the question asked and the end user accounts should never need to be admins. Why do your users need to be admins for legitimate software that you've installed for them?
-
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller Stop shoving your current favorite toy down the poor guy's throat.
Salt and Ansible are great tools, but they are not a panacea.
There are many other perfectly viable tools that are much easier to implement for someone with out any experience than trying to shoe horn in dev-ops tools.
I offered several tools, he specifically asked for tools of that nature and I offered a few. But you'll notice that first I offered a few other approaches.
And then spent 20 posts shoving Salt down everyone's throat.
Which 20 posts were those? Where did I promote it rather than answer a question?
-
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@JaredBusch said in Software restriction policy on Workgroup network ?:
@scottalanmiller said in Software restriction policy on Workgroup network ?:
@openit said in Software restriction policy on Workgroup network ?:
Also, just wondering to know, once we setup SRP, what impact will be while installing legitimate software ? (here we have given users a standard account and separate administrator account for admin to install something)
No legitimate business software expects or requires an administration account. If it does, it's a total joke and has no place in a business environment.
What in the fuck are you babbling about? FFS. All quality software should ask for proper elevation to install itself into the protected programs directory of the OS.
Stop intentionally misreading and spreading incorrect information.
To RUN, obviously.
I realize that, obviously.
But it has nothing to do with the thread or what you replied to.
I only replied about end user accounts, never admin accounts for installation or the IT team. Don't know what thread you were looking at.
