gOxiA=苏繁=SuFan Blog

HOWTO: 为 Office 365 配置 Active Directory 同步

        Office 365 提供的 Active Directory 同步（目录同步）功能，可实现组织内的本地目录服务与组织 Windows Azure AD 租户集成，这一举措将极大降低 IT 管理员的管理和维护任务，同时也向用户提供了更加简化的登录体验。

        默认情况下，当一个组织订阅了 Office 365，并将域名准备就绪后，就需要为用户添加账号，这是一项繁琐的工作，虽然在 Office 365 中也提供了批量添加用户的功能，但是对于那些已经在组织本地内实现目录管理的企业来说，使用 Office 365 的目录同步应该是最明智的选择。因为 Office 365 的目录同步功能可动态的将组织内的目录服务与云进行同步，这样可免去 IT 管理员重复添加账号信息的工作，尤其是可对账户密码进行统一的管理和维护，最终用户无需同时记录一个相同账户的两个密码。

        要实现目录同步其实非常简单，在 Office 365 管理中心内的用户和组管理中提供了路线化的实施向导，共计6个步骤：

1. 准备进行目录同步  
2. 安装目录同步工具  
3. 同步目录  
4. 验证目录同步  
5. 激活同步用户  
6. 管理目录同步

        在开始实施前，我们应当进行目录同步的需求准备工作，微软给出了准备目录同步的详细指导，http://technet.microsoft.com/zh-cn/library/jj151831.aspx，在文中我们需要注意的几点如下：

• 目录同步计算机必须加入 Active Directory，即成员服务器。  
• 目录同步计算机不能是域控制器  
• 目录同步计算机必须运行 Microsoft .NET Framework 3.x 和 4.x，虽然官方文档提示必须 3.x，但实际操作时 4.x 也是成功安装的关键。  
• 目录同步计算机 IE 浏览器版本必须是 IE10 或更高，虽然官方未提到这点，但如果低于 IE10 会发现无法正常执行部署。  
• 目录同步计算机必须运行 Windows PowerShell  
• 目录同步计算机必须位于访问受控制的环境中，官方文档中提示用户只有能够访问活动目录域控制器和其他敏感网络组件的用户才能访问运行目录同步工具的计算。

        综上所述，建议选择一台 Windows Server 2008 R2 Standard 服务器作为目录同步计算机，并安装上述要求安装或升级必须的软件。

        现在，我们可以进入 Office 365 管理中心的用户和组管理页面，在活动用户选项页面中点击 Active Directory 同步旁的设置链接，开始执行目录同步任务。

        首先，参考指导步骤1、2条检查准备工作是否就绪，然后通过步骤3，激活 Office 365 的目录同步功能。

        目录同步服务被激活后，强烈建立先访问 Office 365 Onramp 网站对目录同步计算机执行一次检查工作。可参考下面截图。

       执行检查向导的目的主要是为了保证当前目录同步计算机的软件符合其需求。在早些时候，因为相关软件版本不匹配导致的安装失败问题还是很常见的。

       现在，下载目录同步工具，进行安装。安装过程很简单，整个过程中向导会在目录同步计算机上安装 SQL Server Express，并创建一个用于目录同步所需的账号，安装完成后便可开始进行配置。需要注意的是，如果在安装过程中出现错误导致无法完成安装，只需要重新执行安装即可。在实际操作中发现，此类问题还是比较常见的。

        现在跟随向导完成后续的配置，这里需要准备好 Office 365 管理员的凭据以及企业内部活动目录的凭据。凭据验证通过，即实现将内部活动目录服务上的数据同步至云端。在这一系列步骤中，强烈推荐启用密码同步选项，这样用户本地账号密码即可与云端账号密码统一，但是在启用的同时也需要注意，因为云端密码策略要求比较高，必须是复杂强密码格式，所以如果本地账号密码不符合强密码要求，会导致同步失败。

        至此，Office 365 目录同步的安装和初始配置工作即告一段落！等待片刻就会在 Office 365 管理中心的用户和组中看到组织内部的账号同步过来了，之后就可以统一为这些用户账号分配许可证。此外我们还能利用目录同步工具的筛选功能，仅同步指定类别的账号。

HOWTO：删除 AD 内账号重复的 CN 名称

        近期 gOxiA 在公司 SBS 系统上的 Microsoft Baseline Configuration Analyzer 2.0 检测报告中发现了一条警告“One or more user accounts have duplicate CN names”大概的意思是说在我当前的 AD（活动目录）里发现一个或多个账号存在相同的 CN 名称。如下图所示：

        这要排查起来可老费时间和经理，还好利用 PowerShell 我们能够轻松的对 AD 进行筛选查询，为此登录 DC 服务器，到“管理工具”下找到“用于 Windows PowerShell 的 Active Directory 模块”并运行它，然后键入如下命令行：

        查询结果中我们能很轻松的找到重复的账号，如下图：

        然后打开 ADUC，在“查看”菜单下启用“高级功能”后，再查找这个账号，这样除了能搜索到重复的账号以外，还能通过账号属性下“对象”选项卡确定该账号存储的位置。

        确认这些账号的存储位置之后，便可以对其隶属性进行分析，以确定该删除哪个账号。

HOWTO:解决 ADWS ID1400 警告事件

        基于 Windows Server 2008 R2 的域环境，每次重启服务器后都能在“事件查看器”中看到 Active Directory Web Services 下有一警告事件：来源：ADWS；ID：1400；详细信息：Active Directory Web 服务找不到具有指定证书名称的服务器证书，需要证书才能使用 SSL/TLS 连接。若要使用 SSL/TLS 连接，请验证是否在此计算机上安装了来自受信任证书颁发机构（CA）的有效服务器身份验证证书。如下图所示：

        这是因为本地计算机账户缺少有效的域控制器类型证书，要解决 ADWS ID1400 警告事件，只需要使用 MMC 打开本地计算机账户证书，在“个人”证书下申请证书模板为“域控制器”的证书即可。

        最后重新启动 ADWS，警告事件消失！