如何配置Windows Server2008 ADFS麻烦告诉我

这项新功能甚至可以实现完全不同的两个网络或者是组织之间的帐户以及应用程序之间的通讯。 要理解ADFS的工作原理，可以先考虑活动目录的工ADFS是Windows Server 2008 *** 作系统中的一项新功能，它提供了一个统一的访问解决方案，用于解决基于浏览器的内外部用户的访问。这项新功能甚至可以实现完全不同的两个网络或者是组织之间的帐户以及应用程序之间的通讯。要理解ADFS的工作原理，可以先考虑活动目录的工作原理。当用户通过活动目录进行认证时，域控制器检查用户的证书。当证明是合法用户后，用户就可以随意访问Windows网络的任何授权资源，而无需在每次访问不同服务器时重新认证。ADFS将同样的概念应用到Internet。我们都知道当Web应用需要访问位于数据库或其他类型后端资源上的后端数据时，对后端资源的安全认证问题往往比较复杂。现在可以使用的有很多不同的认证方法提供这样的认证。例如，用户可能通过RADIUS(远程拨入用户服务认证)服务器或者通过应用程序代码的一部分实现所有权认证机制。这些认证机制都可实现认证功能，但是也有一些不足之处。不足之一是账户管理。当应用仅被企业自己的员工访问时，账户管理并不是个大问题。但是，如果企业的供应商、客户都使用该应用时，就会突然发现用户需要为其他企业的员工建立新的用户账户。不足之二是维护问题。当其他企业的员工离职，雇佣新员工时，用户还需要删除旧的账户和创建新的账户。ADFS能为您做什么?如果用户将账户管理的任务转移到他们的客户、供应商或者其他使用Web应用的人那里会是什么样子哪? 设想一下， Web应用为其他企业提供服务，而用户再也不用为那些员工创建用户账户或者重设密码。如果这还不够，使用这一应用的用户也不再需要登录应用。那将是一件多么令人兴奋的事情。ADFS需要什么?当然，活动目录联合服务还需要其它的一些配置才能使用，用户需要一些服务器执行这些功能。最基本的是联合服务器，联合服务器上运行ADFS的联合服务组件。 联合服务器的主要作用是发送来自不同外部用户的请求，它还负责向通过认证的用户发放令牌。另外在大多数情况下还需要联合代理。试想一下，如果外部网络要能够和用户内部网络建立联合协议，这就意味着用户的联合服务器要能通过Internet访问。但是活动目录联合并不很依赖于活动目录，因此直接将联合服务器暴露在Internet上将带来很大的风险。正因为这样，联合服务器不能直接和Internet相连，而是通过联合代理访问。联合代理向联合服务器中转来自外部的联合请求，联合服务器就不会直接暴露给外部。另一ADFS的主要组件是ADFS Web代理。Web应用必须有对外部用户认证的机制。这些机制就是ADFS Web代理。 ADFS Web代理管理安全令牌和向Web 服务器发放的认证cookies。在下面的文章中我们将带领大家通过一个模拟的试验环境来一起感受ADFS服务带给企业的全新感受，闲言少叙，我们下面就开始ADFS的配置试验。第1步：预安装任务要想完成下面的试验，用户在安装ADFS之前先要准备好至少四台计算机。1)配置计算机的 *** 作系统和网络环境使用下表来配置试验的计算机系统以及网络环境。2)安装 AD DS用户使用Dcpromo工具为每个同盟服务器(FS)创建一个全新的活动目录森林，具体的名称可以参考下面的配置表。3)创建用户帐户以及资源帐户设置好两个森林后，用户就可以通过“用户帐户和计算机”(Active Directory Users and Computers )工具来创建一些帐户为下面的试验做好准备。下面的列表给出了一些例子，供用户参考：4)将测试计算机加入到适当的域按照下表将对应的计算机加入到适当的域中，需要注意的是将这些计算机加入域前，用户需要先将对应域控制器上的防火墙禁用掉。第2步：安装 AD FS 角色服务，配置证书现在我们已经配置好计算机并且将它们加入到域中，同时对于每台服务器我们也已经安装好了ADFS组件。1)安装同盟服务两台计算机上安装同盟服务，安装完成后，这两台计算机就变成了同盟服务器。下面的 *** 作将会引导我们创建一个新的信任策略文件以及SSL和证书：点击Start ，选择 Administrative Tools ，点击 Server Manager。右击 Manage Roles， 选中Add roles 启动添加角色向导。在Before You Begin 页面点击 Next。在 Select Server Roles 页选择 Active Directory Federation Services 点击Next 。在Select Role Services 选择 Federation Service 复选框，如果系统提示用户安装 Web Server (IIS) 或者 Windows Activation Service (WAS) 角色服务，那么点击 Add Required Role Services 添加它们，完成后点击 Next 。在 Choose a Certificate for SSL Encryption 页面点击 Create a self-signed certificate for SSL encryption, 点击 Next 继续，在 Choose Token-Signing Certificate 页面点击Create a self-signed token-signing certificate, 点击 Next. 接下来的Select Trust Policy 页面选择 Create a new trust policy,下一步进入 Select Role Services 页面点击 Next 来确认默认值。

在Office 365原有静态密码认证基础上增加第二重保护，宁盾双因素认证结合ADFS联合认证，通过提供多种形式的一次性动态令牌实现双因素认证，提升账号安全，避免因密码共享/泄露或破解造成的账号被盗用，一旦发生安全事件也可追责到个人，加强用户登录认证审计。

具体Office365双因素认证实现流程是：员工访问office365时，首先跳转到ADFS登录页面进行域身份验证。验证成功后进入动态密码验证页面。ADFS服务器将动态密码身份信息传递给宁盾认证服务器进行验证。验证通过，跳转回office365。至此双因素认证登录过程完成。

功能迭代是每个产品同学日常工作的一部分。下边就来梳理一下如何做好一次功能的迭代。

功能迭代定义：在原有功能基础上，再不改变现有功能主逻辑的前提下，针对该功能已知的问题，进行优化和补全。

功能迭代原动力当然是需求，来源方式分类如下：

方式1： 来自用户、客户、业务的反馈。

方式2： 来自数据分析。需要监测用户的每条使用路径是否通畅，对于其中不通的地方加以进一步查找原因和分析。

具体实际中发生的场景如下：

场景1：之前产品设计时未考虑到的场景，多为异常流程。 举个栗子：某同学在设计客户端超时自动锁屏功能时，用户使用账号、密码来解锁。但是未考虑通过微信扫码登录的用户，不会强制设置密码，换言之，微信扫码登录的用户是可以没有密码的，那么这类用户无法通过账号、密码方式来解锁了。

场景2：与该功能强耦合的功能更新了，但该功能未随之更新。 举个栗子：随着产品发展，陆续支持同钉钉、AD、ADFS、OA系统等同步创建用户功能，并且支持扫码登录、统一身份认证等登录方式。之前设计的超时自动锁屏功能，就需要跟随用户登录方式支持更多的解锁方式，而不是简单的使用账号、密码来解锁。

场景3：业务发展或用户使用习惯带来的更多的功能使用场景。 举个栗子：随着产品发展，用户越来越多，用户使用的支付方式也越来越多，微信、支付宝、银联等，那么支付功能就要支持更多的支付方式来扩大支付功能的使用场景。

需要防止的误区：功能上线后，如果评价不好或没人使用，一定要优先复盘该功能的核心场景而不是急着继续拓展功能。举个栗子：公司新开发了一个功能可以统计用户发出去文件阅读时长等数据，上线后无人问津，这个时候需要退回到核心场景，用户是否真的需要文件分发后的数据反馈？而不是急着去做评论、点赞等拓展功能。

Step 1：；分析清楚功能现状与逻辑

找到用户：产品对应用户模型中的哪几类用户会用到这个页面/功能？

流程：这几类用户使用流程是怎样的？

逻辑：产品功能的底层逻辑（业务流程）是怎样的？

Step 2：现在功能出现了什么问题？

现象：哪些用户出了什么问题？

原因：为什么会出问题呢？

影响面：出现问题的pinl和受影响的用户量是怎么样的？

Step 3：如何解决这些问题？

关键点：在业务流程中，找到最关键因素。

多种方案：有没有更多方案？还是只有一种方案？

难度评估：开发难度与效果的选择。可以用四象限法来评估，难度最小，效果最好的。逐步迭代方式。

Step 4：结果如何评定？

考核指标：用什么指标来评估产品的表现？

数据对比：前后的数据对比是如何的？

PS：做功能迭代的时候，往往是迫于一个第三方的压力，产品内心其实并不认同，那么通过数据对比产品可以验证自己的想法的正确性，从而对于第三方不适宜要求进行反击。

---