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.





Sneak Preview: Secret Server Launcher for Mac

11 09 2012

The Thycotic Dev Team is hard at work with new functionality for Mac!  While I don’t have all the details, I do have a few items I can share.  Currently, we’re looking at an “end-of-Q4 2012” release date.  This date may slip, but it’s accurate for now.

Details I can share:

  • The Launcher will support Safari, Firefox, and Google Chrome.
  • The underlying technology uses is a NPAPI plugin. A quick install of a plugin is all it takes to enable the launcher for Mac.
  • Will support SSH and a built-in SSH client will be used.
  • Will support Microsoft Remote Desktop provided the Mac Remote Desktop application is installed.  See Figure 1 for the screenshot of Remote Desktop.  Figure 2 shows the Launcher Helper application in Firefox.

Figure 1

Figure 2

Features due out after the initial release (available in later updates):

  • Custom Launchers will be available in a subsequent update.  Remote Desktop and SSH will be the only launchers supported initially.
  • Session Recording functionality will be available in a subsequent updates.

The Dev Team is interested in hearing your comments, please post your questions and thoughts below!





Group Management Server Scales for Enterprise

5 09 2012

Wait, what is Group Management Server?!

Group Management Server is Thycotic Software’s brand new self service Active Directory group management tool.  IT Admins can designate Group Owners to control Active Directory Security Group and Distribution Group membership.  Reporting and full audit trails are maintained throughout the system on group management activities including adding, deleting, editing user group membership. These audit trails can be used during security audits to demonstrate compliance.

Group Management Server can be installed quickly and does not require Active Directory Schema Extension.  Even very large Active Directory environments can be quickly synchronized and managed from an easy-to-use and secure web interface.  Implementing robust Role Based Access Control and an approvals workflow, Group Management Server can automate IT Admin functions to tighten security, minimize risk, and reduce labor costs associated with managing group membership.

Let’s get back to how Group Management Server scales for the enterprise…

One of the highlights in Group Management Server is the performance during Active Directory synchronization.  Active Directory synchronization is a process in which Active Directory data (groups and users) are populated in Group Management Server.  The synchronization process makes Active Directory group management tasks lightning fast, as opposed to waiting on the Active Directory Users and Computers application to slowly search for the correct group.  In our testing, synchronization with 6 domains (one domain contained nearly 150,000 groups and 100,000 users) was completed in well under 5 minutes.  See figures 1-3 below for before and after screenshots of Active Directory synchronization with Group Management Server.

In Figure 1, this Group Management Server instance manages groups in six domains.  These domains range in size from small (250 objects) to large (100,000+ objects).  Note that domain synchronization has been started at 11:34:08 AM (highlighted in red).

Figure 1

In Figure 2, synchronization has completed for all six domains at 11:38:55 AM.  The elapsed time for the synchronization was
4 minutes and 47 seconds!

Figure 2

In Figure 3, domain statistics are displayed for synchronization.  In less than 5 minutes, Group Management Server synchronized more than 160,000 Active Directory groups and nearly 100,000 user objects spread over six separate domains.

Figure 3

Setting up Active Directory synchronization with Group Management Server

To synchronize with Active Directory, log in as an Administrator for Group Management Server.  Then click Administration -> Active Directory.  Click on the New Domain button and fill out the fields with your specific domain information and click Save.  Group Management Server will begin to synchronize with the newly added domain.  As with test example above, synchronization will take a few minutes depending on the number of groups and other objects in your domain.

Group Management Server information and resources

Try it here:  http://www.thycotic.com/products_groupmanagementserver_try.html

Support:  http://www.thycotic.com/products_groupmanagementserver_support.html

Forums:  http://www.thycotic.com/products_groupmanagementserver_forums.html








Follow

Get every new post delivered to your Inbox.

Join 30 other followers