Windows Domain

  • Joining a Windows Server Std 2008 R2 (and Windows 7) system to a Samba (+LDAP) domain

    I needed to be able to join a virtual, KVM-hosted Windows Server Std 2008 R2 machine to a CentOS Samba domain with a Centos Directory Server password backend. It took me many hours to get this to work - unfortunately assuming stuff and using OLD information can lead you 'up the garden path'! These are the steps I took :

    1. Install a later version of Samba than is available from the CentOS repos. The latest is 3.4.5 as at 19 January 2010. I downloaded and used this extra repo - Download it to /etc/yum.repos.d. I also like to set enabled=0 in non-standard repo files just so that I use stock RPM's as much as possible.
    2. Then run yum --enablerepo=sernet-samba update samba

    3. Make sure net getlocalsidand net getdomainsid return the same result. See here for more info.

    4. By default samba attempts secure connection to your LDAP server using StartTLS. If you don't have this already setup, turn this off with the ldap ssl = none setting in /etc/samba/smb.conf.  If you don't then the join will not work - An 'Access is Denied' message will appear when you attempt to join. Once you have joining working, and you haven't already, then setup up secure connections between Samba and LDAP.

    5. *** THIS IS IMPORTANT *** Check, re-check and re-check again the /etc/ldap.conf, /etc/smbldap-tools/smbldap_bind.conf and /etc/smbldap-tools/smbldap.conf config files. These make or break your samba/LDAP setup. Make sure the base dn is correct, the directory manager binddn and binddnpasswd is correct. Make sure the nss_base settings are correct. Make sure the three files are consistent with each other. Then go and check again!!!!

    4. In the Windows Registry set/add the following keys. The bottom two are set the way shown by default but some sources on the internet suggest to turn them off - IF you do then the join will happen but you won't be able to login with a domain user - an error about "The trust relationship between this workstation and the primary domain failed" will occur. DO NOT TURN THESE OFF:




    5. I also changed the Local Security Policy of the joining Windows workstation, under Security Options. I set "Network Security: LAN Manager authentication level" to "Send LM & NTLM - use NTLMv2 session security if negotiated"

    Helpful Sites
    Samba's Wiki Page re Windows 7:
    Checking SID's are the same:
  • The trust relationship between this workstation and the primary domain failed - Method 1 using netdom

    This is a regurgitation of an articleon Implbits website:


    Use the following command to reset the trust relationship between a workstation and it's primary domain:


    netdom.exe resetpwd /s:<server> /ud:<user> /pd:*


    <server> = a domain controller in the joined domain

    <user> = DOMAIN\User format with rights to change the computer password



    Here are the full steps:

    You need to be able to get onto the machine. I normally just log in with the local Administrator account by typing, ".\Administrator" in the logon window. I hope you remember the password. If you’re creative and resourceful you can hack your way in without the password. Another option is to unplug the machine from the network and log in with domain user. You will be able to do disconnected authentication, but in the case of a reset machine, remember that you may have to use an old password. Your domain user’s cached credential has the same problem as the machine’s private secret.
    You need to make sure you have netdom.exe. Where you get netdom.exe depends on what version of Windows you’re running. Windows Server 2008 and Windows Server 2008 R2 ship with netdom.exe you just have to enable the Active Directory Domain Services role. On Windows Vista and Windows 7 you can get it from the Remote Server Administration Tools (RSAT). Google can help you get them. For other platforms see this link:"


    Extra steps if the machine is a domain controller:

    If the broken machine is a domain controller it is a little bit more complicated, but still possible to fix the problem.

    I haven’t done this for a while, but I think this works:
    Turn off the Kerberos Key Distribution Center service. You can do this in the Services MMC snap-in. Set the startup type to Manual. Reboot.
    Remove the Kerberos ticket cache. A reboot will do this for you, or you can remove them using KerbTray.exe. You can get that tool here:
    Post change steps. Do these in conjunction with 5 below. Turn the Kerberos Key Distribution Center Service back on before rebooting. You should reboot the domain controller and then force replication in the Active Directory Sites and Services MMC snap-in.
    Run netdom.exe to change the password.
    Open an administrative command prompt. On Windows platforms with UAC enabled, you will need to right-click on cmd.exe and select "run as Administrator".
    Type the following command: netdom.exe resetpwd /s:<server> /ud:<user> /pd:*
    Reboot the machine.

    Here is more information on netdom.exe:

  • The trust relationship between this workstation and the primary domain failed - Method 2 using Powershell

    It can be confusing when you go to log into a computer on your domain and you’re suddenly confronted with the message:

    The trust relationship between this workstation and the primary domain failed.

    Why would you get this message? Typically it happens when the computer you’re trying to log into has had it’s Active Directory account deleted (generally by accident). The Computer account on the Active Directory server has a special key that is generated for authentication reasons and it can’t be recovered if you’re not running a later version of Active Directory with undelete functions turned on.


    Unjoin and Rejoin the Domain?
    Administrators can get a bit worried when this happens because the usual solution is to unjoin the computer from the domain and then rejoin it. This can result in having users have to create new profiles and other problems that are at a minimum annoying. Thankfully, I can tell you NO, don’t unjoin and rejoin the domain!


    Powershell is your Friend
    Yes, as odd as it has been, Microsoft has seen the light of the command line world and given us Powershell. If you’re running Powershell v3 or later, you can solve your missing computer Active Directory account very simply. Just do the following:

    Make sure that you have PowerShell v3 installed. If you’re running Windows 7, like this computer was, you’ll need to do 2 steps to upgrade to PowerShell 3. Follow these steps for Installing Windows PowerShell and follow the steps in the section referencing the appropriate Windows version. If you have problems with this, feel free to leave a comment and I’ll do my best to help.
    Create the computer account in Active Directory. If the Active Directory computer account exists already, you can skip this step.
    After you have PowerShell 3 installed, run the following command on your untrusted computer:

    $PSCredential = Get-Credential
    Reset-ComputerMachinePassword -Server -Credential $PSCredential

    Once you enter your credentials and the command has completed, your computer should once again be connected to Active Directory and able to authenticate.