Can't save BitLocker key to Microsoft Account in Windows 10 when encrypting an external drive

1. Save the key to a file (can throw it away later).
2. Start encrypting the drive.
3. Run a command prompt with Admin rights.
4. You need to get the volume ID by typing "mountvol".
5. Now run the "bitlockerwizardelev.exe": "%SystemRoot%\System32\BitLockerWizardElev.exe" \\?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx}\ Y.
6. It will prompt the BitLocker GUI as Admin and save the key to your account.

Samurai Web Testing Framework

IGGY
One of the best security distros out there and part of my standard toolkit.

Microsoft Security Essentials

Microsoft Security Essentials provides real-time protection for your PC that guards against viruses, spyware, and other malicious software.
Security Essentials is simple to install, easy to use and always kept up to date. It’s easy to tell if your PC is secure - when you’re green, you’re good. It’s that simple.
Download is here.

Syncing DSRM & Domain Administrator Passwords

Setting the password for DSRM is done during setup of AD.
Under W2K3 this was complicated and required you to use NTDS. This has been addressed in W2K8. Download this hotfix and after installation, run the following command to sync the passwords.

ntdsutil "set dsrm password" "sync from domain account <DomainAdminAccountName>" q q

Microsoft IPSec Diagnostic Tool

Info and download are here.

BitLocker Drive Preparation Tool

If you have considered running Bitlocker, Microsoft's drive encryption tool, but didn't want to bother with what it would take to setup your drives properly to support it, then you are now in luck if you are running Windows Vista Ultimate edition or Enterprise edition. Microsoft has made a tool just for you. The Bitlocker Drive Preparation Tool is designed to help convert your existing install of Windows Vista into a setup that supports Bitlocker drive encryption. Read more here.

Credits: WindowsConnected.

The Server and Domain Isolation Using IPsec and Group Policy Guide

This guide provides business-oriented justification as well as technical guidance for logically isolating servers and domains from certain types of network traffic through the use of IPsec filters and Group Policy.

How Windows stores your passwords and how these passwords can be attacked

Nice article from Jesper Johansson. You can read it here.

Circumventing Group Policy Settings

Group policy settings are an integral part of any Windows-based IT environment. If you are a network administrator you use them to enforce corporate security and desktop management policy, and if you are a user you have almost certainly been frustrated by the limitations imposed by those policies. Regardless of which you are, you should be aware that if the users in your network belong to the local administrator's group they can get around policies any time they want.

There are two steps to circumventing a group policy setting: identifying the setting's location and preventing the setting from being applied.

Read more here on Mark's Sysinternals blog.

Access Based Directory Enumeration tool

Just a quick link to the tool itself. It was written by DuWayne Harrison at Microsoft in the US. Please be aware that there is absolutely no support from PSS and all standard disclaimers apply as per resource kit tools. In other words, any use you make of this utility is entirely at your own risk.

(Eeeeuh what's this?) ABDE is used for hiding folders in shares so users who don't have rights on these folders won't see them. The impact is clear. No more fiddling in restricted directories.

Stop using Passwords, Use Pass Phrases!

Do you hate remembering all those freaky passwords, if possible meeting password complexity requirements? I do. There are about 10 passwords I have to remember/change on regular basis, not speaking the ones I use for Blogger, my Hotmail, Gmail etc...
While surfing the web I found an interesting article on Robert Hensing's Blog. He recommends using Pass-Phrases instead the password of 7 or more letters and numbers. (If using less you're hackable in a sniffs time)

What are according to Robert the advantages of using Phrases?

1. They meet all password complexity requirements due to the use of upper / lowercase letters and punctuation (you don't HAVE to use numbers to meet password complexity requirements).

2. They are so freaking easy for me to remember it's not even funny. For me, I find it MUCH easier to remember a sentence from a favorite song or a funny quote than to remember 'xYaQxrz!' (which b.t.w. is long enough and complex enough to meet our internal complexity requirements, but is weak enough to not survive any kind of brute-force password grinding attack with say LC5, let alone a lookup table attack). That password would not survive sustained attack with LC5 long enough to matter so in my mind it's pointless to use a password like that. You may as well just leave your password blank.

3. I dare say that even with the most advanced hardware you are not going to guesss, crack, brute-force or pre-compute these passwords in the 70 days or so that they were around (remember you only need the password to survive attack long enough for you to change the password).

Want to know more? Read it here.

Security Configuration Wizard in Windows Server 2003 Service Pack 1

It is no secret that Microsoft needs to work on security for their operating systems. It is also no secret that many of their attempts to date have not worked as seamlessly as they have originally intended. However, Microsoft is finally onto something with the introduction of the new Security Configuration Wizard, which is bundled with Windows Server 2003 service pack 1.
The Wizard works in conjunction with security policies. The resulting security policies can be applied to any server on your network, allowing for consistency and stability of the security settings on all servers. The security policies are created based on a baseline server. Once the security policy is created, it can be applied to the baseline server, or any other server in the organization.
In this article, we will go over the options that you have as you maneuver through the Security Configuration Wizard, starting with the options of how to manipulate the security policies. We will also cover key areas that are targeted by the Wizard, including services, network security, registry settings, administration and other server responsibilities. Read more here.

How to disable applied GPO's with GanoTools KillPol

This tool from GanoTools enables you to temporarily remove policy restrictions for the current user. It is a useful tool for helpdesk personal in networks with restricted policies. Download is here.

Analyze System Security Settings in Windows 2000

Browsing the latest additions to the Microsoft TechNet Site, I found an interesting article about analyzing system security in Windows 2000. This step-by-step article describes how you can use the Security Configuration and Analysis snap-in to analyze and configure security on a Windows 2000-based computer.

Windows 2003 Security Configuration Wizard

Michael Kleef, Australian member of MSFT, has made a streaming BlogCast on the new Security Configuration Wizard in Windows Server 2003. If you're IT Pro, it's worth seeing. The link is here.

Beat Hackers with a Hackerbasher Site

On any given morning, a look through my production Web Server's logs will show that my server farm is under a barrage of attacks. Hackers and crackers with automated IP port scanners can swamp a Web site with bogus requests and failed logons. However, at the Microsoft TechNet site you can now find a document which describes how to fight back. The link is here. Hackerbash them all Marnie.

Securing Administrative Groups and Accounts in Active Directory Part 5

Moving Service Administrator Groups into the new OU: Move the following groups from their current location in the Users and Groups OU in your controlled subtree: 1. Domain Admins and any nested subgroups. 2. Enterprise Admins and nested subgroups. 3. Schema Admins and nested subgroups. 4. Any groups that are nested in the Domain Administrators, Server Operators, Backup Operators, or Account Operators groups. 5. Any group that has delegated rights so it's users have Service Administrator rights. The built-in groups Administrators, Server Operators, Account Operators, and Backup Operators cannot be moved from their default container to the subtree. However, built-in groups are protected by default in Windows Server 2003 by the AdminSDHolder. If your organization has not yet created any nested subgroups or delegated service administration rights to any group, you only move the Domain Admins, Enterprise Admins, and Schema Admins. Tasks: 1. Log on as a member of the Domain Admins group, and open Active Directory Users and Computers. 2. In the console tree, click Users. 3. In the details panel, right-click Domain Admins, and click Move. 4. In the Move box, double-click Service Admins, click Users and Groups, click OK. 5. Verify that the Domain Admins group is in the Users and Groups OU. 6. Repeat the procedure for all listed service administrator groups. If you have nested groups under the builtin groups such as Administrators, or other groups you previously assigned administrative privileges, their location might not be the Users container.
Moving Service Administrator User Accounts into the new OU: Move the following user accounts from their locations in the directory into the Users and Groups OU in your subtree: 1. All administrative user accounts that are members of the service administrator groups. This includes the renamed Domain Administrator account. 2. The decoy administrator account you created earlier. Each service administrator should have two accounts, one for service administration duties and one for data administration and typical user access. Place the administrative user accounts in the Users and Groups OU in your controlled subtree. If these accounts exist elsewhere in the directory, move them into the subtree. The regular accounts for those administrators should not be placed in this controlled subtree. Regular user accounts remain in their original location (Users) or in an OU created by your organization. Tasks: 1. Log on as a member of the Domain Admins group, and open Active Directory Users and Computers. 2. In the console tree, click Users. 3. In the details pane, right-click the name of the renamed administrator account, and then click Move. 4. In the Move box, double-click Service Admins, click Users and Groups, and click OK. 5. Verify that the account is now in the Users and Groups OU. 6. Repeat the procedure for all service administrator accounts listed above. If you have previously created administrative accounts or other OUs, their location might not be the Users container.
Moving all the Administrative Workstation Accounts into the Admin Workstations OU: Move the computer accounts for workstations used by administrators into the Admin Workstations OU in the subtree. WARNING!!!: Do not move domain controller accounts out of the default Domain Controllers OU. Moving DC's disrupts the application of domain controller policies to all domains. Tasks: 1. Log on as a member of the Domain Admins group, and open Active Directory Users and Computers. 2. In the console tree, click Computers. 3. In the details pane, right-click the name of the workstation used by an administrator, and click Move. 4. In the Move box, double-click Service Admins, click Admin Workstations, and click OK. 5. Verify that the computer account is in the Admin Workstations OU. 6. Repeat this for all administrative workstations.
End of Part 5.

Securing Administrative Groups and Accounts in Active Directory Part 4

Strengthening Security on Service Accounts and Groups: By creating a subtree containing all service administrator accounts and the administrative workstations that they use, you can apply specific security and policy settings to maximize their protection.
Creating the OU Structure for the Controlled Subtree: To create the subtree, create three OUs: 1. Service Admins, under the domain root, which will hold the following two sub-OUs: 2. Users and Groups, to hold administrative user and group accounts. 3. Admin Workstations, to hold administrative workstations. Tasks: 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. In the console tree, right-click the domain name, point to New, and click Organizational Unit. 3. In the Name box, type Service Admins and click OK. 4. In the console tree, right-click Service Admins, point to New, and click Organizational Unit. 5. In the Name box, type Users and Groups and click OK. 6. In the console tree, right-click Service Admins, point to New, and click Organizational Unit. 7. In the Name box, type Admin Workstations and click OK.
Setting the Permissions on the Controlled Subtree OUs: Doing the following can help you limit access to the controlled subtree, so that only service administrators can administer the membership of the service administrator groups and their workstations. Tasks: 1. Log on as a member of the Domain Admins group, and open Active Directory Users and Computers. 2. On the View menu, select Advanced Features. 3. Right-click the Service Admins OU, and click Properties. 4. On the Security tab, click Advanced to view all of the permissions that exist for the OU. 5. Clear the Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here check box. 6. In the Security dialog box, click Remove. This removes the permissions that were inherited from the domain. 7. Remove the remaining permissions. Select all of them and click Remove. 8. For each group listed in the Name column of the list below, add a permission entry to agree with the Access and the Applies to columns as shown in the list. To add an entry, click Add, then in the Select User, Computer, or Group dialog box, click Advanced. In the expanded dialog box, click Find Now. In the search results box, select the group name and click OK twice. This brings up the Permission Entry dialog box, where you can select he Access and Applies To items to agree with the list. List: Allow, SYSTEM, Full Control, This object and all child objects. Allow, Enterprise Admins, Full Control, This object and all child objects. Allow, Domain Admins, Full Control, This object and all child objects. Allow, Administrators, Full Control, This object and all child objects. Allow, Pre–Windows 2000 Compatible Access, List Contents, Read All Properties, Read Permissions, User objects. Allow, Pre–Windows 2000 Compatible Access, List Contents, Read All Properties, Read Permissions, InetOrgPerson objects. Allow, Enterprise Domain Controllers, List Contents, Read All Properties, Read Permissions, This object and all child objects. Allow, Authenticated Users, List Contents, Read All Properties, Read Permissions, This object and all child objects. That's it. Now we are going to move all accounts and their workstations to the Subtree. I wil blog that piece this evening.
End of Part 4.

Securing Administrative Groups and Accounts in Active Directory Part 3

Securing Guest: The Guest account allows the users who do not have an account in the domain to log on to the domain as a guest. This account is disabled by default. Leave it like that. But just to be sure we will hide the account for protection against any unauthorized access. Use fictitious first and last names, in the same format as other user names. Tasks: 1. Log on as a member of the Domain Admins group, and open Active Directory Users and Computers. 2. In the console tree, click Users. 3. In the details pane, right-click Guest, and click Rename. 4. Type the fictitious name and press Enter. 5. Right-click the new name, and click Properties. 6. On the General tab, delete the Description and type in a description to resemble other user accounts or just leave it blank. 7. In the First name and Last name boxes, type the fictitious name. 8. On the Account tab, type the new User logon name, using the same format you use for other user accounts. 9. Type this new logon name in the User logon name (pre-Windows 2000) box, and click OK. 10. Verify that the account is disabled. The icon should be red with an X over it. If it is enabled, right-click the new name, and click Disable Account.
End of Part 3.

Securing Administrative Groups and Accounts in Active Directory Part 2

Creating a New User Account with Domain Admins Credentials: If you do not already have a user account that is a member of the Domain Admins group, other than the standard Administrator account, create one that you will use to perform the tasks. As the administrator of your network, you will use this new account only when you need to perform tasks that require Domain Admin credentials. Do not remain logged on with this account after you finish performing these tasks. Create another user account for data management and day-to-day tasks as running Microsoft Office and sending and receiving e-mail, but do not add that user account to the Domain Admins group. Tasks: 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. Right-click the Users container, click New, and then click User. 3. Type the First name, Last name, and User logon name, and then click Next. 4. Type and confirm the user password, clear the User must change password at next logon check box, and then click Next. 5. Review the account information and then click Finish. 6. With the Users container selected, in the details pane (right pane), double-click the Domain Admins group. 7. Click the Members tab. 8. Click Add and then, in the Select Users, Contacts, or Computers dialog box, type the user logon name of the administrative account you just created, and then click OK. 9. Verify that your new account appears as a member of the Domain Admins group.
Protecting the Administrator Account: All installations of Active Directory have an account named Administrator in each domain. This account cannot be deleted or locked out. In Windows Server 2003, the Administrator account can be disabled, but it is automatically re-enabled when you start the computer in Safe Mode. A evil user attempting to break into a system would start by attempting to try to obtain the password for the all-powerful Administrator account. For this reason, rename it and change the text in the Description to eliminate anything that indicates that this is the Administrator account. In addition, create a decoy user account called Administrator that has no special permissions or user rights. Always give the Administrator account a long, complex password. Use different passwords for the Administrator and DS Restore Mode Administrator accounts. Tasks: 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. In the console tree (left pane), click Users. 3. In the details pane (right pane), right-click Administrator, and then click Rename. 4. Type the fictious first and last name and press Enter. 5. In the Rename User dialog box, change the Full name, First name, Last name, Display name, User logon name, and User logon name (pre-Windows 2000) values to match your fictitious account name, and then click OK. 6. In the details pane (right pane), right-click the new name, and then click Properties. 7. On the General tab, delete the Description "Built-in account for administering the computer/domain" and type in a description to resemble other user accounts. Note: This procedure changes only the default Administrator account's logon name and account details, which someone can see if they manage to enumerate a list of accounts on your system. The procedure does not affect the ability to use the DS Restore Mode Administrator account to start Directory Services Restore Mode. Remember, we have 2 different accounts.
Creating a Decoy Administrator Account: You are going to hide the default Administrator account. Hackers who are using password attacks on the Administrator account can be fooled into attacking an account with no special privileges. Tasks: 1. Log on as a member of the Domain Admins group, and then open Active Directory Users and Computers. 2. Right-click the Users container, click New, and then click User. 3. In First name and User logon name, type Administrator and then click Next. 4. Type and confirm a password. 5. Clear the User must change password at next logon check box. 6. Verify that the decoy account is created and click Finish. 7. In the details pane (right pane), right-click Administrator, and then click Properties. 8. On the General tab, in the Description box, type Built-in account for administering the computer/domain, and then click OK.
End of Part 2.