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.

Solution: 

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: Use Dell-approved ethernet adapters (rather than third party) 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.