• Win32Exception (0x80090311) —— 计算机 脱域 —— Kerberos 异常


    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
    ---> System.ServiceModel.Security.SecurityNegotiationException: Authentication failed on the remote side (the stream might still be available for additional authentication attempts).
    ---> System.Security.Authentication.AuthenticationException: Authentication failed on the remote side (the stream might still be available for additional authentication attempts).
    ---> System.ComponentModel.Win32Exception (0x80090311): Unknown error
    --- End of inner exception stack trace ---
    at System.Net.Security.NegoState.ThrowCredentialException(Int64 error)
    at System.Net.Security.NegoState.ProcessReceivedBlob(Byte[] message, LazyAsyncResult lazyResult)
    at System.Net.Security.NegoState.ReadCallback(IAsyncResult transportResult)
    --- End of stack trace from previous location where exception was thrown ---
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw(Exception source)
    at System.Net.Security.NegoState.EndProcessAuthentication(IAsyncResult result)
    at System.Net.Security.NegotiateStream.EndAuthenticateAsClient(IAsyncResult asyncResult)
    at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)
    --- End of stack trace from previous location where exception was thrown ---
    at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeInitiator.OnInitiateUpgradeAsync(Stream stream, OutWrapper`1 remoteSecurity)
    --- End of inner exception stack trace ---
    at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeInitiator.OnInitiateUpgradeAsync(Stream stream, OutWrapper`1 remoteSecurity)
    at System.ServiceModel.Channels.StreamSecurityUpgradeInitiatorBase.InitiateUpgradeAsync(Stream stream)
    at System.ServiceModel.Channels.ConnectionUpgradeHelper.InitiateUpgradeAsync(StreamUpgradeInitiator upgradeInitiator, OutWrapper`1 connectionWrapper, ClientFramingDecoder decoder, IDefaultCommunicationTimeouts defaultTimeouts, TimeSpan timeout)
    at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreambleAsync(IConnection connection, ArraySegment`1 preamble, TimeSpan timeout)
    at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnectionAsync(TimeSpan timeout)
    at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpenAsync(TimeSpan timeout)
    at System.ServiceModel.Channels.CommunicationObject.OnOpenAsyncInternal(TimeSpan timeout)
    at System.ServiceModel.Channels.CommunicationObject.System.ServiceModel.IAsyncCommunicationObject.OpenAsync(TimeSpan timeout)
    at System.ServiceModel.Channels.CommunicationObject.OpenAsyncInternal(TimeSpan timeout)
    at System.Runtime.TaskHelpers.WaitForCompletion(Task task)
    at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
    at System.Runtime.TaskHelpers.CallActionAsync[TArg](Action`1 action, TArg argument)
    at System.ServiceModel.Channels.ServiceChannel.OnOpenAsync(TimeSpan timeout)
    at System.ServiceModel.Channels.CommunicationObject.OnOpenAsyncInternal(TimeSpan timeout)
    at System.ServiceModel.Channels.CommunicationObject.System.ServiceModel.IAsyncCommunicationObject.OpenAsync(TimeSpan timeout)
    at System.ServiceModel.Channels.CommunicationObject.OpenAsyncInternal(TimeSpan timeout)
    at System.Runtime.TaskHelpers.WaitForCompletion(Task task)
    at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
    at System.ServiceModel.Channels.ServiceChannel.CallOpenOnce.System.ServiceModel.Channels.ServiceChannel.ICallOnce.Call(ServiceChannel channel, TimeSpan timeout)
    at System.ServiceModel.Channels.ServiceChannel.CallOnceManager.CallOnce(TimeSpan timeout, CallOnceManager cascade)
    at System.ServiceModel.Channels.ServiceChannel.EnsureOpened(TimeSpan timeout)
    at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
    at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
    at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(MethodCall methodCall, ProxyOperationRuntime operation)
    at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(MethodInfo targetMethod, Object[] args)
    --- End of stack trace from previous location where exception was thrown ---
    at System.Reflection.DispatchProxyGenerator.Invoke(Object[] args)

    https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/705fb797-2175-4a90-b5a3-3918024b10b8

    脱域 or 网络问题

    计算机脱域

    1. 计算机长时间没登陆域会自动脱离域,那么是不是超过30天未登录过域的计算机就一定会脱离域?
    2. 我的环境中发现有几台计算机由于休假或者出差长时间(两三个月)未登录域,这部分计算机在30天以前已经被我经用了,今天我启用这几台计算机之后,发现他们仍能后登陆域。计算机与域控间的网络正常。这个怎么解释?(域功能级别windows server 2008 r2)

     

    回答:从您的描述中,我对这个问题的理解是您想知道计算机是不是超过30天未登录就一定会脱域。

    默认情况下,加域计算机每三十天就会更改一次计算机密码,这个密码会分别被存在计算机本地和AD里面。同时,计算机本身会保存两份密码在本地:当前的密码和之前的密码。当计算机尝试和DC建立secure channel的时候,它会先使用最新的密码,如果这个密码无效,那么它会尝试使用之前的那个密码,如果这个密码也不能够和AD域里面保存的密码匹配,那么计算机和DC之间的secure channel就会被破坏,我们将不能通过域账号登录到这台电脑上。因为我们不清楚计算机密码是什么时候更改的,所以一般情况下,计算机不能登录到域的时间范围是31到60天。您看到的文章来自活动目录seo http://adirectory.blog.com/category/active-directory/

    这里也要分两种情况:

    • 加域的计算机shutdown的话,在它Start up之前,它是不会更改计算机密码的。
    • 如果加域的计算机一直在运行,只是没有连到公司网络,那么它仍然会每隔三十天更改一次密码。

    计算机脱域的时间不是随机的,它是由计算机能够联系到DC的时候最后一次改密码的时间决定的。举个例子:比如还有十天计算机就需要更改密码了,从这个时候开始,它将不再处于域环境中,那么,他不能够登录到域的时间是四十天之后。

    具体一点说:比如它在域的最后一次密码是:password1(剩余有效期:10天),十天之后他需要改密码了,改为password2(有效期30天)。这时候在计算机保存的密码是:password1和password2,在DC端保存的密码是password1。在第三十五天的时候,如果计算机连到公司网络,它会首先尝试用password2去和DC建立安全通道,由于DC没有这个新的密码,计算机再次尝试并用password1,由于DC保存有这个密码,密码匹配,那么安全通道成功建立,计算机就可以登录到域。

    然而,如果是在第四十五天的时候,这时候计算机已经第二次改密码了,假设为:password3。那么在计算机保存的密码是:password2和password3,在DC端保存的密码仍然是password1。当计算机连到公司网络,他会尝试用password3和password2去和DC建立安全通道,由于DC上面保存的密码是password1,他们不能够匹配,安全通道建立不起来,计算机就不能够登录到域环境。

    不过由于我们无法得知计算是具体是什么时候更改的密码,所以在某种程度上面来讲,您可以认为计算机不能够登录到域的时间在31~60天的时间段内是随机的。

    From:http://adirectory.blog.com/2015/02/computer-disconnects-from-domain/

     [DateTime]::FromFileTime((Get-ADComputer bailin1 -Properties pwdlastset).pwdlastset) 
     
     
     
     
     
    By
    Published Apr 04 2019 01:52 PM  83.1K Views
     
     

    First published on TechNet on Feb 13, 2009


    Hi, this is Manish Singh from the Directory Services team and I am going to talk about the machine account password process. Ever wondered what goes on with your machine account in Active Directory? Here is a brief set of question and answers to clear things up.

    Question: How often does the machine password account change in AD (is it different for various Windows operating systems)?

    Answer: The machine account password change is initiated by the computer every 30 days by default. Since Windows 2000, all versions of Windows have the same value. This behavior can be modified to a custom value using the following group policy setting in Active Directory.

    Domain member: Maximum machine account password age

    You can configure this security setting by opening the appropriate policy and
    expanding the console tree as such:

    Computer\Configuration\Windows Settings\Security Settings\Local Policies\Security Options

    Question: If a workstation does not change its password, will it not be allowed to log onto the network?

    Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

    So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.

    If the machine was down for a long time, that scavenger thread will not run and the password will not get out of sync in the local store and Active Directory.

    If the machine was unable to communicate with a domain controller, the client doesn’t try to change its password. For example, if it was a laptop running at home with no VPN for 4 months, the laptop would never change its own machine password. 

    The relevant Netlogon parameters that come into play and we can think about changing here are:

    ScavengeInterval (default 15 minutes),
    MaximumPasswordAge (default 30 days)
    DisablePasswordChange (default off).

    DisablePasswordChange would prevent the client computer from changing its computer account password.

    Warning: If you disable machine account password changes, there are security risks because the security channel is used for pass-through authentication. If someone discovers a password, he or she can potentially perform pass-through authentication to the domain controller.

    Here is the article that talks about disabling automatic machine account password change: KB154501

    Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
    Value = DisablePasswordChange REG_DWORD
    Default = 0

    Group policy setting:
    Computer\Configuration\Windows Settings\Security Settings\Local Policies\Security Options

    Domain member: Disable machine account Password changes

    ScavengeInterval controls how often the workstation scavenger thread runs - the workstation scavenger is responsible for changing the machine password if necessary.

    HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
    Value: ScavengeInterval REG_DWORD, 60 to 172800 Seconds (48 hours)
    Default : 900 (15 minutes)

    MaximumPasswordAge determines when the computer password needs to be changed.

    Key = HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
    Value = MaximumPasswordAge REG_DWORD
    Default = 30
    Range = 1 to 1,000,000 (in days)

    Group policy setting:
    Computer\Configuration\Windows Settings\Security Settings\Local Policies\Security Options

    Domain member: Maximum machine account Password age

    To clear things up, it is 7 days on Windows NT by default, and 30 days on Windows 2000 and up.

    The trust password follows the same setting. So Trust between two NT 4 domains is 7 days. Trusts between Windows 2000 and up and anything else is 30 days.

    So what this means is if:

    - 2000 and NT4 trust password is 30 days.
    - 2000 to 2000 is 30 days.
    - 2000 to 2003 is 30 days.
    - 2003 to 2003 is 30 days.

    After Netlogon service starts the Workstation service scavenger thread wakes up. If the password is not older than MaximumPasswordAge , the scavenger thread goes back to sleep and sets itself to wake up when the password will reach that age. Otherwise, the scavenger thread will attempt to change the password. If it cannot talk to a DC, it will go back to sleep and try again in ScavengeInterval minutes.

    The ScavengeInterval setting can be modified to a custom value using the group policy setting in Active Directory.

    Group policy setting:
    Computer Configuration\Administrative Templates\System\Netlogon\Scavenge Interval

    Further we have given the following clarification regarding the behavior described
    in KB260575.  

    Question: How do computers actually use passwords?

    Answer: Each Windows-based computer maintains a machine account password history containing the current and previous passwords used for the account. When two computers attempt to authenticate with each other and a change to the current password is not yet received, Windows then relies on the previous password. If the sequence of password changes exceeds two changes, the computers involved may be unable to communicate, and you may receive error messages.

    When a client determines that the machine account password needs to be changed, it would try to contact a domain controller for the domain of which it is a member of to change the password on the domain controller. If this operation succeeds then it would update machine account password locally.


    The local copy of the machine password is stored under:

    HKLM\SECURITY\Policy\Secrets\$machine.ACC

    We store the current password and the previous password under CurrVal & OldVal Keys respectively.

    In Active Directory, we store the password in unicodepwd and lmpwdHistory . We also store the timestamp in the pwdlastset attribute (the method to convert it into readable format is



    Convert the value in the attribute from decimal to hex (using calc.exe)
    Split the result into two equal parts (8 bits for each part)
    Run nltest /time: rightsidehex leftsidehex

    The resultant value is the date and time the password was set on this computer object in AD. The cases where in you could run into problems that the KB260575 describes would be:

    If you use System Restore after the password change interval expired one time, and you restore the computer to a point before the password changes, the next password change may not occur when it is due. Instead, the operating system treats the restore as if the password was changed.

    Now consider the scenario, when a machine is not connected to the network for a long period.

    Supposing on the client:

    Old password = null
    Current password = A

    New random password = B

    And on the machine account in AD:


    unicodePWD = A


    After 30 days when the Scavenger thread runs, the value would be


    Old Password = A

    Current Password = B
    At 60 th day the same process happens again. So now the newly generated password is C and the values are:

    Old password = B

    Current Password = C

    Now when the client connects to AD, it will try the current password to authenticate. When that fails with the error, it can try the previous. Otherwise machine should be able to reset its password once it boots even after say 90 days.

    Update April 2020: While the above scenario may have been possible when the article was originally written, Windows 7 SP1 clients and later will never reset the local registry LSA secret if it fails to reset the AD object’s corresponding UnicodePWD attribute -- in other words: Local password change will never occur unless a DC is able to process the change.



    How to detect and remove inactive machine accounts

    https://gallery.technet.microsoft.com/scriptcenter/Get-Active-Directory-df516533

    https://gallery.technet.microsoft.com/scriptcenter/Get-Inactive-Computer-in-54feafde

    I would recommend the following KB articles as good reads:

    How to disable automatic machine account password changes

     
    Effects of machine account replication on a domain
    https://support.microsoft.com/en-us/help/175468/effects-of-machine-account-replication-on-a-domain

    Domain member: Disable machine account password changes
    https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-...

    Domain member: Maximum machine account password age
    https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-...

    Account Passwords and Policies
    https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/passwor...

    To wrap it up Machine account password are driven by Client computer not by Active directory. The Netlogon scavenger thread is responsible for changing the Machine password if necessary the same can be modified by group policy. We first change the password locally and then update it in Active Directory. It will not rollback the changes to the current password if it is unable to update it in Active Directory.


    - Manish Singh
  • 相关阅读:
    python-pyStrich条形码模块
    js原型及原型链解析
    解决Genymotion下载device时较慢的问题
    nodejs实现OAuth2.0授权服务
    Swagger文档添加file上传参数写法
    TypeScript学习笔记之类
    TypeScript学习笔记之接口类型
    win64环境下使用curl命令
    TypeScript学习笔记之基础类型
    WebRTC介绍及简单应用
  • 原文地址:https://www.cnblogs.com/panpanwelcome/p/15924666.html
Copyright © 2020-2023  润新知