binaryfactory.ca

I’ve spent some time in the last weeks testing Cyber-Ark’s Enterprise Password Vault. First of all, let me say that I am in no way associated with them, and that this post reflects only my opinion of the software, and not that of any of my clients. This is not a review of the tool, but a bit of information on it and on why everyone should think about using such a solution to secure credentials and become compliant with various laws, guidelines, best practices and policies.

What’s Cyber-Ark Enterprise Password Vault?

Cyber-Ark’s password management environment is made out of multiple separate, secure pieces. At the core of the solution is the Cyber-Ark Vault itself. This server runs on a secured Windows server OS, with no standard services running, and with multiple security layers added. This machine can be considered as an “appliance”, as it is very different from a stock Windows environment. This is what will store files, which in the case of the Enterprise password vault, represent passwords. The vault can be highly available, in a cluster, and replicated as well.

In order to use those files, an interface is needed. The best way to do this is using the Password Vault Web Access, which resides on a web server and communicates with the Vault using proprietary protocols. This allows all systems administrators, operators, developers, etc, to access the vault without needing particular client software.

The third important block is the CPM (Central Password Manager), which will act as the enforcer of policies and as a bridge between the vault containing the accounts and the machines where they are used, when necessary.

Why should it be used?

A solution such as this one should be used at least to store “generic” accounts, while providing separation of duty, auditing, and ease of management. A good example would be the built-in Administrator account of an Active Directory domain. In many cases, the enterprise will want to keep this password somewhere, in case it is ever needed. However, if anyone knows it, there can be no traceability proof if something is done using it.

Companies often design complex pen and paper based systems to store these accounts, often in separate parts, in different safes, in different locations. This is all well until there are just too many generic accounts to keep track of. By using a good password vault product, you should be able to separate duties between password owners and users. Allow management to approve requests for viewing the passwords, allow sysadmins to reset some passwords but not others, and most importantly, log every access to those passwords.

Once someone has seen the password, it is important that it be changed. This is where the CPM comes handy. It is able to change passwords for multiple platforms. Coupled with the ability to delegate only “connect” access (basically, establishing a direct RDP or SSH session with the credentials without showing the password), it can be used to manage a list of passwords that should never be known by anyone until they need to be used. This can also be used to share accounts on systems that do not support multiple users. By changing the password every time it is used, and logging everything, even an appliance that only has a “root” user now has some traceability.

Another great improvement to security that can be made is proper management of service accounts. Many service accounts in environments are set to not expire, as they are to be managed manually.. this means that a lot of manual labor will be done managing them, or in many cases, that they will simply not be managed. Now, with a product such as this one, you can discover what service accounts are being used for what service on what server, as well as enable central management. Yes, this means that it can connect back to Windows servers (among others) and change the passwords used to start up services so that they match. This effectively means that service accounts could be set up with a temporary password during installation, and once managed by the tool, never seen or known again.

Do yourself a favor, and start studying those solutions. Start by storing “generic” and built-in administrative credentials, and work your way up to shared accounts and service accounts. Once they are all in the vault, you can start experimenting with automated management features. It is better to start now and have something ready to use than to wait until something bad happens and then do it in a hurry..

To get facetime working on your firewall you need to be sure some ports can be used. For most home users this won’t be a problem but it may be different at work. Here is the Apple KB Article on it :

http://support.apple.com/kb/HT4245

If the Wi-Fi network router that you are connected to uses a firewall or security software to restrict Internet access, contact the network administrator and reference this technical article. To use FaceTime on a restricted Wi-Fi network, port forwarding must be enabled for ports 443 (TCP), 3478–3497 (UDP), 16384–16386 (UDP), and 16393–16402 (UDP).

Make sure those UDP port ranges have a good priority in your QoS configuration and you should be good to go. It is worth noting that DNS and HTTP must be open to the outside as well, but they are probably used only to establish the call (same for HTTPS/443) so the QoS config should not matter.

Depending on how you use Active Directory in your organization, you may be setting a lot of security policies on workstations, and some of these settings can be problematic during the automated build of computers.

A few workarounds exist to avoid applying those to the workstations being imaged:

* Create a temporary OU for the computer account, and move it to the proper location once the build is done
* Change the order of the steps in your build to avoid issues caused by security settings
* Configure a GPO to override the settings that need to be set only during deployment, and filter that only to machines being used.

For multiple different reasons, I had to use the last option. It is a rather clean option, as it doesn’t involve moving computer accounts after the build or any chances on the domain during the imaging process, other than joining the machine, which is great.

One word of notice: Make sure whatever you are overriding is not a must for security and is simply an “annoyance”, because eventually (within a few minutes probably), a user WILL figure out how you’re doing the filtering and WILL apply it to his own machine, in order to bypass some security settings.

Only a few steps are involved :

1) Create a GPO that will set the values to what they need to be during the build (don’t link it yet)

2) Create a WMI filter called “BoxBeingBuilt” or something similar. Have it do a query on something you know is true only during imaging. If you can’t find anything reliable, do something like this:

Select * from Win32_Environment Where Name = “BuildinDaBox”

3) Ensure your built process sets a system variable with that name at the beginning, and removes it at the end.

Tada!

Having issues pushing SCOM through the Windows firewall?

You opened the Remote Administration exception, you can ping it, you can browse shares, file and print sharing is enabled, yet it still fails?

There is one thing I have not seen documented in the SCOM installation/deployment guides: The agent actually adds an exception for itself when it runs, so if you block local exceptions (What’s the point of having a GPO for the firewall config on your serves if you don’t?) , it will fail.

Add this to your Firewall policy, as a program exception:
%SystemRoot%\422C3AB1-32E0-4411-BF66-A84FEEFCC8E2\MOMAgentInstaller.exe

Be sure to open it for the proper IPs only for added security. Then try to push it again..

Good luck!

If you are trying to perform EFS recovery by backing up encrypted files on a client machine and sending the backup file to a dedicated recovery workstation, remember this:

1) You need to be a local admin while performing the backup, and the restore, in order to back up the data stream even though you don’t have access to the encrypted files.

2) If a policy is disabling EFS on the recovery workstation, ntbackup won’t tell you that it can’t create the encrypted files because EFS is disabled. No. It will simply SKIP the files. So if you have files that get skipped, try to manually create a folder and encrypt it. It has to work else you will not be able to restore the backup properly..