Securing Web Browsers Through Group Policy

9 09 2013

When developing a workflow to manage shared credentials, it’s important to take into account certain environmental factors that may cache credentials on their own. These factors can decrease security around shared credentials.

This week, we’ll focus on securing your web browsers through group policy.

Disable Password Caching for IE

Note: these instructions are specific to Windows Server 2012, however may be similarly applied in Windows Server 2008.

Caching of passwords and auto-completion of usernames and passwords used in IE can be disabled from the Group Policy Management Editor under:

  •  User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer

Here, you can disable “Turn on the auto-complete feature for user names and passwords.”

Group Policy Management Editor

This will also prevent users from re-enabling the setting:

Web Browser Caching 2

Restriction of password caching in Mozilla Firefox

Locking down settings in Firefox requires use of a third-party extension. One extension that we tested is called FirefoxADM, which provides adm files that add the ability to configure Firefox settings through Windows Group Policy. However, this only seemed to work with older versions of Firefox. Other extensions and tools exist, however are not officially supported by Microsoft for use in a Windows environment.

Disable Password Caching in Google Chrome for Business

Google Chrome for Business allows for policies relating to Google Chrome to be defined at either user or device level.

The Google Chrome Password Manager can be disabled at the user level by logging into the Google Admin console and navigating to the Settings menu. After selecting the “User Settings” menu, select an OU and under the Security settings disable Password Manager.

The Google Chrome Password Manager can be disabled at the device level through Windows GPO by adding two REG_DWORD values to the Windows registry at HKEY_LOCAL_MACHINE\Software\Policies\Chrome called PasswordManagerEnabled and PasswordManagerAllowShowPasswords, each with a value of 0×00000000.

Web Browser Caching 3

Disabling the Password Manager takes away the users’ ability to enable the “Offer to save passwords I enter on the web” setting in Chrome.

Web Browser Caching 4

Controlling credential caching in Mac OS X

Safari cannot be easily managed in a Windows environment, however Mac OS X Server provides a tool called Server Admin that may facilitate control of Safari settings in the OS X environment. Third-party tools are also available for this purpose.

Web Password Filler

Once you’ve secured your browsers, you can still utilize the credentials stored in Secret Server by using the Web Password Filler. For more information, see this blog post.





Importing Credentials into Secret Server Part Two of Two

3 09 2013

In our last post we discussed importing secrets manually into Secret Server using our Migration Tool and built in CSV and XML import. This week we are going review how to automatically import credentials into Secret Server.

Discovery in Secret Server

Discovery is a major feature in Secret Server with two main functions:

  1. Scan your network for local Windows accounts and import them as Secrets. With Discovery Rules, this process can be automated to run on a schedule, and new accounts will be imported based on a set parameters that you establish.
  2. Scan your network and pull in Windows services, attaching them as dependencies to current Secrets or creating new Secrets based on the particular account running the service.

How to Set Up Discovery

Setting up Discovery is simple.

  1. On the Administration>Discovery page, check the box enabling Discovery.
  2. Set the interval that you want Discovery to perform scans of the domain.
  3. Create a domain for Discovery to run against: on Administration>Discovery, click Edit Domains and then click Create New. Here you will enter the Fully Qualified Domain Name. Use an account that has access to all the machines you would like to discover and the ability to change the passwords for those accounts.
  4. Check the Enable Discovery box for the new domain and then click Save and Validate. Secret Server will confirm that it can reach your domain.

Once Discovery is turned on, it will start running scans throughout the network. This occurs in batches so as to not bog down your network.

Import Accounts using Discovery

  1. When the scans finish, click Discovery Network View on the Administration>Discovery page.
  2. You will see two tabs, one for local Windows accounts and another for service accounts. This page enables you to find the accounts you would like to import. It allows you to filter computers based on organizational unit (OU) and search for specific computers and accounts.
  3. Check the accounts you wish to import and click the import button. Secret Server will automatically create a Secret for each. You also have the option of changing the passwords for the accounts when the Secrets are created.

Using the API to Create Secrets

The final method of importing Secrets is to use our API to programmatically create the Secrets. The Secret Server API allows basic functions to be performed on Secrets, such as creating, deleting or modifying.

The API is especially useful when you have an existing script that already provisions accounts. Secret Server provides web service API calls that can be added to your existing script in order to create Secrets after your new accounts are provisioned.

After Secrets are imported, the API can also be used if you have third party applications that need credential access (i.e. the API can then be used to programmatically provide credentials stored in Secret Server). The API is also good for updating existing Secrets. For example, if your domain name has changed, you can use the API to quickly update all applicable Secrets to match the new domain.

Check out our Knowledge Base and API Guides located on the Secret Server technical support page for examples on how to utilize Secret Server’s API.





Get Credentials out of Code with Secret Server API

16 07 2013

A few years back, our engineers decided to solve a new password problem: Network credentials are not only used by people. Sometimes other programs need credentials to interact with the network too. Secret Server was already providing full audits of each user’s credential usage, why not create an API so programs could also use Secret Server for credential access?

Using scripts, Secret Server’s API allows third-party programs to access Secret Server programmatically. Secrets and Folders can be searched and retrieved, and new ones can be created. This not only provides a full audit trail of credential usage by third-party applications, but also improves security by getting credentials out of clear text within the application’s code.

Any developer can make use of Secret Server’s API for use in their scripts or to integrate with an existing software. It’s always great when companies use our APIs and share them with others. Here are a couple of examples:

Puppet Labs creates automation software for provisioning, maintaining infrastructure configurations, automating repetitive tasks and more. Steve Shipway, a Puppet Labs and Secret Server user, wrote a module for Puppet Labs that uses the Secret Server API to assist Puppet Labs’ configuration and provisioning tasks. The Secret Server API module for Puppet Labs is available online for free.

Devolutions’ Remote Desktop Manager provides a central location for managing remote connections, including Putty, RDP and Team Viewer. Through the Remote Desktop Manager integration with Secret Server, network admins can use their Windows Authentication credential to launch applications, providing greater network security.

Ready to start making your own third-party program integrations with Secret Server? Check out our KnowledgeBase for guidance.





Conventions for Naming Secrets

9 07 2013

When first adding Secrets to your Secret Server account, one of your questions might be, “What should I name my Secrets?” This is a great question and one that we recommend thinking about for any new Secret Server customer. Secret names should be descriptive, but should not reveal any sensitive data. An option for Administrators to ensure Secrets are easily identifiable in Reports and in searches is to use naming requirements. For example, UserName\DeviceName. Whatever naming convention you choose, it will simplify your experience in the long-term.

Once you create a name convention, you will want to be able to enforce the naming requirements. Secret Server can use Regex to validate a Secret name upon creation. This will ensure that Secret names will match a desired pattern. Naming patterns are assigned by Secret Template.

For this example, we’ll walk you through the steps set naming rules for a Secret Template by using the Windows Server 2008 R2 Local Admin Account Template. First, visit Administration > Secret Templates. Next, select the Windows Account and click Edit. The current Template configuration and fields will appear, and then you will want to click Change. Now, you can enter Regex. For this example, we want all Secrets using this Template to be named the following: admin\computername-PC

To enforce our chosen naming pattern we will use the following Regex: ^admin\\\w+-PC$

Now you can set the Error Message that will appear when users attempt to create a Secret using a name that does not match your chosen pattern. In this case, we’ll have the error message say “Secret Name must be admin\computerName-PC”

SecretNaming





Integrated Windows Authentication and Two-Factor Authentication

11 04 2013

In Google Chrome and Internet Explorer with Integrated Windows Authentication, enabled users are automatically signed in to Secret Server when they visit the site using their Active Directory credentials. This feature reduces the number of passwords that a user has to type, and the possibility of a forgotten password. This also allows domain administrators to specify a password policy that Secret Server will adhere to, such as password strength and password history.

Radius Configuration

Two-Factor Authentication in Secret Server forces users to enter another form of authentication on login, such as a pin or token. Secret Server comes with its own built-in email two-factor authentication, and supports the existing infrastructure to make use of RADIUS two-factor systems. This adds another layer of security to user accounts, however, it increases the number of steps required to access Secret Server. Using two-factor authentication helps prevent a scenario where a user might walk away from a workstation while logged in and an attacker could walk up to it and login to Secret Server.

B2





Sneak Preview: HSM Data Encryption with SafeNet

16 11 2012

We’re working with SafeNet, an industry leader in data protection, to bring hardware data encryption to Secret Server. We’re adding support for SafeNet’s Hardware Security Modules, or HSMs.

SafeNet LUNA

Pictured: SafeNet LUNA PCI HSM

SafeNet’s Luna PCI HSM (pictured) is FIPS 140-2 Level 2 and 3 compliant, bringing a new level of data protection to your enterprise.

When Secret Server is configured to use SafeNet’s HSM, Secret Server will no longer store the encryption key on the server or perform the actual encryption and decryption. Instead, the encryption key is stored inside the device, and the device itself performs the encryption and decryption. Secret Server at no point is aware of the keys being used to encrypt or decrypt data. All the encryption and decryption stays in the hardware.

 

When an HSM is available, Secret Server will allow selecting the encryption key storage location during installation.

Installation HSM

SafeNet’s HSM also allows redundant configuration of two or more HSMs to ensure zero loss of data and Secret Server is always available.

We are pleased to be adding this capability to Secret Server and have enjoyed working with the smart folks over at SafeNet. The SafeNet HSM support will be available in the next release of Secret Server.





Get passwords out of batch files and scripts

28 09 2012

Secret Server Enterprise Plus Edition has an Application Server API that can be used to get passwords out of your configuration files and scripts.  The idea is to authorize the application server to access Secret Server (this is done by installing the Secret Server Application Server API on the application server) – there is then a user account in Secret Server for the application server – this means you can then assign permissions for which Secrets it can access.

Here is an example of a batch file doing some FTP uploads with an FTP sync tool:

line01: @echo off
line02: echo —————————————-
line03: echo Uploading changes…
line04: echo —————————————-
line05: ftpsync-1.3.04\ftpsync.pl documents ftp://jsmith:passJgH47523@10.0.10.100/stage/mydocuments

Notice the embedded password in the file?  Not very secure or accountable.

Here are the steps to get rid of that embedded password:

  1. Create an Application Account user in Secret Server.
  2. Install the Secret Server Application Server API on the workstation or server where the script runs
    (the API is a jar file and the install is done from the command line …
    java -jar secretserver-jconsole.jar -i <username> <password> <URL to Secret Server>
    This will change the password on the Application Account to a random value and will lock the account usage to that machine.
  3. Create a new Secret in Secret Server with the password from the batch file.  Give the Application Account access through the permissions.
  4. Change the batch file to make the call to the API and use a variable for the password. (the 1587 is the secretid of the new Secret and “Password” is the field name)
    The value of the password is stored in the variable FieldValue which can be used in the FTP command using %FieldValue%.
  5. That’s it – no more embedded password!

line01: @echo off
line02: echo —————————————-
line03: echo Connecting to Secret Server API…
line04: echo —————————————-
line05: FOR /F “tokens=*” %%A IN (‘java -jar secretserver-jconsole.jar -s 1587 Password’) DO SET FieldValue=%%A
line06: echo —————————————-
line07: echo Uploading changes…
line08: echo —————————————-
line09: ftpsync-1.3.04\ftpsync.pl documents ftp://jsmith:%FieldValue%@10.0.10.100/stage/mydocuments

We could also look up the username “jsmith” from the same Secret instead of having it in the script too.

There are other benefits to getting the password out of the batch file:

  • The password can now be rotated by Secret Server on a schedule.
  • There is now a full audit trail in Secret Server for when this password is accessed and used.
  • The batch file can now be added to backups, source code control and documentation without fear of spreading the production password.

It is recommended that you lock down modification to the batch file on the server using ACLs in the operating system (to prevent batch file changes).  Ideally the server has limited access for users since it is a production environment anyway.

What other uses can you see for this technology?





Using a Web Launcher with Logmein

14 09 2012

Have you ever been in the situation where you needed to provide a full desktop to someone outside your organization? One way you might accomplish this is by creating a Logmein.com account allowing users to login remotely. A caveat to this solution is it requires external access to your Secret Server instance.

Follow these steps:

1. Create a Logmein account restricted to access only the target workstation.

2. Install the Logmein client on the target workstation.

3. Secure the internal workstation to include only the features you want users to use when accessed remotely.

4. Create a secret in a Secret Template that has the Web Launcher enabled. If you’re using stock Secret Templates the “Web Password” template will work just fine.

5. Enable the Web Launcher with these settings: Click Edit -> Launcher tab -> Configure Launcher Settings button -> Choose -> Type https://secure.logmein.com/login.asp for URL -> Finally click Test Launcher. If the launcher works, move on to Step 6. If the launcher doesn’t work, you may need to do some custom field mapping. Essentially the Email field from Logmein should be mapped to the username of the secret. Password is password, fairly obvious!

6. Create a user account in Secret Server that has read access to just this secret.

7. Hide the password from the users by clicking: Edit button for the Logmein account -> Security tab -> Edit button -> Check the Hide Launcher Password box -> Save.

Now, the target remote user should be able to login to Secret Server. When they do, they will have access to only this Logmein secret. Additionally, they will only be able to use the Web Launcher and not actually see the password. The end result is a remote user has access to a controlled internal system by simply logging in to Secret Server.

Note: The workstation being accessed remotely can be a virtual workstation. This would make it very easy to control content and access (if the virtual machine isn’t running, no one can access it).

Advantages:

  • This is very easy to use as it only requires a Secret Server account.
  • You’ll have an auditable history of when a user logged into Secret Server and the actions they took.
  •  Workstation login credentials don’t have to be shared or even visible.
  • This method of access works from multiple browsers and across operating systems and devices.




Secret Server and DoubleLock

13 09 2012

Do you have a need for additional security when storing your most sensitive data?

Where do you store the company’s banking account numbers and other critical financial data?  …top-level credentials for your customer database that contains Credit Card and Social Security numbers?  …credentials for classified system access?

When you need that additional layer of security within an already secure system, DoubleLock is your answer.  DoubleLock encrypts Secret data with an additional encryption key that is only accessible with an additional password that is unique per user, regardless of permissions or physical access to the machine running Secret Server. Private/public key encryption technology enables you to securely share access to the DoubleLock between users.

Benefits of enabling the DoubleLock feature include:

  • Secrets cannot be decrypted even if Secret Server is compromised.
  • Secrets cannot be decrypted even when someone is accidentally granted permissions to a Secret based on AD group membership.
  • DoubleLock provides an additional grouping of privilege to grant select individuals access to highly sensitive data.

There is one caveat to consider when using DoubleLock:

Resetting a forgotten DoubleLock password is irreversible and can result in permanent loss of the data. In the case that a user has sole access to a DoubleLocked Secret, the data will be lost and the Secret locked with that DoubleLock key will be deleted.  However, if another user has access to the Secret, they will need to re-assign you to the DoubleLock.

When resetting a DoubleLock password, a list of the assigned DoubleLocks and the Secrets they protect are displayed for the user.  Check that the secrets have at least one additional user with DoubleLock access.  This way, the data is not deleted due to a forgotten DoubleLock password.

To enable DoubleLock, a password will need to be created.  In Secret Server, click: Tools menu -> Create DoubleLock Password -> enter the desired Password (minimum 8 characters) -> Create Password.  Then, click on the Administration menu -> DoubleLock -> Create New button -> type a Name for your DoubleLock -> Save.

Now that a DoubleLock has been created, assign the appropriate users and secrets to the DoubleLock.  In more complicated environments, multiple DoubleLocks can be created.  Each of these DoubleLocks can be assigned their own set of users.  To assign DoubleLock to a secret, click the Edit button on the desired secret.  Then, click the Security tab -> check the Enable DoubleLock box -> select the appropriate DoubleLock in the dropdown menu -> Save.  Remember that the DoubleLock selected will already have a list of defined users.

As a safety net, always have at least 2 users for each DoubleLock to avoid the potential loss of data if the DoubleLock password has to be reset.





SSL Certificates, License Keys & More in Secret Server

27 08 2012

Do you have copies of your SSL Certificates, Licensing Data, and Support Documentation?  Of course!  Can you easily search for all of those files with a single term?  Maybe.  Is it well-organized, access-controlled, and verified?  Maybe not.

Secret Server supports the functionality above by simply building a Secret Template with the proper settings.  For example:  Instead of using DFS or a SharePoint plug-in to store your documentation and important files, why not leverage Secret Server?  You’ve already committed your Admin username and password.  By editing a Secret Template, you can easily create a designated file location for each workstation, server, and appliance in your network.  Once you’ve created the template, you’ll know precisely where all your documentation is stored.  When coupled with adequate Disaster Recovery plans (Microsoft SQL Clusters, Mirroring the database, or a frequent database backup), you’ve added additional layers of protection to your critical technical documents.

Storing documents in Secret Server has distinct advantages beyond access control and redundancy.  First, Secret Server admins can require fields to contain data before saving new secrets.  While you can’t control the quality of the documents that people might store – but at least you will know that a document was saved.  Second, these documents are encrypted in the Secret Server database.  Third, the documents can be relayed to a coworker or a third party with a simple http link.  (Note the previous blog post about this.)

Secret data saved using the "Hardware - Remote Desktop" Secret Template.

Secret data saved using the “Hardware – Remote Desktop” Secret Template.

Making a Secret Template may take some thought about what your organization finds useful.  However, once you’ve created a template, it’s very easy to edit, copy, and enhance.  One potential side benefit of structuring the above information is data in Reports.  Using some extra data points like I have in this Template may be of benefit in Secret Server Reports.

Thycotic’s Secret Template Gallery contains the content for the Secret Template I created above.  The Template can be found by searching “Hardware Remote Desktop” or by using this direct link.  Import this or any template by clicking Administration -> Secret Templates.  Paste the XML into the Import Secret Templates text box and click the Import button.

If you think you have a great and useful Secret Template, comment below!  We want to hear about it and what makes it useful.








Follow

Get every new post delivered to your Inbox.

Join 30 other followers