“Klareringsforholdet mellom arbeidsstasjonen og primærdomenet ble ødelagt.” or “The trust relationship between this workstation and the primary domain failed.”

I added the Norwegian translation of the error message to the title as well to help any Norwegians trying to find a solution to this Windows AD issue. The root cause is that the kerberos secret on the client no longer (for some reason) matches the secret stored in the AD forest. The usual fix is to make the client rejoin the domain, however, there’s a better solution.

First you’ll need Administrator access to the client. If you’re unable to log in as an Administrator (because the computer was locked by a domain user account before the secret got borked), reboot the client without any network access. This will allow the user to log in with the cached credentials, as the client is unable to discover that its secret differs from the secret stored in the domain.

You’ll need to download the Remote Server Administration Tools for Windows 7, and install it on the client. After installing, go to Programs and features in the Control Panel, select enable / disable windows features on the left pane, and navigate through:

Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tools

.. and find the choice that includes “console tools” (I don’t remember the exact name).

Start cmd as an administrator (right click, select run as administrator under Accessories), and use netdom.exe to sort the issue out properly.

netdom resetpwd /s:<server.domain.local> /ud:DOMAIN\user /pd:*

The user referenced by DOMAIN\user needs to have access to add / edit clients in the domain.

svn: OPTIONS of ‘‘: SSL handshake failed: SSL error: A TLS warning alert has been received. ()

If your svn client suddenly starts complaining about something similar to

svn: OPTIONS of '...': SSL handshake failed: SSL error: A TLS warning alert has been received. (...)

The reason might be that the host in the URL (https://example.com/ => example.com) doesn’t match the ServerName setting in the SSL host for your web server. You might not have configured this, so for Apache add:

ServerName example.com

.. and restart the server. It might just work again!