关于Daas平台无法登录的故障处理
【事件描述】
某天对Daas桌面环境中AD域控服务器进行挂起，执行克隆备份操作后，再次开启AD域控后，登录短少系统报错：身份验证失败，无法登录。如下图所示：
【故障分析及处理】
1）本次故障前除挂起ad虚拟主机操作外，未执行任何其他操作；故故障应该出现在AD域控内部，导致的域验证信任关系失败；故着重检查AD域相关设置。
2）浏览器打开【开发者模式】，执行登录调试报：401错误，如下图所示：
401错误说明：
一般来说该错误消息表明您首先需要登录（输入有效的用户名和密码）。 如果你刚刚输入这些信息，立刻就看到一个 401 错误，就意味着，无论出于何种原因您的用户名和密码其中之一或两者都无效（输入有误，用户名暂时停用等） 。
3）后发现是AD域控的时间自动被修改了，所以无法通过身份验证，AD域环境对时间有较高的要求。
但是修改时间并将vmtools配置为与ESxi主机同步后，报400错误：
但是直接通过TA连接云桌面，是可以成功登录的！后再次尝试，登录失败；发现时间又被更改，遂取消虚拟机在vmtools处于ES洗主机的时间同步，再次手动修改时间后，登录正常。
【总结】
1)注意事项：
AD域环境对时间要求很高，因此整个环境部署前要提前规划好NTP服务器，或者配置手动时间，相差时间不得超过5分钟；
2）AD环境身份验证时间的影响说明：
PDC服务器和Internet 外部时间源或本地硬件同步。所有域控制器按层次结构找PDC同步。所有成员服务器或客户端在登录时通过那台服务器验证，就与那台DC时间进行同步。对于加入域环境的客户端是与在父域中的权威服务器进行时间同步的。默认的同步时间的方法就是使用域层次，客户端会使用其所连接域中的域控来同步时间，而域控会反过来从整个林中的权威时间源来同步时间。如果在森林的根域中没有指定某个域控为权威时间源，那么拥有PDC角色域控会担当这个权威时间服务器。这台PDC会使用自己内部的时钟来为整个林的域控提供时间。确保PDC时间源才准确性，通常建议PDC使用外部的权威时间源（这样可以减少时间偏差和我们管理工作量）。
时间同步非常重要，这主要是因为AD使用的是Kerberos验证，验证需要保证客户端和服务器之间的时间不能相差太多。默认情况下，客户端与服务器之间的时间不能相差5分钟，否则验证无法通过。时间不同步也会出现客户端不能正常加域和lync客户端不能登陆的问题。AD中客户端主要是通过W32tm这个服务使用NTP协议来同步，从而保证客户端与服务器的时间准确；另外，我理解，客户端与DC交互信息携带相关时间属性信息，如果时间不同步，那这些交互信息将无法成功匹配，无法完成交互，也即无法验证，欢迎各位小伙伴追加关于这方面的说明和理解！！！
3）AD集中身份验证的工作原理
加入域的客户端是使用域用户登录后，系统会使用Kerberos验证用户的身份和网络服务。Kerberos中的一项重要服务是密钥发行中心（KDC），KDC作为Active Directory目录服务的一部分在每个域控制器上运行，它存储了所有客户端密码和其他帐号信息。用域用户帐号成功登陆到域后，DC会替用户建立一个访问令牌（Access Token），其中包含着该用户的SID及用户所属所有组的SID 。且这个令牌会一直生效，每次的令牌应该是一样的，因为令牌里包含用户的SID和所属组以及权力，只要你没改变他的这些特性，就应该是一样的
参考：https://blog.51cto.com/gnaw0725/686657在Windows 2000及以上的域环境中，默认的验证协议是Kerberos v5。
假设现在用户是在一个Windows 2003的域环境。当一台客户机登录域时，客户按下CTRL+ALT+DEL, 机器的 Winlogon 服务在转到登录的界面前，会触发 Winlogon的组件之一GINA DLL。GINA会显示登录界面，同时 GINA 也负责收集用户登录的数据，打包成数据单位，然后送给LSA认证。用户输入用户名及密码，选定域。当按下确定时， GINA 把用户信息传给Winlogon。 Winlogon 把信息传给 LSA。 LSA 使用LsaLogonUser进行验证. 就在此时，LSA开始使用Kerberos V5验证协议开始验证。 LSA收到用户密码后，使用DES-CBC-MD5加密方法加密生成一个Key。（所以Kerberos version 5验证协议必须支持DES-CBC-MD5）。这个Key就是用户密钥。LSA 与Kerberos SSP 互动，得到TGT Ticket和service ticket. 使用这些ticket, LSA就可以和KDC（Key Distribution Center密钥分发中心）交换信息。（客户机通过DNS查询来定位KDC，每台DC都是在DNS注册过的KDC）。通过和KDC的互动，客户机使用 Kerberos发送消息 KRB_AS_REQ 给KDC。该消息包括用户名，域以及生成的密钥。KDC 从其数据库中找到用户及用户密钥，对比结果，如果用户及密钥都相同，则该用户被允许登录。但此时用户仅仅是能登录，如果要做其余的动作，比如浏览共享文件夹等，则用户要先与KDC做近一步的互动。您看到的文章来自活动目录seo 用户登录域，必须先通过DNS定位KDC，然后使用Kerberos验证协议。这2步是必须的。DNS使用的是TCP和UDP的53端口，Kerberos使用的是TCP和UDP的88端口。
