none
Computers falling off the domain

    Question

  • We are experiencing a rash of computers falling off the domain, and there seems to be no rhyme or reason as to why or when.  We use Ghost – GSS 2.0 (with no sysprep or Ghostwalker) –  to image our labs.  We have a home-grown applet called “PostGhosties,” which renames each machine with a GHOSTED_CPU…. name temporarily after imaging.  The PostGhosties app then goes out to a .txt file on our server and matches the MAC address for the machine to a real computer name like LA312-13-27806 (BuildingRoom-RowPositionNumber-AssetTagNumber).  We use the Ghost Console to execute PostGhosties, renaming the machines and rejoining them to the domain.  While we know that the SIDs aren’t being changed, we’ve been doing this for years without trouble.  We also have DeepFreeze installed on all the workstations, and we’ve been setting the secure channel maximum password age to 998 (both on the workstations and the servers with group policies) to avoid known problems with secure channel password changes.

     

    The real trouble started after the last round of imaging, which we completed over winter break.  These updates included IE8 and replacing Symantec Antivirus with Sophos.  Since then, many computers in one room will fall off, while others don’t.  They’ve all been ghosted with the same image during the same Ghostcast session.  When checking the computer (before putting it back on the domain), we discovered that the maximum password age was somehow being reset back to 30 days in the registry, while the computer sitting right next to it still had the 998 days setting.  We contacted Sophos, but they claim their application doesn’t touch secure channel.  We started checking event logs, both on the workstations and the domain controllers to troubleshoot.  Below is an example of everything that transpired during the “falling off” process for one computer.  If anybody has any suggestions, I sure would love to hear them!

     

    Thanks!!

     

    Lianna Croft

    Assistant Director for User Services

    Technology Services

    Alverno College

    Lianna.croft@alverno.edu

    414-382-6337

     

    Event Properties – LA312-13, 3/12/10

    This machine “fell off the domain” on this date. Data was retrieved from the workstation prior to reboot to preserve data (DeepFreeze was on). Type in black is from the system log with a red error tag. Red type is from the system log with a yellow Warning tag. Type in Green is from the domain controller.

    ·         8:57:53AM

    o   Source LicenseServices (PDC\Event Viewer\Applications)

    o   eventID 202

    o   Computer    SRV

    o   The produce Windows Server is out of licenses. Us Licensing from the Administrative Tools folder for more information on which users are out of compliance and how many licenses should be purchased

    ·         9:04:55AM –

    o   Event ID 6011

    o   Computer: LA312-13-27806

    o   “The NetBIOS name and DNS host name of this machine have been changed from GHOSTED_CPU0763 to LA312-13-27806”

    ·         9:05:17 AM

    o   Source NETLOGON

    o   EventID: 3210

    o   Computer: LA312-13-27806

    o   “This computer could not authenticate with \\\    dc, a Windows domain controller for domain                   , and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for the computer account is not recognized.

    ·         9:05:27AM

    o   Source: Userenv

    o   Event ID: 1053

    o   User NT AUTHORITY\SYSTEM

    o   Windows cannot determine the user or computer name (Access is denied._ Group Policy processing aborted

    ·         9:05:28

    o   Source: AutoEnrollment

    o   Event ID: 15

    Automatic certificate for local system failed to contact active directory (0x8007052b). Unable to update the password. The value provided as the current password is incorrect. Enrollment will not be performed.

    ·         9:10:23AM

    o   Source:   SRV

    o   Category: SPNEGO (Negotiator)

    o   Event ID: 40961

    o   Computer: LA312-13-27806

    o   The Security System could not establish a secured connection with the server cifs/SOPHOS.  . No authentication protocol was available

    ·         9:11:07AM

    o   Source NELOGON

    o   Event ID: 3210

    o   Computer: LA312-13-27806

    o   This computer could not authenticate with \\        .  \, a Windows domain controller for domain                   , and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for the computer account is not recognized.

    ·         39:12:13AM

    o   Source NELOGON

    o   Event ID: 3210

    o   Computer: LA312-13-27806

    o   This computer could not authenticate with \\   dc.  \, a Windows domain controller for domain                   , and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for the computer account is not recognized.

    ·         9:21:17AM

    o   Source : DnsApi

    o   Event ID: 11165

    o   Computer LA312-13-27806

    o   “The system failed to register host (A) resources records (RRs) for network adapter with settings: Adapter Name: {big number} ……

    ·         9:38:50AM

    o   Source NELOGON

    o   Event ID: 3210

    o   Computer: LA312-13-27806

    o   This computer could not authenticate with \\   srv.  \, a Windows domain controller for domain                 , and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for the computer account is not recognized.

    ·         9:43:34AM

    o   Source: NETLOGIN

    o   Event ID: 5722

    o   Computer:    SRV

    o   The session setup from the computer LA312-1-27806 failed to authenticate. The name(s) of the account(s) referenced in the security database is LA312-13-27806$. The following event occurred: Access is denied.

    ·         12:25:31PM

    o   Source:   SRV

    o   Category: SNEGO (Negotiator)

    o   Event ID 40961

    o   The Security System could not establish a secured connection with the server LDAP/pdc.  . No authentication protocol was available.

    ·         12:25:32PM

    o    Source:   SRV

    o   Category: SPNEGO (Negotiator)

    o   Event ID 40961

    o   The Security System could not establish a secured connection with the server LDAP/pdc.  . No authentication protocol was available.

    ·         12:50:21

    o   Source: W32Time

    o   Event ID: 29

    o   “The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible. No attempt to contact a source will be made for 240 minutes. NtpClient has no source of accurate time.

    ·         1:20:17PM

    o   Source NELOGON

    o   Event ID: 3210

    o   Computer: LA312-13-27806

    o   This computer could not authenticate with \\        .  \, a Windows domain controller for domain                   , and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for the computer account is not recognized.

    ·         1:22:17PM

    o   Source: LSASRV

    o   Category: SPNEGO (Negotiator)

    o   Event ID 40961

    o   The Security System could not establish a secured connection with the server cifs/SOPHOS.  . No authentication protocol was available.

    ·         1:28:48PM

    o   Source: LSASRV

    o   Category: SPNEGO (Negotiator)

    o   Event ID 40961

    o   The Security System could not establish a secured connection with the server cifs/        .  . No authentication protocol was available.

    ·         1:13:35PM

    o   Source: LSASRV

    o   Category: SPNEGO (Negotiator)

    o   Event ID: 40961

    o   Computer: LA312-13-27806

    o   The Security System could not establish a secured connection with the server cifs/dc.  . No authentication protocol was available

    ·         1:44:02 PM

    o   Source: LSASRV

    o   Category: SPNEGO (Negotiator)

    o   Event ID: 40961

    o   Computer: LA312-13-27806

    o   The Security System could not establish a secured connection with the server cifs/   srv.  . No authentication protocol was available

    ·         1:50:17PM

    o   Source NELOGON

    o   Event ID: 3210

    o   Computer: LA312-13-27806

    o   This computer could not authenticate with \\   srv.  , a Windows domain controller for domain        , and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for the computer account is not recognized.

    ·         1:53:11PM

    o   Source: NETLOGON

    o   Event ID: 5722

    o   Computer:    SRV

    o   “The session setup from the computer LA312-13-27806 failed to authenticate. The name(s) of the account(s) referenced in the security database is LA312-13-27806$. The following event occurred: Access is denied.”

    Note: I removed and rejoined the client to the domain about 2pm.

    Monday, March 15, 2010 7:05 PM

Answers

  • I assume that, despite it worked before, the SID's are causing this issue. After all the SID is used for the computer password and to reate the domain accounts.

    i would recommend to change the sid with the sysinternals tool newsid on a few machine and detect whether these machiens are still affected.


    MCSA/MCTS/MCP
    Tuesday, April 06, 2010 11:18 AM

All replies

  • Have you tried to remove them from the domain, Delete them from Active directory (computer), then remove from DNS,and then rejoin to the domain.
    Also have you checked the DNS server settings on the NIC, but I think that the above should help.
    Tuesday, April 06, 2010 1:17 AM
  • I assume that, despite it worked before, the SID's are causing this issue. After all the SID is used for the computer password and to reate the domain accounts.

    i would recommend to change the sid with the sysinternals tool newsid on a few machine and detect whether these machiens are still affected.


    MCSA/MCTS/MCP
    Tuesday, April 06, 2010 11:18 AM
  •  I agree with the point of SenneVL. as per summery, it shows that it has ran with the same ghost Image. hence, the domain recognizes the system on the basis of unique ID, which is missing in this case. For any pwd change policy to take place, all the comp accts should have isolated ID. ONly then it will able to understand and communicate with the client.  And for your information NETLOGON  is the service which act as the a media for pwg change...

     

     

     

    Friday, April 16, 2010 8:47 PM
  • We have this problem also.  It has nothing to do with syspreping or not.  The Reason stems from deepfreeze.  I can recreate this in our lab.  We do not allow users to changetime in our deepfreeze configuation.  When the machine is frozen, pull the plug and go into bios during boot.  Change the date so it is a couple of years behind.  let windows boot.  You will get domain controller not found.  We have noticed this falling off happening when we had power hits.  I noticed the bios was loosing the date and time on some machines, Fix for us was to replace the MB battery so the settings are not lost during power hits.
    • Proposed as answer by Steve Mal Wednesday, May 05, 2010 9:22 PM
    Thursday, April 29, 2010 8:02 PM
  • Received this email from Faronics today

    Dear Steve,

    Thank you for contacting Technical Support. The issue you might be running into is that if the system date is before the current date, the system might think the that Secure Channel Password needs to be changed since the Domain Controller may think the currrent password has expired. The Domain Controller will automatically issue a new Secure Channel Password but because the systems are frozen, the workstaiton will revert to the old Secure Channel Password and the trust relationship will be broken and the system removed from the domain.

    To avoid this behavior, you should insure that the CMOS batteries are working correctly. Also you should verify that you have a Group Policy Object set to insure that MachineMaximumPasswordAge is set to 99999 days.

    You can get further information about disabling the Secure Channel Password by referring to the article "Disable Secure Channel Password and Trust Password Changes" which can be found at Disable Disable Secure Channel Password and Trust Password Changes.

     

     

    Regards,

    David Feinstein

    Technical Support

    Faronics Technologies Inc.

    Tel: 800-943-6422

    Fax: 800-943-6488

    Intelligent Utilities for Absolute Control

    www.faronics.com

     

     

    www.faronics.com/av

     

     

    Now with Faronics Anti-Virus!

    • Proposed as answer by Steve Mal Wednesday, May 05, 2010 9:24 PM
    Wednesday, May 05, 2010 9:23 PM
  • We, a community college, also are experiencing this problem of various classroom lab Win7x64 computers, mostly Dell 790's, and also using Deep Freeze, randomly falling off the domain.  Lately, my experiences have been that after doing some, but not all, Windows updates, I have to put the pc's back onto the domain. Weekly we have a system that unfreezes them automatically, applies updates, and refreezes them.

    My current belief is that there are some Windows updates that knock the pc off the domain.  We also have found that rather than the two-step process of placing pc onto workgroup and restart, and then back onto domain and restart - the one-step process of using the [Network ID...] choice is more efficient and also confirms the AD OU object in the process of putting pc back on the domain.

    Monday, June 25, 2012 4:44 PM
  • Hi all,

    We've had major problems with hundreds of PCs dropping out of AD with the "Trust Relationship between the workstation and the domain controller" message for the past 4 months. The symptoms are to the letter of the original poster, and I have posted everywhere without any answers or fix to the situation.

    We roll out a SYSPREPPED image to over 4 floors of 140+ PCs each, using Ghost. The PCs then boot up and sysprep runs and changed the SID etc. Once all the PCs are in the domain (via scripts) and deepfreeze is used to seal up the Pcs all is fine. However after a few days, reports start coming in about Pcs randomly failing.

    We have had to manually unfreeze and rejoin them (painfully slow) and kept logs of failed PCs, but the worrying thing is that the "SAME" PCs have failed again later down the line.

    I have recreated the Image and fully patched the image with the latest patches from microsoft and rolled that out via ghost last week to 140 PCs and guess what..... yes after randomly checking 12 PCs today, 8 are back again with the trust relationship problem....

    What is going on, does anyone have any idea how to fix this? Is it a windows patch causing this? I have an older image on different hardware which has not been as bad with this error, but how on earth can we be expected to go through each windows patch until we find (or not find) the culprit, if it is that in the first place?

    This issue only cropped up since easter this year when we rolled out some new HP PCs, but no clue why this is happening.

    Any ideas?

    Tuesday, June 26, 2012 4:22 PM