Security

  • To enable the administrator (that is disabled by default from Windows 7 onwards):
    net user administrator /active:yes
  • It's a good idea to encrypt your backups, particularly if you take them offsite (and you SHOULD!).

    1. Partition your external usb hard drive as normal: fdisk /dev/disk/by-id/usb-external_drive
    2. Encrypt the created partition: cryptsetup luksFormat /dev/disk/by-id/usb-external_drive-part1 /etc/volume_key
    3. Open the encrypted partition: cat /etc/volume_key | cryptsetup luksOpen /dev/disk/by-id/usb-external_drive-part1 EncryptedBackup
    4. Create a filesystem in the opened (mapped) encrypted partition: mkfs -t ext4 /dev/mapper/EncryptedBackup
    5. Mount the filesystem to check that it works: mount /dev/mapper/EncryptedBackup /mnt/backup
    6. Umount the filesystem once finished: umount /dev/mapper/EncryptedBackup
    7. Close the encrypted partition: cryptsetup luksClose /dev/mapper/EncryptedBackup

    FreedomIT-Backup
  • 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: http://technet.microsoft.com/en-us/library/ee649281(WS.10).aspx"

     

    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: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17657
    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: http://support.microsoft.com/kb/325850

  • 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.

    Source: https://www.prolved.com/trust-relationship-workstation-primary-domain-failed/

  • There are 2 parts to getting password-less, key-based ssh login to work. The first is to generate ssh keys for the user you are going to be accessing the remote host fromi.e. your localmachine. You then copy the public key of this local user to the remoteuser you want to login to the remote machine as. These are the steps to take:



    1. Generate a public key pair on the local machine:

    $ ssh-keygen -t rsa

    This will generate a couple of files in ~/.ssh. You can/should skip this step if this has already been done.



    2. Use the ssh-copy-id script to copy the local public key to the remote user:

    $ ssh-copy-id -i ~/.ssh/id_rsa.pub user@host -p 3000

    Make sure you just copy the .pub file. The -p 3000 is only necessary if you are using a non-standard ssh port.



    3. Then try logging into the remote machine - you shouldn't be asked for a password! 


    BTW, you have several  types of authentication encryption available with SSH: rsa, dsa, ecdsa, ed25519

  • I had a situation where adding an Office 365 account to Outlook 2016 would produce the following window when asking for the user credentials:
    windows security empty window
    i.e. No entry fields for the login or password - huh?!?!?!
     
    After weeks of googling, letting it sit for a while, more googling, letting it sit for a while, even more googling I stumbled upon a Microsoft Technet forum page that hinted at the C:\ProgramData\Microsoft\User Account Pictures\user.bmp file not being to Windows liking. This rang a bell since as part of my setting up the customers Windows 7 DVD image for install I had made a custom user tile.
     
    Once I had opened the user.bmp in MS Paint and resaved (as a 24-bit Windows Bitmap File) all was good! I retried the Outlook 2016 Office 365 and BOOM! the User Tile, Login Name and Password all displayed, waiting for entry.