script for domain trust relationship??

jabokimjabokim Member Posts: 56 ■■□□□□□□□□
Hi,
Does anyone know of a script (preferably with powershell) that when we add a PC to the domain that it will use the admin/password automatically, thus always having a constant trust relationship. We just had a guy quit, so now we're getting a bunch of trust issues on the PC's he added to the domain. Thanks!

Comments

  • kriscamaro68kriscamaro68 A+, Net+, Server+, Security+, Win7 MCP, Server 2012 Virtualization Specialist, MCSA 2012 Member Posts: 1,186 ■■■■■■■□□□
    Not sure how him leaving would affect a trust relationship between a workstation and the DC. That is taken care of by the computer account and a password set within AD for the computer account. It has nothing to do with a user account at all. Do you sysprep your images before deploying them? Did he? Did he have access to ADUC and could be logging in and deleting the computer accounts from AD because he is pissed? You should be looking at something else at this point as the admin/password is not your issue.
  • jabokimjabokim Member Posts: 56 ■■□□□□□□□□
    I was thinking the same thing too. Our systems admin said since the other IT guy left, it tries to verify the trust by using his old admin login and password but since it's no longer active it doesn't work. he mentioned it's just a windows 7 issue. Then when I remove it from the domain and add it back on with my admin credentials the workstations with this problem works again. he was trying to figure out a way to use a script with our IT managers login/password so there won't be any more trust issues. i'm new to this stuff so i've been confused about it lol
  • kriscamaro68kriscamaro68 A+, Net+, Server+, Security+, Win7 MCP, Server 2012 Virtualization Specialist, MCSA 2012 Member Posts: 1,186 ■■■■■■■□□□
    I think there are other underlying issues here. Using a script with someones credentials is a major security issue and I would recommend that he not try anything close to that. The fix for any trust relationship issue between a workstation and a DC is almost always dis-join and then re-join so as long as you use any user account that has rights to join a domain it will work. I have never ran into this issue before on any of my systems. We had to fire our previous Systems Engineer who had joined plenty of workstations\servers to the domain and his account has been inactive for almost a year now and we don't have any issues like this. Something seems very wrong.
  • QordQord Senior Member Member Posts: 632 ■■■■□□□□□□
    You should create a locked-down ad user for just that purpose. Check "method 2" here:
    Domain Users Cannot Join Workstation or Server to a Domain
    You can then use the add-computer powershell function to add the computer to a workgroup, and then use it again to add it back into the domain.
  • xenodamusxenodamus Member Posts: 758
    You can script this for convenience sake if you want, but this isn't what's causing your problem.

    It doesn't matter what user account you join the domain with. After joining, the trust relationship is maintained using a "computer account password" that is rotated and synced between the machine and AD every 90 days. You've got something else going on here.
    CISSP | CCNA:R&S/Security | MCSA 2003 | A+ S+ | VCP6-DTM | CCA-V CCP-V
  • MrJimbo19MrJimbo19 Member Posts: 49 ■■□□□□□□□□
    As Xenodamus mentioned it sounds like something else is going on in addition to the person leaving. You may find this read useful on how the machine account process works, remember that the trust on the local machine is established between the AD and the machine, not the user. Expiring the user account will simply prevent that user from logging in/being authenticated to the domain.

    Machine Account Password Process - Ask the Directory Services Team - Site Home - TechNet Blogs
  • CodeBloxCodeBlox Member Posts: 1,363 ■■■■□□□□□□
    jabokim wrote: »
    he was trying to figure out a way to use a script with our IT managers login/password so there won't be any more trust issues.
    Using user accounts to run automated tasks is bad business. One more thing to troubleshoot and fix when **** breaks.
    Currently reading: Network Warrior, Unix Network Programming by Richard Stevens
Sign In or Register to comment.