Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

Would IP scheme change of network cause issues with trust relationship on PCs communicating to the DC?

Posted on 2017-03-07
8
Medium Priority
?
91 Views
Last Modified: 2017-03-16
I have recently changed IP schemes of a  rather good size network, taken from a class B "flat" network operating on the default vLANS to a network separated into more logical class C VLANS. In doing so we changed the IP scheme from 192.168.0.0 to a 10.1.x.x depending on the VLAN tag.  This seemed to be the most logical/secure way to handle this.  All these changes have been applied and operational for about three weeks now including all vlans handing out appropriate IPs based on VLAN tag.  All this to say that the the default DC changed from 192.168.0.5 to 10.1.1.5

The issue was just brought to my attention that there were a few PCs that just recently appeared to have logged in the local user on a temporary account, which is not to big of deal other than the users had a few local docs saved, so they saw that these were not there.  I am not working this issue directly and only getting update from someone on site.  My question is would the IP change had any adverse affect on these machines seeming to have lost its "trust" relationship to the domain controller? Or is there another issue un-related?

Please let me know your thoughts...
0
Comment
Question by:ITGUY-17
  • 3
  • 2
  • 2
  • +1
8 Comments
 
LVL 19

Expert Comment

by:Mal Osborne
ID: 42038577
In theory, if everything  was done perfectly, this shoudl not have happened. Having said that, a few unnoticed DNS entries or something could easily wreak havoc; with a project like this one I would anticipate at very least minor problems.

I am not sure I understand the description of the fault. Has the user been unable to login to the domian, and chose to log in with local account credentials instead, or did they log in with the normal credentials, and have thier profile fail to load? Are you running roaming profiles?
0
 
LVL 14

Expert Comment

by:Natty Greg
ID: 42038610
A change in scope requires a reboot of both systems including the DHCP so that the ptr record can be set, so clients can find the resources. or you can wait until all this propagate which will take time.
0
 

Author Comment

by:ITGUY-17
ID: 42038627
I will get verification, but from what I have now the user was receiving the the error that "The Trust relationship between the workstation and the primary domain failed". So then the user was logged in with a temporary profile. I have checked a few other accounts, and it does not appear that roaming profiles are being used. This issue has only been seen on three machines on a domain with around 500 workstations logging in on a daily basis. One other note is that these three machines are all on the same VLAN.

Natty Greg:  The DC which is also the DHCP server has been rebooted since these changes were applied. Also, the time frame of nearly a month has passed again with users/pcs logging into  the domain without issue.

Just trying to eliminate causes here... I am not ruling out this may be a fluke with these PCs themselves?

Thanks again for all the help.
0
What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

 
LVL 19

Accepted Solution

by:
Mal Osborne earned 1000 total points
ID: 42038693
Odd. "The Trust relationship between the workstation and the primary domain failed" means the machine account on the DC has somehow been corrupted, however I can't see how your changes would invoke that. If a machine is totally unable to contact a domain controller, due to connectivity issues, DNS misconfiguration or being plugged into a foreign network, users who have logged in before should still be able to log it, using cached credentials. Laptop users do this all the time.

I would probably start by checking time sync, some skew can cause all sorts of wierd problems. Next step for me would be checking that the DCs are replicating properly with each other.

https://technet.microsoft.com/en-us/library/cc794749(v=ws.10).aspx
0
 
LVL 14

Assisted Solution

by:Natty Greg
Natty Greg earned 1000 total points
ID: 42038728
You can join the domain from the client if at the same time you can provide an administrator username and password on the domain.

-or-
You can delete the existing computer account in Server Manager, recreate the computer account, synchronize the domain, and then on the client rejoin the domain.

Also note that there will a mis trust between computers whose time is off by 5 minutes.

make sure the times are sync and if the computer is not keeping proper time change the cmos battery
0
 

Author Comment

by:ITGUY-17
ID: 42039359
Malmensa: I did notice while assisting with this issue that the DC was completely off on time a few days ago, and that it was corrected on the DC. I am unsure how the tech may force the time sync out to his machines, or if that is done at all. I have asked for some remote access to better assist on this issue, and see if that may be the culprit.  I completely agree with your statement on the use of cached credentials if there may be some type of networking misconfiguration, over even if the machine is off network for that matter. Also, note there is only one DC on this network.

Natty Greg: We are looking into the possibility this may be related to time sync.

Again, thanks for all the help. I will update this as I get more information.
0
 
LVL 32

Expert Comment

by:masnrock
ID: 42039758
The DC would act as an NTP server to machines joined to the domain. This is an automatic process. The DC's time being off is another issue totally, and it would cause workstations to get the wrong time at times. That could be due to a bad CMOS battery on the server, which would need replacement. What I've done in a few cases is to actually utilize a time sync program to at least keep the DC's time accurate until the battery was replaced.
0
 

Author Closing Comment

by:ITGUY-17
ID: 42051133
This seemed to have been the cause on these three machines, as they were the only ones that lost that trust relationship to the DC.  The time sync has been put into place with using an NTP server per the internet to sync the time to the DC.

Thanks for all your help!
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Originally, this post was published on Monitis Blog, you can check it here . It goes without saying that technology has transformed society and the very nature of how we live, work, and communicate in ways that would’ve been incomprehensible 5 ye…
This article will show how Aten was able to supply easy management and control for Artear's video walls and wide range display configurations of their newsroom.
Internet Business Fax to Email Made Easy - With  eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, f…
In this video we outline the Physical Segments view of NetCrunch network monitor. By following this brief how-to video, you will be able to learn how NetCrunch visualizes your network, how granular is the information collected, as well as where to f…

876 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question