微软于本周，对Windows登录验证机制，实施了重大调整，直接封堵了一种被广泛使用的身份验证方式，此举动及了所有仍受支持的Windows 10版本，还波及了所有仍受支持的Windows 11版本。这一安全策略变更，是由官方主动发起的，已经致使部分用户不能正常获取系统预览版本，在开发者社区引发了广泛关注，还引发了广泛讨论。
官方封堵验证方式
微软在本周正式宣告，已达成对Windows PC登录验证方式的封堵事项。该公司清晰表明，这是一回主动的安全策略调整，并非系统漏洞亦非意外事故。所有仍处于支持周期之内的Windows 10以及Windows 11系统，皆受到此次变更的影响。
微软于官方说明里详尽地阐述了调整的原因，着重表明这样做的目的是用以提升用户账户的安全性，该公司觉得原本的验证方式存在着会被滥用的风险，有可能被攻击者借助来绕开正常的安全检查機制，进而对用户的数据构成潜在的威胁。
预览版本下载受阻
在这同一时间，Windows Insider项目的用户察觉到，最新的预览版本涌现出下载失败的状况 ，涉及到的版本有Windows 11 Canary通道的28020.1611 ，还有Windows Server预览版本29531 ，当用户试着去下载ISO文件的时候，系统给出了错误提示，表明其IP地址被封锁了。
该问题，最早是由用户ChronoVore，在微软官方论坛提出，从而进行反馈的。这个用户宣称，自己使用的是Google Fiber网络服务，并且并没有启动虚拟专用网络，或者动用任何匿名代理工具。错误信息里头，包含特定代码，也就是715 - 123130和b64dd3c8 - ed16 - 4d46 - 87ac - a871691f1c41，这些代码指向的IP段，被系统予以识别，进而遭到拦截。
开发者工具遭遇拦截
制作知名Windows启动盘的工具Rufus，同样受到了此次变更的影响，该工具的开发者是Pete Batard，他证实，Rufus所依赖的Fido脚本，已不能够正常运行了，这致使工具获取Windows ISO文件的功能失效，Batard觉得微软或许对预览版本的下载机制作出了调整。
Batard于GitHub相关讨论里剖析表明，微软好像正主动去识别且阻拦Fido脚本的下载请求，鉴于该脚本是开源项目，技术层面实施检测并非困难，不过得微软方面有明确意图以及主动介入方可达成精准封锁，类似情形在历史中曾多次出现。
检测机制疑似针对性
Batard作了进一步的推测，微软在此次进行调整，其目标有可能是期望去引导用户运用官方媒体创建工具也就是MCT来获取Windows ISO，第三方脚本以及工具绕过了官方下载流程，这可能会被视作是对服务器资源的非授权使用，进而促使微软去采取技术手段展开干预。
对于开发者社区而言，此反应呈现出不一致的状况，一部分开发者秉持着这样的想法，微软具备保护自身服务器以及下载渠道的权利，其目的在于保证流量借助官方工具来实施管理与分发，然而，另外一些观点却表明，诸如Rufus这类工具为一部分用户给予了便利，特别是当官方工具没办法满足特定需求之际，微软的此番举动有可能对用户体验产生影响。
波及范围持续扩大
于微软官方反馈中心，有更多用户汇报碰到相同问题。有用户表明，此下载异常状况好像已波及所有Windows Insider预览通道，并非只局限于先前报道的Canary版本。不管是开发者版本还是服务器版本，都出现了IP被封锁的提示。
ChronoVore用户的这个事例可不是单独存在的例子，有好些用户都着重表示自己网络状况处于正常状态，没有运用任何匿名服务，然而还是被系统判定成“并非所宣称的身份”，这说明微软的检测机制或许是依据更复杂些的算法，针对来自特定ISP或者IP段的请求施行更为严格的审查。
历史问题再次重演
这可不是微软头一回针对第三方下载工具施行限制举措，回溯以往，诸如Rufus这类工具，曾因微软对下载策略加以调整，从而多次出现短暂失效的状况，开发人员接着借助更新脚本达成适配，此次事件的特别之处在于，微软特意把它说成是“特意施行的变动”，还阐释了安全方面的考虑因素。
迄今还没有任何迹象能表明微软马上会恢复被封锁的IP的访问权限，开发者以及用户正等待微软官方给出进一步说明，或者自己找寻替代解决方案，Rufus开发者宣称会密切留意事态发展情况，并且评估后续应对策略。
各位读者，当你运用Windows预览版本之际，或者使用第三方下载工具之时，有没有遭遇过IP被封锁的状况？欢迎于评论区去分享你的经历，点赞以便让更多碰到同样问题的朋友能够看到，并且请把本文转发给那些可能有需要的IT爱好者。
