Trust Relationship Errors at Logon
Trust relationship errors are often caused by "naming collisions" stemming from using non-Dell usb-to-ethernet adapters that are passing their own MAC addresses to AD.
1. Try re-binding to AD. This will work if there is not a naming collision. You need a local admin account to do this.
Option 1: use LAPS.
Option 2: try your adm account while disconnected from all network. If you had previously logged in, your credentials will be cached.
Option 3: use a local ITSC (or old S&R Administrator) account.
(If these fail and you have to preserve data, you’ll have to pull the drive, mount it, copy user data off, redeploy the machine from scratch.)
2. If re-binding does not solve the problem, then most likely the trust relationship issue was caused by imaging with the same (unsupported) ethernet adapter repeatedly.
Explanation: When a machine is OSD’d (or re-OSD’d), it will bind to its existing AD object and name **referenced by the MAC address. The 3rd party ethernet adapters pass their own MAC address to SCCM. When the adapter is used a second time, the second machine ‘overwrites’ the record of the first in AD/SCCM, and an AD account will not be able to log in on it.
3. If there is a naming collision, go to one of the machines, login as local admin user, rename computer, then re-bind as above.
4. If you have to OSD with a third-party adapter, delete the prior SCCM object after OSDing, and it will add itself back to SCCM with the right unique MAC address for the machine, solving this problem.
Note 1: ITSCs are expecting a delivery soon (early Nov 2019) of Dell-approved ethernet adapters. Use these to avoid this problem.
Note 2: It has happened a few times that Dell shipped more than one computer with identical service tags, but this is extremely rare.