我有一个客户,他们的员工完全是由使用苹果和Windows 7个人电脑/笔记本电脑的远程员工组成的。
用户目前没有针对某个域进行身份validation,但是由于以下几个原因,组织希望朝这个方向移动。 这些是公司拥有的机器,公司寻求对帐户停用,组策略和一些轻量级数据丢失防护(禁用远程媒体,USB等)进行一些控制。他们担心需要VPN身份validation才能访问AD会很麻烦,特别是在远程机器上被终止的员工和caching凭证的交集处。
组织中的大多数服务都是基于Google的(邮件,文件,聊天等),因此唯一的域服务是DNS和思科ASA VPN的身份validation。
客户想了解为什么将域控制器暴露给公众是不可接受的。 另外,分布式远程员工更容易接受的域结构是什么?
编辑:
Centrify正在用于less数Mac客户端。
我发布这个答案主要是因为每个人都有基于经验,第三方信息,传闻和部落知识的自己的“教育意见”,但这更多的是来自微软的“直接”引用和阅读清单。 我使用了引号,因为我确定他们没有正确地过滤员工提出的所有意见,但是如果您是直接从Microsoft获得authoritative
引用,这应该是有帮助的。
顺便说一句,我也认为这是非常容易的说DOMAIN CONTROLLER == ACTIVE DIRECTORY,情况并非如此。 AD FS代理和其他方式(OWA,EAS等基于表单的身份validation)提供了一种将AD自身“公开”到Web的方式,以允许客户至less尝试通过AD进行身份validation,而无需公开DC。 去某人的OWA网站,并尝试login和广告将获得authentication请求在后端DC,所以AD技术上“暴露”…但是通过SSL安全,并通过Exchange服务器代理。
在Windows Azure虚拟机上部署Windows Server Active Directory的准则
在你走之前“Azure不是AD”…你可以在Azure虚拟机上部署ADDS。
但是要引用相关的部分:
切勿将STS直接暴露给互联网。
作为安全的最佳实践,将STS实例放置在防火墙之后,并将其连接到公司networking,以防止暴露于Internet。 这很重要,因为STSangular色会发出安全令牌。 因此, 他们应该被视为与域控制器同等级别的保护。 如果STS受到威胁,那么恶意用户就有能力发出访问令牌,这些令牌可能包含他们select的依赖方应用程序和其他信任组织中的STS。
ergo …不要将域控制器直接暴露给互联网。
Active Directory – AD LDS的UnicodePwd之谜
将域控制器暴露给Internet通常是不好的做法,无论这种暴露是直接来自生产环境还是通过外围networking。 自然的select是放置Windows Server 2008服务器,并在外围networking中运行Active Directory轻型目录服务(AD LDS)angular色。
活动目录即服务? Azune暗示,Intune在云托pipe的AD未来中扮演着重要angular色
最终,没有什么很好的“短”的答案来达到摆脱AD服务器的目的,换来Azure的替代品。 虽然微软在允许客户在Azure的Server 2012和2008 R2服务器上托pipeActive Directory域服务,但他们的实用性与您为员工所能达到的VPN连接一样好。 DirectAccess虽然是一个非常有前途的技术,但由于自身的不利局限,双手紧密相连。
使用单点login和Windows Azure虚拟机部署AD DS或AD FS和Office 365
域控制器和AD FS服务器决不能直接暴露在Internet上,只能通过VPN访问
活动目录(AD)不是为这种部署而devise的。
产品devise中使用的威胁模型假设“防火墙后”部署,其中一些敌对angular色在networking边界过滤。 虽然您可以强化Windows Server以暴露于公共networking,但Active Directory的正确运行需要一个安全的姿势,这个姿势显然比面向公众networking的主机更加松懈。 为了使AD正常工作,必须从域控制器(DC)中暴露出许多服务。
Zoredache在评论中的build议,特别是像OpenVPN那样运行的机器级服务(带证书authentication),可能是一个很好的select。 正如其他人所说的,DirectAccess正是你所需要的,除了它没有你想要的跨平台支持。
顺便说一句:我已经玩弄了使用基于证书的传输模式IPSEC将AD直接暴露给Internet的想法,但从来没有真正有时间去做。 微软在Windows Server 2008 / Vista时间框架中进行了改变,据说这样做是可行的,但我从来没有真正行使过。
别人都说了什么 我对克里斯托弗·卡雷尔(Christopher Karel)提到的暴力尝试特别紧张。 最后一个Def Con的演讲是关于这个话题的:
所以你认为你的域控制器是安全的?
JUSTIN HENDRICKS安全工程师,MICROSOFT
域控制器是一个组织的皇冠上的gem。 一旦他们下降,领域的一切都会下降。 组织竭尽全力保护他们的域控制器,然而他们经常无法正确保护用于pipe理这些服务器的软件。
本演示文稿将介绍通过滥用组织部署和使用的常用pipe理软件来获取域pipe理员的非传统方法。
Justin Hendricks在Office 365安全团队工作,参与红色团队,渗透testing,安全研究,代码审查和工具开发。
我相信你可以find很多其他的例子。 我正在寻找关于域控制器和黑客的文章,希望能够得到关于如何迅速findDC的说法等,但我认为现在就可以做到。
如果你想说服pipe理层,一个好的开始将是:
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
我相信你可以在这个问题上鼓吹一些微软的文档,所以就是这样。 除此之外,你可以说明这样一个举措的危害,这个方面是:
A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.
caching的凭据就是 – caching。 他们工作的本地机器,当它无法连接到域 ,但如果该帐户被禁用,他们不会为任何networking资源(svn,vpn,smb,fbi,cia等),所以他们不必担心。 另外请记住,用户已经拥有对本地机器上的configuration文件文件夹中的任何文件(以及可能的可移动介质)的全部权限,因此禁用了凭据,或者他们不能根据该数据做他们想做的事情。 一旦重新连接到networking,它们也不能用于本地机器。
您是指Active Directory或域控制器提供的服务,如LDAP? 如果是这样的话,为了进行身份validation和目录查询,LDAP通常是安全的,但是只要closuresWindows防火墙(或者打开所有需要的端口 – 在这个例子中是同样的东西)可能会导致严重的问题。
AD不能真正pipe理 Mac,所以需要一个独立的解决scheme(比如OS X Server)。 你可以join一个Mac到一个域,但是这只不过是让他们用networking证书进行authentication,把域pipe理员设置成mac上的本地pipe理员等。没有组策略。 MS试图违背SCCM的新版本,声称能够将应用程序部署到Mac和* nix盒,但我还没有看到它在生产环境。 我也相信你可以configurationMAC连接到OS X服务器,它将validation你的AD目录,但我可能是错的。
也就是说,可以devise出一些创造性的解决scheme,比如Evanbuild议使用OpenVPN作为服务,并且在该员工离开的时候禁用机器证书。
这听起来像一切都基于谷歌,所以谷歌是作为你的LDAP服务器? 我会build议我的客户保持这种方式,如果可能的话。 我不知道您的业务的性质,但对于基于Web的应用程序(如git或redmine服务器),即使在内部设置可以使用OAuth进行身份validation,也可以利用Google帐户进行身份validation。
最后,像这样的道路战士设置几乎需要一个VPN才能成功。 一旦机器进入办公室并进行configuration(或通过脚本进行远程configuration),他们需要一种接收configuration更改的方法。
除了VPN之外,Mac还需要一个单独的pipe理方法,但是他们不再制造真正的Mac服务器太糟糕了,但是他们在上次检查时确实在OS X Server中有一些体面的策略实现(几年前)。
不幸的是,DirectAccess仅在Win7 +企业版上可用,因为它是为您的请求量身定制的。 但不知道你的版本,看到你有MacOS,这是行不通的。
/编辑 – 看起来像一些第三方声称,他们有DA客户端的Unices: http : //www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp
有可用的MDM解决scheme可以满足您的需求; 我们正在将其中一个(MAAS360)滚动到处于类似位置的客户端。
这显然是一个重大的安全风险。 此外,它可能不会像你想的那样工作。 如果Internet上的随机用户能够尝试login到您的AD环境,则所有用户都将被locking的可能性非常大。 永远。 并且取消locking要求意味着对于简单的密码进行暴力检查变得非常容易。
更重要的是,在不使AD服务器可以直接访问的情况下,实现目标(最终用户使用域凭据login到笔记本电脑)应该没有问题。 也就是说,Windows机器可以caching最后的X个成功login,以便在断开连接时可以使用相同的凭据。 这意味着最终用户可以login并执行有用的工作,而无需触摸您的AD服务器。 他们显然需要利用VPN连接到其他主要企业资源,并且可以同时刷新AD / GPO设置。
Ewwhite,
你的问题是非常有效的,值得仔细审查。
所有的安全专业人员都可以在任何networking资源前面推荐安全层,包括SPI防火墙,IDS,基于主机的防火墙等。如果可能的话,您应该总是使用像ISA(现在的TMG)这样的代理外围网关防火墙。
也就是说,Microsoft Active Directory 2003+没有公开透露任何主要漏洞。 LDAP技术和它的散列algorithm通常是非常安全的。 如果SSL VPN运行OpenSSL并且容易受到冲击,那么它可以说比SSL VPN更安全。
我会提醒5件事情:
关注面向networking的其他服务,如terminal服务器,DNS服务,CIFS,尤其是IIS,其安全logging非常糟糕。
将LDAPS与安全证书一起使用可避免通过电报传递明文文本域凭据。 安装证书服务后,会自动发生这种情况(使用PKI的单独机器)
在接口上放一个数据包嗅探器,观察你的stream量,修改任何明文密码,因为防火墙与否,如果你不使用VPN或LDAPS,一些旧系统会发送明文密码。
知道MITM攻击可以强制本地身份validation机制降级并将密码暴露给较弱的NTLM身份validation。
请注意可能仍存在的一些用户枚举漏洞。
也就是说,活动目录在安全方面有很好的logging。 此外,MS活动目录不存储密码,只有散列,这也可以减轻妥协的严重性。
您可以从更加无缝的安全基础结构中受益,您不必设置特殊的DNS服务器或使用domain.local,并且可以在公共因特网(如domain.com)上使用您的实际域。
在我的专业观点中,公开部署Active Directory等安全技术会带来实质性好处,其他技术(如Exchange,DNS和Web服务器)不提供任何好处和风险。
注意:如果您部署Active Directory,它将包含一个DNS服务器。 是一定要禁用您的DNS服务器recursion(默认情况下启用),否则您将绝对参与拒绝服务攻击。
干杯,
布赖恩
戴尔(通过购买Quest(通过购买Vintela))有一个跨平台的解决scheme,为了达到这个目的 ,F500企业经常部署这个解决scheme。
要考虑的事情…
并确保您的防火墙解决scheme能够处理极高的重传速率,如果您的用户使用节stream上行链路,从嘈杂的无线中心连接等。