因为老大的要求，需要将MOSS的Window认证改为较为友好的Form认证。因为这是一个很老的话题，所以懒得自己想，上网google了一下。这一下不要紧，发现网络上的教程，所用的数据源要不是text的，要不就是sql server上的，唯独没有AD的。看来还是要自己动手哇。
OK，让我们先了解一下升级的大致原理。
这是Memebership在整个应用结构中的位置。观察发现，Membership的位置位于较为底层，可以预见的是，很多具体的应用操作可以通过Membership实现过滤。
因为我们是使用的现成的AD组件，所以我们并不需要写什么代码，直接对web.config文件做一些修改即可，告诉MOSS该将取得的用户名与密码送到哪里去，然后获得一个布尔型的结果，既可以达到以前windows认证相同的效果了。
在这里，我们假设，你要对http://moss:8082站点进行form认证的升级。
注意，请在修改web.config文件之前做一下备份！
打开此文件，定位到<system.web>节点下，增加此节点
程序代码
并且在<system.web>的父级节点增加此节点
程序代码
<connectionStrings>
<add name="ADConnectionString"
connectionString="LDAP://yourcompany.com/CN=Users,DC=YOURCOMPANY,DC=com" />
</connectionStrings>
打开IIS，打开管理中心站点的属性查看管理中心的文件目录
进入文件目录，按照步骤一的改法再次修改一遍web.config。
这里要注意的几个问题:
一个就是attributeMapUsername属性，必须赋上SAMAccountName（注意大小写），否则会在添加用户的时候出现"找不到完全匹配的项目"的错误。如下图
另外一个问题就是关于LDAP配置，你需要根据你自己域树的形状设定LDAP地址。
最后一个是关于设定应用程序和管理中心的web.config文件。为什么非要修改管理中心的web.config文件呢？管理中心中有时候必须要到域里取用户的信息，比如设定站点集的管理员。如果你还是用的域里的信息，那么会生成类似于下面这种形式的登录名:YOURDOMAIN\YOURNAME,而你用的Form认证，会生成YOURPROVIDERNAME/YOURNAME格式的登录名。显然，这两种登录名是不一样的。这也是为什么在更换到Form认证以后，所有的角色会失效的原因。
好了，现在web.config文件设定完毕了。
进入管理中心-》应用程序管理-》应用程序安全性 -》验证提供程序 。选择8082端口的应用程序。
然后按照你设定的Provider名称填入。
注意：此时数据虽然还是AD中的，但是因为映射改变，角色也就失效了，要在“网站集管理员”中重新设定管理员，并且你的站点里也要重新分配员工到角色上，并且一个可爱的功能没了（添加所有已验证用户）。
大功告成，现在登陆看看，记得，此时只要用户名就可以了，域名就不要填了：）
文章来源:http://www.windwhisper.cn/default.asp?id=14 [来自于我的www.windwhisper.cn，文章总是会现在这里发布的。]
OK，让我们先了解一下升级的大致原理。
这是Memebership在整个应用结构中的位置。观察发现，Membership的位置位于较为底层，可以预见的是，很多具体的应用操作可以通过Membership实现过滤。
因为我们是使用的现成的AD组件，所以我们并不需要写什么代码，直接对web.config文件做一些修改即可，告诉MOSS该将取得的用户名与密码送到哪里去，然后获得一个布尔型的结果，既可以达到以前windows认证相同的效果了。
在这里，我们假设，你要对http://moss:8082站点进行form认证的升级。
注意，请在修改web.config文件之前做一下备份！
一，修改8082文件夹下的web.config文件
打开此文件，定位到<system.web>节点下，增加此节点
程序代码 <membership defaultProvider="MembershipADProvider">
<providers>
<add
name="MembershipADProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web,Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ADConnectionString"
connectionUsername="administrator"
connectionPassword="your password" attributeMapUsername="SAMAccountName" enableSearchMethods="true"/>
</providers>
</membership>
<providers>
<add
name="MembershipADProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web,Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ADConnectionString"
connectionUsername="administrator"
connectionPassword="your password" attributeMapUsername="SAMAccountName" enableSearchMethods="true"/>
</providers>
</membership>
并且在<system.web>的父级节点增加此节点
程序代码<connectionStrings>
<add name="ADConnectionString"
connectionString="LDAP://yourcompany.com/CN=Users,DC=YOURCOMPANY,DC=com" />
</connectionStrings>
二，修改管理中心的web.config文件
打开IIS，打开管理中心站点的属性查看管理中心的文件目录
进入文件目录，按照步骤一的改法再次修改一遍web.config。
这里要注意的几个问题:
一个就是attributeMapUsername属性，必须赋上SAMAccountName（注意大小写），否则会在添加用户的时候出现"找不到完全匹配的项目"的错误。如下图
另外一个问题就是关于LDAP配置，你需要根据你自己域树的形状设定LDAP地址。
最后一个是关于设定应用程序和管理中心的web.config文件。为什么非要修改管理中心的web.config文件呢？管理中心中有时候必须要到域里取用户的信息，比如设定站点集的管理员。如果你还是用的域里的信息，那么会生成类似于下面这种形式的登录名:YOURDOMAIN\YOURNAME,而你用的Form认证，会生成YOURPROVIDERNAME/YOURNAME格式的登录名。显然，这两种登录名是不一样的。这也是为什么在更换到Form认证以后，所有的角色会失效的原因。
三，管理中心中配置
好了，现在web.config文件设定完毕了。
进入管理中心-》应用程序管理-》应用程序安全性 -》验证提供程序 。选择8082端口的应用程序。
然后按照你设定的Provider名称填入。
注意：此时数据虽然还是AD中的，但是因为映射改变，角色也就失效了，要在“网站集管理员”中重新设定管理员，并且你的站点里也要重新分配员工到角色上，并且一个可爱的功能没了（添加所有已验证用户）。
大功告成，现在登陆看看，记得，此时只要用户名就可以了，域名就不要填了：）
文章来源:http://www.windwhisper.cn/default.asp?id=14 [来自于我的www.windwhisper.cn，文章总是会现在这里发布的。]
