因为老大的要求,需要将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,文章总是会现在这里发布的。]
分类:
SharePoint研究
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· [AI/GPT/综述] AI Agent的设计模式综述