小议 UAC 在 Windows Server 2008 上的作用
[ 2008/08/22 10:34 | by gOxiA ]
大家都知道微软发布的 Windows Vista 中包含了一个新的安全技术 - User Account Control(UAC,用户帐户控制),同样该技术也被包含在 Windows Server 2008 中。UAC 到目前为止还是备受争议,但是我个人已经很依赖这个安全特性,而且在实际操作中感觉越来越习惯,前提是 UAC 确实在安全方面起到了一定的作用。而今天提出这个议题的主要原因是因为我的日常工作经常涉及到 B/S 管理以及安全防护,要知道现在的“黑客”通过工具入侵一台没有经过防护措施的服务器是多么的轻而易举,一些 ITPro 们经常要检查系统是否存在新的漏洞,防止这些“黑客”有机可趁。在我所接触上百次的客户服务器安全事件中,70%以上都是由于未对服务器进行安全加固,“黑客”通过“WebShell”对系统进行入侵,之后“黑客”为所欲为,植入后门、木马等等。面对这些安全事件,实在令人头疼!这些客户服务器的运维人员的工作质量令人堪忧……
微软 Windows Server 2008 已经正式发布,IIS 7 的改进是非常之大,除了性能方面的提升,安全方面也得到了大大的提高。但是没有经过安全加固的 Web Server 同样很容易遭到“黑客”的入侵和破坏,再次同时使我联想到了 UAC 的作用,我一直在设想如果对 用于 Web 服务的 Windows Server 2008 进行了安全加固之后,开启 UAC 岂不是为系统加了把锁,更确切地讲是增加了一道安全防护墙。因为微软公司出于安全因素的原因,在设计 UAC 时并为加入命令行的支持,也就是说我们无法通过命令行来调用或干预 UAC 的操作,这就意味着如果当你通过命令行或使用 WebShell 调用某些命令时,一旦触发 UAC 那么命令结果一定是失败的。相信能避免不少安全事件的发生……
但是启用 UAC 也存在一些问题,如果一套 B/S 程序中触发了 UAC ,那么也将会被拦截,结果自然是程序运行失败,当然具体的兼容性还需要进行针对性的评估。
总之,根据我的个人工作经验,我相信对于大多数 Web 程序来说,开启 UAC 并不会对其造成影响,在 Web Server 上,特别是公共主机上开启 UAC 是非常有必要的。
最后,需要提到的一点是,在之前我已经提到 UAC 不支持命令行的调用及干预,所以在 Server Core 上 UAC 功能是无效的,即使你通过注册表启用了 UAC 功能,但实际上系统并未启用。到目前为止,微软仍未透露是否会在未来支持 UAC 在命令行中的调用及干预,但是从设计初衷来看,这个期望恐怕遥遥无期,一旦支持 UAC 的命令行支持,那等于形同虚设!
微软 Windows Server 2008 已经正式发布,IIS 7 的改进是非常之大,除了性能方面的提升,安全方面也得到了大大的提高。但是没有经过安全加固的 Web Server 同样很容易遭到“黑客”的入侵和破坏,再次同时使我联想到了 UAC 的作用,我一直在设想如果对 用于 Web 服务的 Windows Server 2008 进行了安全加固之后,开启 UAC 岂不是为系统加了把锁,更确切地讲是增加了一道安全防护墙。因为微软公司出于安全因素的原因,在设计 UAC 时并为加入命令行的支持,也就是说我们无法通过命令行来调用或干预 UAC 的操作,这就意味着如果当你通过命令行或使用 WebShell 调用某些命令时,一旦触发 UAC 那么命令结果一定是失败的。相信能避免不少安全事件的发生……
但是启用 UAC 也存在一些问题,如果一套 B/S 程序中触发了 UAC ,那么也将会被拦截,结果自然是程序运行失败,当然具体的兼容性还需要进行针对性的评估。
总之,根据我的个人工作经验,我相信对于大多数 Web 程序来说,开启 UAC 并不会对其造成影响,在 Web Server 上,特别是公共主机上开启 UAC 是非常有必要的。
最后,需要提到的一点是,在之前我已经提到 UAC 不支持命令行的调用及干预,所以在 Server Core 上 UAC 功能是无效的,即使你通过注册表启用了 UAC 功能,但实际上系统并未启用。到目前为止,微软仍未透露是否会在未来支持 UAC 在命令行中的调用及干预,但是从设计初衷来看,这个期望恐怕遥遥无期,一旦支持 UAC 的命令行支持,那等于形同虚设!
[经验技巧] 当终端服务超出了最大允许连接时
[ 2008/08/21 21:21 | by gOxiA ]
这一幕相信很多刚接触服务器运维,特别是经常需要远程登录到服务器进行管理的 ITPro 经常遇到的,出现这个问题的原因通常不外乎以下几点:
1、网络意外终端
2、程序意外关闭
3、非正常方式退出远程桌面
而以上问题出现的主要因素是因为我们通常使用的是远程桌面的管理模式而非应用模式,当然如果你激活了应用模式可以有效避免因上述操作而导致的终端服务器超出了最大允许连接,但是则需要额外的付出终端授权的费用。毕竟我们在某种情况下还是主要以管理为主。过去出现这个问题后唯一的解决办法就是重启服务器,或安装第三方的远程管理软件。
其实从 Windows Server 2003 开始 RDP 的客户端程序 - mstsc.exe 就提供了一个参数“/console”,使用该参数我们可以直接使用“控制台会话”,即大家常说的本地登录模式远程登录到已经超出连接的远端服务器上。
注意,“/console”并不适用于 Windows 2000 Server 。
在 Windows Vista 和 Windows Server 2008 上 RDP 及其客户端工具 mstsc.exe 都采用了最新版 v6.0,而“/console”参数也变更为“/admin”。
如需获取 mstsc.exe 的更多参数,可以在运行中键入“mstsc /?”来获取更多的参数信息。
[HOWTO] 解决 AutoEnrollment ID:13 警告
[ 2008/06/28 18:04 | by gOxiA ]
一台额外 DC 控制器,在 AD 中部署了证书服务之后,该额外 DC 控制器出现来源:AutoEnrollment,ID:13 的应用程序警告。参考:KB903220 ,地址:http://support.microsoft.com/kb/903220/zh-cn。发现域控制不隶属于 CERTSVC_DCOM_ACCESS 组。使用 ADUC 将 Domain Controllers 加入到 CERTSVC_DCOM_ACCESS 组,重新启动该额外 DC 控制器,问题解决。







