我是否应该将Active Directory公开给远程用户使用？

我有一个客户，其员工完全由使用Apple和Windows 7 PC /笔记本电脑的远程员工组成。

用户目前不针对某个域进行身份验证，但是出于多种原因，组织希望朝该方向发展。这些是公司拥有的机器，公司寻求对帐户停用，组策略和某些轻量数据丢失的预防（禁用远程媒体，USB等）进行某种控制。他们担心需要VPN身份验证才能访问AD这将很麻烦，尤其是在终止员工和远程计算机上缓存的凭据的交集处。

组织中的大多数服务都是基于Google的（邮件，文件，聊天等），因此唯一的域服务是DNS和Cisco ASA VPN的身份验证。

客户想了解为什么将其域控制器公开给公众是不可接受的。此外，对于分布式远程劳动力，什么是更可接受的域结构？

编辑：

Centrify用于少数Mac客户端。

我之所以将其发布为答案，主要是因为每个人都基于IT方面的经验，第三方信息，传闻和部落知识有自己的“受教育的见解”，但这更多是Microsoft的“直接”引文和读物清单。我使用引号是因为我确信它们不能正确过滤其员工的所有意见，但是如果您是authoritative直接从Microsoft 获得参考，这对您还是很有帮助的。

顺便说一句，我也很容易地说DOMAIN CONTROLLER == ACTIVE DIRECTORY，情况并非如此。AD FS代理和其他方式（基于OWA，EAS等的基于表单的身份验证）提供了一种将AD自身“公开”到Web的方法，以允许客户端至少尝试通过AD进行身份验证而不公开DC本身。转到某人的OWA站点并尝试登录，AD 就会在后端DC上获得身份验证请求，因此从技术上讲AD是“公开的” ...但是通过SSL保护并通过Exchange服务器代理。

引用1

在Windows Azure虚拟机上部署Windows Server Active Directory的准则

在进行“ Azure不是AD”之前，您可以在Azure VM上部署ADDS。

但是要引用相关的位：

切勿直接将STS公开到Internet。

作为安全性最佳实践，请将STS实例放置在防火墙之后，并将其连接到公司网络以防止暴露于Internet。这很重要，因为STS角色会发出安全令牌。因此，应该对它们进行与域控制器相同的保护级别。如果STS受到威胁，恶意用户就可以发出访问令牌，这些令牌可能包含对信任组织中依赖方应用程序和其他STS的选择权。

因此，...不要将域控制器直接暴露给互联网。

引用2

Active Directory-AD LDS的UnicodePwd之谜

将域控制器暴露给Internet通常是一个坏习惯，无论这种暴露是直接来自生产环境还是通过外围网络。自然的替代方法是在外围网络中放置一台具有Active Directory轻型目录服务（AD LDS）角色的Windows Server 2008服务器。

引文＃3-不是来自MS ...但是在展望未来时仍然有用

Active Directory即服务？Azure，Intune暗示了云托管的AD未来

最后，没有一个很好的“简短”答案可以满足删除AD服务器办公室以换取Azure替代方案的目标。尽管微软在允许客户在Azure中的Server 2012和2008 R2机器上托管Active Directory域服务方面表现得很自满，但它们的用处仅与为员工提供的VPN连接一样好。DirectAccess是一项非常有前途的技术，但由于其自身的不幸局限性而束手无策。

引文4

使用单点登录和Windows Azure虚拟机部署AD DS或AD FS和Office 365

域控制器和AD FS服务器绝对不应直接暴露给Internet，而只能通过VPN访问

Active Directory（AD）并非针对此类部署而设计。

产品设计中使用的威胁模型假定“防火墙后”部署，并且在网络边界过滤了一些敌对行为体。虽然您当然可以加强Windows Server使其暴露于公共网络中，但Active Directory的正常运行需要一种安全态势，而这种安全态势显然要比为面向公共网络而硬化的主机更为宽松。一个很多服务都必须从一个域控制器（DC）暴露AD正常工作。

Zoredache在评论中的建议，特别是引用像OpenVPN这样作为带有证书认证的机器范围服务运行的东西，可能是一个很好的选择。正如其他人提到的那样，DirectAccess正是您所需要的，除了它没有您想要的跨平台支持。

顺便说一句：我已经想到了使用基于证书的传输模式IPSEC将AD直接暴露给Internet的想法，但实际上却没有时间这样做。微软在Windows Server 2008 / Vista的时间范围内进行了更改，以使此操作可行，但我从未实际使用过。

其他人怎么说。我对克里斯托弗·卡雷尔（Christopher Karel）提到的强力尝试感到特别紧张。 在上一届Def Con上的演讲涉及以下主题：

那么您认为域控制器是安全的吗？

微软的贾斯汀·亨德里克斯安全工程师

域控制器是组织的皇冠上的明珠。一旦它们倒下，领域中的一切都会倒下。组织竭尽全力保护其域控制器，但是他们常常无法正确保护用于管理这些服务器的软件。

本演讲将介绍通过滥用组织部署和使用的常用管理软件来获得域管理员的非常规方法。

贾斯汀·亨德里克斯（Justin Hendricks）在Office 365安全团队工作，他参与了红色团队，渗透测试，安全研究，代码审查和工具开发。

我相信您还能找到许多其他示例。我一直在寻找有关域控制器和黑客攻击的文章，希望能获得对找到DC的速度的描述，等等，但是我认为现在就可以了。

如果您想说服管理层，一个好的开始是：

It goes against Microsoft's Best Practices for Active Directory Deployment.

更新：请参阅此technet文章，内容涉及防止域控制器受到攻击，标题为的部分Perimeter Firewall Restrictions指出：

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

标题为Blocking Internet Access for Domain Controllers：

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

我敢肯定，您可以就此事征询一些Microsoft文档，仅此而已。除此之外，您还可以陈述这种举动的危害，大致如下：

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

缓存的凭据就是缓存。它们在无法连接到域的本地计算机上工作，但是如果该帐户被禁用，它们将不适用于任何网络资源（svn，vpn，smb，fbi，cia等），因此他们不必担心。还请记住，无论如何，用户已经对本地计算机上的配置文件文件夹中的任何文件（以及可能的可移动介质）拥有完全权限，因此，禁用凭据或不使用凭据都可以按照自己的意愿进行操作。一旦本地计算机重新连接到网络，它们也将不适用于本地计算机。

您是指Active Directory或域控制器提供的服务（例如LDAP）吗？如果是这样，则通常会出于身份验证和目录查询的目的而安全地破坏LDAP，但是仅关闭Windows防火墙（或将所有必需的端口开放给公众使用-在此示例中相同）可能会导致严重问题。

AD不能真正管理 Mac，因此需要一个单独的解决方案（以OS X Server为例）。您可以将Mac加入域中，但这不仅仅可以让他们使用网络凭据进行身份验证，还可以将域管理员设置为Mac上的本地管理员，等等。无组策略。MS试图用新版本的SCCM突破这一领域，后者声称能够将应用程序部署到macs和* nix盒中，但是我还没有在生产环境中看到它。我也相信您可以将macs配置为连接到OS X Server，这将对基于AD的目录进行身份验证，但是我可能是错的。

话虽这么说，但可以设计一些创造性的解决方案，例如Evan建议使用OpenVPN作为服务，并在有时间放开该员工时禁用计算机证书。

听起来一切都基于Google，所以Google充当您的ldap服务器吗？我建议我的客户尽可能保持这种方式。我不知道您的业务性质，但对于git或redmine服务器等基于Web的应用程序，即使内部设置可以利用Google帐户通过OAuth进行身份验证。

最后，像这样的公路战士设置几乎需要 VPN才能成功。将机器带入办公室并进行配置（或通过脚本远程配置）后，它们需要一种接收配置更改的方法。

Mac除了VPN之外还需要一种单独的管理方法，这太糟糕了，它们不再制造真正的Mac服务器，但是我上次检查时（几年前）它们确实在OS X Server中实现了一些不错的策略实现。 ）。

不幸的是，DirectAccess仅在Win7 +企业版中可用，因为它是根据您的要求量身定制的。但是不知道您的版本，并看到您拥有MacOS，那是行不通的。

/编辑-看起来有些第三方声称他们拥有Unices的DA客户端：http : //www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

有可用的MDM解决方案可以满足您的需求。我们会将其中一个（MAAS360）推出给处于类似位置的客户。

这显然是重大的安全风险。此外，它可能不会像您希望的那样工作。如果Internet上随机的人能够尝试登录到您的AD环境，则很有可能您的所有用户都将被锁定。永远。消除锁定要求意味着对简单密码进行暴力检查变得非常容易。

更重要的是，在不使AD服务器直接可访问的情况下，实现目标（最终用户使用域凭据登录到便携式计算机）应该没有问题。即，Windows计算机可以缓存最近的X次成功登录，以便那些相同的凭据在断开连接时也可以工作。这意味着最终用户可以登录并执行有用的工作，而无需触摸您的AD服务器。他们显然需要利用VPN连接到其他主要公司资源，并且可以同时刷新AD / GPO设置。

Ewwhite，

您的问题非常有效，值得您仔细审查。

所有安全专家都建议在任何网络资源（包括SPI防火墙，IDS，基于主机的防火墙等）之前都应具有安全性。在可能的情况下，应始终使用诸如ISA（现为TMG）之类的代理外围网关防火墙。

也就是说，Microsoft Active Directory 2003+尚未公开披露任何重大漏洞。LDAP技术及其哈希算法通常非常安全。如果说SSL VPN运行OpenSSL并且容易受到恶意攻击，那么可以说它比SSL VPN更安全。

我会警告5件事：

1. 请关注网络面临的其他服务，例如终端服务器，DNS服务，CIFS，尤其是具有糟糕安全记录的IIS。

2. 将LDAPS与安全证书一起使用，以避免通过网络传递明文域凭据。安装证书服务后会自动发生（使用单独的PKI机器）

3. 在接口上放一个数据包嗅探器，观察流量，更正所有明文密码，因为是否有防火墙，如果您不使用VPN或LDAPS，则某些旧系统将发送明文密码。

4. 知道MITM攻击会强制本机身份验证机制降级，并将密码公开给较弱的NTLM身份验证。

5. 请注意可能仍然存在的一些用户枚举漏洞。

也就是说，Active Directory在安全性方面拥有良好的记录。此外，MS Active Directory不存储密码，仅存储散列值，这些散列值也可以减轻危害的严重性。

您可能会受益于更加无缝的安全性基础结构，无需设置特殊的DNS服务器或使用domain.local，并且可以在公共互联网（例如domain.com）上使用实际的域。

以我的专业意见，公开部署安全技术（如Active Directory）会带来巨大的好处，而其他技术（如Exchange，DNS和Web服务器）根本不会带来任何好处，并且会带来所有风险。

注意：如果部署Active Directory，它将包括DNS服务器。一定要禁用DNS服务器上的递归（默认情况下已启用），否则您将绝对参与拒绝服务攻击。

干杯，

-布莱恩

戴尔（通过购买Quest（通过购买Vintela））具有跨平台解决方案，出于此明确目的，该解决方案经常在F500企业中部署。

要考虑的事情...

1. 您的用户是否始终保持连接状态？如果是这样，将为您提供最佳的弹性基于VM的托管环境，当许多活动用户对LDAP施加挑战时，该托管环境可以灵活发挥作用
2. 您是否在多个物理数据中心中运行？考虑在AD服务之前进行地理负载平衡，以减少用户与系统之间的跳数
3. 此外，如果回答＃2是肯定的，那么请确保您设置了一些专用的网络资源来复制你的森林所描绘这里

如果用户受到限制的上行链路，从嘈杂的wifi中心进行连接等，请确保您的防火墙解决方案能够处理极高的重传速率。