我们正在构建一个旨在在基于 Windows 的服务器上运行的应用程序。我们目前正在考虑的考虑之一是如何控制对应用程序 GUI 的访问，它允许配置和控制“后端”服务。
为了正确保护应用程序，有几个对象需要应用 ACL - 文件、目录、注册表项、命名管道、服务等。我们需要为管理员提供一些方法来配置这些 ACL 以限制访问仅限授权用户。
我们考虑过的一种方法是创建一个可以同时修改所有这些对象上的 ACL 的工具，但这将是相当大的工作量并且可能很脆弱。
我们正在研究的另一种可能的方法是创建一个自定义组（例如“我的应用程序用户”），这样我们就可以赋予该组对每个对象的适当权限。这意味着管理员将能够使用熟悉的 Windows 组成员工具添加/删除授权用户。
那么：在安装时创建组是可以接受的事情，还是可能会让管理员感到不安？老实说，我更熟悉 UNIX 世界，基于服务器的应用程序或多或少会创建组，但我不确定 Windows 生态系统中的礼仪。
另外：我错过了更好的解决方案吗？
提前致谢！
这个问题是双重的——一个是技术性的，一个是政治性的。从技术上讲，本地组很好，您可以将 AD 或域用户添加到本地组中，每个人都很高兴。就应用程序是否应该扰乱服务器的安全“立场”而言，唯一合理的答案是弹出某种请求，告诉用户您将要做什么并请求许可（确保您还记录了该决定某种日志或条目）。这也解决了每个人的合法 a$$，例如，如果他们点击“不，让我的应用程序不安全”并被黑客入侵）。
采用 UNIX 方法，您可以告诉用户您需要什么，建议一个本地组（并让用户有机会选择另一个本地或域/AD 组）。看看（例如）Oracle 安装在 UNIX 上是如何做到的。
由于这是一个服务器应用程序，您可能必须支持静默/无人值守安装，请确保可以在安装脚本中指定行为，并且非常非常肯定脚本的行为已记录在案，这样就没有人安装程序实现安装程序实施的安全策略的更改。
我认为为此目的创建一个本地组是非常好的。
此外，经过深思熟虑后，我无法提出更好的解决方案。
根据实施的规模，小组可能是要走的路。但请记住，应该设置目录和注册表上的相关 ACL。我同意将它们设置一次到组，然后让访问控制由组成员维护。关于 klausbyskov 的回答，我认为本地组可能没问题，但请考虑使用 LDAP。从安全角度来看，您将分离身份验证过程并让目录处理它；使用kerberos。