一切福田,不離方寸,從心而覓,感無不通。

出现身份验证错误,要求的函数不受支持(这可能是由于CredSSP加密Oracle修正)

问题描述: 从5月8\9日开始客户端Win10\WinSer2016突然无法访问测试环境下所有远程Win Ser2012/16资源,提示"出现身份验证错误。要求的函数不受支持… 这可能是由于CredSSP加密Oracle修正…" Win7中英文版本分别提示"发生身份验证错误。要求的函数不受支持"或"An authentication error has occurred and the required function is not supported" 问题截图: Win7报错截图: 具体信息: 远程桌面连接报错: 出现身份验证错误。要求的函数不受支持 远程计算机:*.*.*.* 这可能是由于CredSSP加密Oracle修正。 要了解详细信息,请访问https://go.microsoft.com/fwlink/?linkid=866660 问题排查: 根据提示我们访问https://go.microsoft.com/fwlink/?linkid=866660 发现是因为CVE-2018-0886 的 CredSSP 更新导致该问题的发生。简单了解下CredSSP: 凭据安全支持提供程序协议 (CredSSP) 是处理其他应用程序的身份验证请求的身份验证提供程序。 CredSSP 的未修补版本中存在远程代码执行漏洞。 成功利用此漏洞的攻击者可以在目标系统上中继用户凭据以执行代码。任何依赖 CredSSP 进行身份验证的应用程序都可能容易受到此类攻击。 此安全更新通过更正CredSSP在身份验证过程中验证请求的方式来修复此漏洞。 解决方法: 修改本地组策略: 计算机配置>管理模板>系统>凭据分配>加密Oracle修正 选择启用并选择"易受攻击"。 易受攻击–使用CredSSP的客户端应用程序将通过支持回退到不安全的版本使远程服务器遭受攻击,但使用CredSSP的服务将接受未修补的客户端。 English: Group Policy ->Computer Configuration->Administrative Templates->System->Credentials Delegation>Encrypted Oracle Remediation change to Vulnerable Vulnerable – Client applications that use CredSSP will expose the remote servers to attacks by supporting fallback to insecure versions, and services that use CredSSP will accept unpatched clients. 步骤如下: 1.打开本地组策略: 2.依次展开计算机配置>管理模板>系统>凭据分配>加密Oracle修正 […]

龙生   22 Dec 2018
View Details

在.Net中跑RocketMQ_入门篇(下)

上一篇讲了如何再控制台将RocketMQ跑起来,本篇讲解,在asp.net mvc种跑起来,含(发布、订阅)。 因篇幅过长,本次将不挨个贴源码,直接展示目录,根据上一篇文章,进行相应的调整即可。 1、新建一个类库,将MQ公共部分提出来(源码在入门篇1中有讲解和截图): 如: 此时需要注意的有两点: (1)在RocketMQClientManager中,尽量将IRocketMQManager做成单例,避免每发一次消息,就实例化一个对象造成资源浪费。 (2)经测试,在RocketMQClientManager中发送消息时,遇到并发可能会存在消息丢失问题,防止消息丢失,可以在发布的时候,进行加锁处理。 2、在asp.net mvc 项目中配置MQ信息(需要在App_Data中修改RocketMQ的相应配置,入门篇1中有讲解)。 3、在asp.net mvc Global种添加初始化RocketMQ和订阅代码(按Tag进行订阅,也可订阅多有的Tag): 注意:FarseerBootstrapper.Create().Initialize(); //必须注册MQ服务,否则运行会抛出,未注册MQ服务啥。 4、接下来可以在控制器调用RocketMQ,进行测试(发布消息的Tag为BootsShuTestTag,消费可以根据指定的Tag进行消费): 发布、订阅运行结果: 注意、注意、注意: 1.需要将项目统一编译成X64、并且将项目寄宿到IIS,里边即可正常运行。在VS里边运行,是跑不起来的! 2.作者不推荐在服务端进行订阅,如果在IIS上运行,则可以将订阅模块提出来写成windows服务。 大家根据自己的业务场景自行甄别及其使用。 以上如有不对的,可以拍砖,相互学习,共同进步。 欢迎加入.NET CORE/ASP.NET CORE 技术交流群,我们期待你的加入。 群号:702566187   from:https://blog.csdn.net/weixin_37207795/article/details/81023914

龙生   22 Dec 2018
View Details

在.Net中跑RocketMQ_入门篇(上)

下面我将为大家介绍一款支持.NET端的RocketMQ。大名为:Farseer.Net.MQ.RocketMQ。 支持.Net Framework 4.5和.NetStandard 2.0 1、先创建一个.Net Framework的控制台,热热手。 2、通过Nuget安装相应组件。 Install-Package Farseer.Net.MQ.RocketMQ -Version 2.0.1 Install-Package Farseer.Net.Configuration 3、将ONSClient4CPP放到项目根目录: 如: 3.1、 3.2、 4、新建启动模块:PushModule: 如: 5、在我们创建的控制台中,编写RocketMQ代码: 如: 6、将项目改为X64。 7、修改App_Data下的Farseer.Net.josn(注意:程序运行,会自动生成改json配置文件) 8、运行控制台,能跑起来了吧! 欢迎加入.NET CORE/ASP.NET CORE 技术交流群,我们期待你的加入。 群号:702566187   from:https://blog.csdn.net/weixin_37207795/article/details/81023757

龙生   22 Dec 2018
View Details

分布式系统事务一致性解决方案

开篇 在 OLTP 系统领域,我们在很多业务场景下都会面临事务一致性方面的需求,例如最经典的 Bob 给 Smith 转账的案例。传统的企业开发,系统往往是以单体应用形式存在的,也没有横跨多个数据库。我们通常只需借助开发平台中特有数据访问技术和框架(例如 Spring、JDBC、ADO.NET),结合关系型数据库自带的事务管理机制来实现事务性的需求。关系型数据库通常具有 ACID 特性:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。 而大型互联网平台往往是由一系列分布式系统构成的,开发语言平台和技术栈也相对比较杂,尤其是在 SOA 和微服务架构盛行的今天,一个看起来简单的功能,内部可能需要调用多个“服务”并操作多个数据库或分片来实现,情况往往会复杂很多。单一的技术手段和解决方案,已经无法应对和满足这些复杂的场景了。 分布式系统的特性 对分布式系统有过研究的读者,可能听说过“CAP 定律”、“Base 理论”等,非常巧的是,化学理论中 ACID 是酸、Base 恰好是碱。这里笔者不对这些概念做过多的解释,有兴趣的读者可以查看相关参考资料。CAP 定律如下图: 在分布式系统中,同时满足“CAP 定律”中的“一致性”、“可用性”和“分区容错性”三者是不可能的,这比现实中找对象需同时满足“高、富、帅”或“白、富、美”更加困难。在互联网领域的绝大多数的场景,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即可。 分布式事务 提到分布式系统,必然要提到分布式事务。要想理解分布式事务,不得不先介绍一下两阶段提交协议。先举个简单但不精准的例子来说明: 第一阶段,张老师作为“协调者”,给小强和小明(参与者、节点)发微信,组织他们俩明天 8 点在学校门口集合,一起去爬山,然后开始等待小强和小明答复。 第二阶段,如果小强和小明都回答没问题,那么大家如约而至。如果小强或者小明其中一人回答说“明天没空,不行”,那么张老师会立即通知小强和小明“爬山活动取消”。 细心的读者会发现,这个过程中可能有很多问题的。如果小强没看手机,那么张老师会一直等着答复,小明可能在家里把爬山装备都准备好了却一直等着张老师确认信息。更严重的是,如果到明天 8 点小强还没有答复,那么就算“超时”了,那小明到底去还是不去集合爬山呢? 这就是两阶段提交协议的弊病,所以后来业界又引入了三阶段提交协议来解决该类问题。 两阶段提交协议在主流开发语言平台,数据库产品中都有广泛应用和实现的,下面来介绍一下 XOpen 组织提供的 DTP 模型图: XA 协议指的是 TM(事务管理器)和 RM(资源管理器)之间的接口。目前主流的关系型数据库产品都是实现了 XA 接口的。JTA(Java Transaction API) 是符合 X/Open DTP 模型的,事务管理器和资源管理器之间也使用了 XA 协议。 本质上也是借助两阶段提交协议来实现分布式事务的,下面分别来看看 XA 事务成功和失败的模型图: 在 JavaEE 平台下,WebLogic、Webshare 等主流商用的应用服务器提供了 JTA 的实现和支持。而在 Tomcat 下是没有实现的(其实笔者并不认为 Tomcat 能算是 JavaEE 应用服务器),这就需要借助第三方的框架Jotm、Automikos 等来实现,两者均支持 spring 事务整合。 而在 Windows .NET 平台中,则可以借助 ado.net 中的TransactionScop API 来编程实现,还必须配置和借助 Windows 操作系统中的 MSDTC 服务。如果你的数据库使用的 mysql,并且 mysql 是部署在 Linux 平台上的,那么是无法支持分布式事务的。 由于篇幅关系,这里不展开,感兴趣的读者可以自行查阅相关资料并实践。 […]

龙生   22 Dec 2018
View Details