PowerShell: 如何使用原生PowerShell解决访问SharePoint时的ADFS认证问题

说实话我的本命技能并不是PowerShell，而是SharePoint 2007/2010/2013/2016/Online 都有涉猎。

在SharePoint使用过程中会用到大量的PowerShell来管理，随着时间的推移，需要用PowerShell来处理SharePoint的场景越来越多。甚至是帮助客户解决一些使用PowerShell来进行SharePoint相关的批处理。

因为对于普通用户来讲是没有办法在SharePoint服务器上运行PowerShell脚本的，他们只能基于客户端（浏览器，PowerShell)来访问SharePoint资源。

那么在进行任何SharePoint操作之前最重要的一步就是认证，SharePoint有非常完善以及严格的认证授权机制。任何操作都必须先进行认证。

如果你的SharePoint配置的是Windows认证那么恭喜你，你可以省掉很多麻烦。不过如果你的SharePoint是基于ADFS认证的那么就比较麻烦了。之前做过一个基于.net的ADFS 认证库给公司内部使用，那么下面在提供一个PowerShell版本的。

SharePoint ADFS 2.0 认证的基本流程

详细的流程我就不一一赘述了，有兴趣可以去MSDN查一下。我们只来说说基本流程

1. 用户通过浏览器访问SharePoint
2. SharePoint检查当前用户是否已经认证，如果没有则跳转到登陆页面
3. 登陆页面会根据SharePoint配置的认证方式跳转到不同的登陆页面，ADFS则跳转到ADFS的默认登陆页面
4. 在ADFS认证服务器上当用户通过认证之后会颁发一个token然后回调SharePoint的 /_trust 页面
5. SharePoint根据这个认证过的token生成Cookie
6. 以后每一次请求带上这个Cookie, SharePoint 就会认为你已经认证过了

从上面几个基本步骤中我们可以看出，在默认情况下SharePoint配置了ADFS之后，SharePoint其实是通过Cookie（Cookie默认名字：FedAuth）作为session的保持的，并且SharePoint 本身不直接接受用户的用户名密码登陆。这也是很多脚本在遇到SharePoint ADFS认证方式都嗝屁的原因，而新手遇到这个问题往往都不知所措。

而且微软官方没有提供比较好用的解决方案。

模拟ADFS认证流程

既然我们已经搞清楚了ADFS认证的基本流程，那么其实我们只需用PowerShell模拟这个过程。获取到最后的 FedAuth Cookie,然后在以后的每次操作中带上这个Cookie。那么就能顺利通过SharePoint的认证检查。

废话不多说，那么我们怎么模拟这个流程呢？ 其实很简单。
PowerShell 5.0之后提供了很多使用的命令，比如今天我们要用到的 Invoke-WebRequest 这个命令就是模拟一个web请求，像浏览器一样。当然功能没有浏览器那么强大。
但是对于我们编写很多后台代码或者批处理脚本足够了，我们甚至都可以使用这个命令来爬网。

直接上代码吧：

$adfsresult=Invoke-WebRequest -Uri $SiteUrl -UseBasicParsing -UseDefaultCredentials -MaximumRedirection 100 -Headers @{
   "upgrade-insecure-requests"="1"}
# $SiteUrl 我们要请求的Site的地址
# -UseBasicParsing 制作基本解析，这样会更省资源
# -UseDefaultCredentials 使用当前用户登陆
# MaximumRedirection 100 最大从定向次数，一定要设置这个，SharePoint使用了很多302从定向在各个页面之间跳转
# @{"upgrade-insecure-requests"="1"} Http头，在没有认证成功之前要加上这个http头，否则SharePoint会直接返回401，而不是从定向到登陆页面

上面的步奏是模拟ADFS认证的整个过程，但是由于 Invoke-WebRequest 没有自动提交表单