FastPass Password Manager · The intended operation here is to have two frontend servers for...

FastPass Password Manager Version 3.4.3

Implementing for High Availability


Status: Final of 10

Date: July 24, 2013

Document Classification Public

Document Revision D

Document Status Final

Document Date March 18, 2013

The specifications and information in this document are subject to change without notice. Companies, names, and data

used in examples herein are fictitious unless otherwise noted. This document may not be copied or distributed by any

means, in whole or in part, for any reason, without the express written permission of FastPassCorp A/S.

© 2004–2013 FastPassCorp A/S. All rights reserved. Lyngby Hovedgade 98, 2800 Kongens Lyngby, Denmark.

http://www.fastpasscorp.com/.

FastPass Password Manager is a trademark of FastPassCorp A/S. All further trademarks are the property of their respective

owners.

Limited Warranty

No guarantee is given for the correctness of the information contained in this document. Please send any comments or

corrections to [email protected].


Status: Final of 10

Date: July 24, 2013

1. Introduction ..................................................................................................................................................................... 4

1.1 Purpose ................................................................................................................................................................... 4

1.2 Audience ................................................................................................................................................................. 4

1.3 How to use this document ...................................................................................................................................... 4

2. Implementing active/slave functionality multiple servers (No Sync/Selective Password Reset) .................................... 5

2.1 Implementing active/slave functionality multiple servers with Sync/Selective Password Reset .......................... 6

2.2 Needed firewall port openings: .............................................................................................................................. 8


Status: Final of 10

Date: July 24, 2013

1. Introduction

The document was last updated in February 2013 and is now targeted FastPass Password Manager Version 3.4. series

1.1 Purpose

The purpose of this document is to describe how to implement FastPass in a High Availability environment.

1.2 Audience

The intended audience of this document are personnel responsible for installing and maintaining the solution.

1.3 How to use this document

This document can be read in its entirety.


Status: Final of 10

Date: July 24, 2013

2. Implementing active/slave functionality multiple servers (No

Sync/Selective Password Reset)

Password Manager is quite easy to setup in a Master/Slave setup. The below describes in detail how this is setup.

Description

The intended operation here is to have two frontend servers for failover operation. Both servers points at the Master for

obtaining data. In the event of a failure in on the Master server the Slave can take over the operation.

The following conditions will have to be met for the setup described here to work:

• For the Windows Client to work the SSL certificate coming from the Load Balancer must be trusted by the client

and the servername in the certificate must be the same as the requested one.

• The servers has to be members of a domain (could be any domain)

• The Service users has to be domain users (Adam, gateway and iis)

To implement this solution please follow these guidelines:

On the Master:

1. Install Password Manager as usual (use 127.0.0.1 as the servername for ADAM)

2. Edit the registry key HKEY_LOCAL_MACHINE\SOFTWARE\FastPassCorp\Password Manager\DATA, adding the

Slave’s IP address to the Network entry.( Network_GUID_GatewayCallerList)

3. Edit the file Configuration\FastPassServer\CWConfig.xml, adding the IP address from the Slave

On the Slave

1. Install the ADAM instance as a replica of the Master server

2. Run the backend installer. (AdamInstaller and Serverinit should NOT be run)

3. Export the registry HKEY_LOCAL_MACHINE\SOFTWARE\FastPassCorp to a file from the Master machine and import

it on the slave.

4. Edit the key HKEY_LOCAL_MACHINE\SOFTWARE\FastPassCorp\Password Manager\InfraStructureGateway\

InfrastructureGateway_URI and set the servername to the slaves name

5. Copy all the configuration files to the Slave(All file found under <INSTALLPATH>\Configuration\)

6. Edit the Configuration\FastPassClient\CAConfig.xml setting the servername to the slaves name


Status: Final of 10

Date: July 24, 2013

7. Edit the Configuration\FastPassAdministrationClient\admCAConfig.xml setting the servername to the slaves name

Now the two servers are alike. For keeping the servers uptodate the following should be copied:

• Files: Configuration\FastPassGateway\GatewaySettings.dat

• Files: Configuration\FastPassGateway\FastPassServer\FastPassEngine\*

• Registry: HKEY_LOCAL_MACHINE\SOFTWARE\FastPassCorp\Notification Service\NotificationMark

• Registry: HKEY_LOCAL_MACHINE\SOFTWARE\FastPassCorp\Statistics Service\LastExecutedEventID

• Registry: HKEY_LOCAL_MACHINE\SOFTWARE\FastPassCorp\Statistics Service\LastExecuion

In the event of a takeover follow this procedure:

1. Make sure the FastPass services on the Master are all shutdown

2. On the Slave Open ADSI edit editing OrganisationID\FastPassGateway setting the servername for

GatewayHostname and GatewayUri to the slaves servername (If the servername used for the FastPass Servers are

the same this step can be omitted)

3. Start-up all the services on the Slave and it is up and running.

4. On the Client machines edit the Configuration\FastPassClient\CAConfig.xml – setting the servername to the Slaves

name (by using dns to point at the other server this step can be omitted)

5. Restart iis (iisreset on the two Frontend servers)

The result of the take-over is that the Slave actually acts as the Master. When the Master comes back online – make sure

that the FastPass Services are kept shutdown. Once the server is up, ADAM will automatically replicate the new data from

the Slave to the Master. Following the above procedure (changing the roles) will make the Master operational again. Adam

replication is almost instantaneous but waiting 15 min. from the takeover should make sure that the data is updated.

2.1 Implementing active/slave functionality multiple servers with Sync/Selective

Password Reset

To proceed it is important that the previous section (installation without Sync/Selective Password Reset is understood). The

big difference in these setup’s are the SQL-server


Status: Final of 10

Date: July 24, 2013

Description

The Synchronization/Selective Password Reset part stores some data in the SQL server – these are:

1. User map (General rules are stored when creating/saving Sync and Selective profiles) – the profile data is securely

stored in the ADAM database therefore the usermap can be recreated simply by saving the profiles.

2. Custom rules in the usermap(UserID A in AD has to map to UserID B in the target) is only present in the usermap

table in SQL

3. Password Requests

4. Password Transactions

5. Password Manager Events (Only in larger installations)

To make a full synchronization when the master the databases will need to be in sync. FastPass recommends keeping the

tables in sync with a minimum of 15-20 min. apart. This will ensure that the impact is small in the event of a take over.

To implement this solution please follow these guidelines:

On the Master (after install of the core Password Manager):

1. Install the MSSQL servers on the master

2. Install the sync-server (FastPass-PasswordSync-Server) remember to point the FastPass at the local MSSQL

server.

On the Slave:

1. Install the MSSQL servers on the master

2. Install the sync-server (FastPass-PasswordSync-Server) remember to point the FastPass at the local MSSQL

server.

Now the two servers are alike. For keeping the servers up-to-date the data in the SQL servers Password Sync database will

need to be kept up-to-date. This can be done using basic scripting or other synchronization tools.

In the event of a takeover Password Manager will start picking up data from the local SQL server. Remember that the data

will have to be synced to that master server again before switching roles.

If the setup described here is used with Sync please take the following into account. The Interceptor module, which is

installed on all the Domain Controllers, has to always point at the live MSSQL Server to keep delivering data to the system

system that is up. This can be achieved in a number of ways.

• Cluster: The SQL Database is placed on an existing database cluster.

• Mirroring (In that case the ConnectionString for the Interceptor has to have the slave server added as “Failover

Partner”).

• DNS – by having the DNS point at the active server, using that name in the Interceptor and lowering the TTL value

to eg. 10 min. then the new IP for the active server will be updated on the Interceptors within 10 mins.


Status: Final of 10

Date: July 24, 2013

2.2 Needed firewall port openings:

From the Backend servers:

To AD: 389,445,636

To SMTP server:25

If other systems like SAP, AS400 are installed – ports will have to be opened to those systems as well. Please consult the

documentation for the systems involved

From the Frontend Servers:

To Backend Server: 443

From the Internet:

To front-end servers: 443

2.3 Using FastPass HA scripts to control servers

FastPass has built scripts to handle the takeover process. The scripts are free to use and change. Please note that there is no

support regarding the use of these scripts, neither any guarantee that they will get fixed if any specific bug is found. Please

note that in the event of a takeover where the current master server is offline, the scripts has no possibility to disable the

services on the current master, the server should be restarted offline to avoid any issues. In the following section the server

are referred to as master(Server1)/slave(Server2).

Depending on the exact setup, dns references etc. might need changing to complete the takeover, this is not part of these

scripts, please check the detailed operations done by the scripts below.

2.3.1 Description

The scripts provide functionality to promote a server to the master in a master/slave environment and are to be placed on

both servers. More precisely the following scripts are available:

1. TakeOverMasterRole.vbs - This script is to be called by hand when a takeover(role switch) is supposed to take

place. When one server is to be the master, then this script called, by a user with sufficient permissions. It will:

a. 'Remove ISMASTER file from partner

b. Stop Services on partner

c. Disable automatic start up services on partner

d. Start local services

e. Set Local Services to automatic startup

2. DoSync.vbs - This script will keep the servers config files and registry settings up to date, the script should be run at

least every hour on both servers. When run on the master it will:

a. Fetch config files and place them in the configLib folder

b. Fetch registry information and place them in the configLib folder

When Run on the slave it will:

c. Fetch config files from the master and place them into the local installation

d. Fetch Registry values from the master and insert them into the local registry


Status: Final of 10

Date: July 24, 2013

3. RestartServicesHA.vbs – this script replaces the normal service restart script as it will take into account if the

server is a master or a slave. If the server it runs on is the master server it will restart the services, otherwise it will

not.

4. Config.vbs – this file holds the configuration for the setup on each server the files are added to editing is needed

the following needs to be edited:

a. PartnerServerName: This is the name of the other server in the setup(The name must resolve correctly)

b. ShareName – This is the share name of the partner server location of the HA folder

In other words the 2 variables must result in the server being able to access the partner’s folder by issuing

\\PartnerServerName\ShareName

2.3.2 Setting it up

In order to setup he servers to work with the scripts please follow the below guidelines having in mind that

servernames/usernames are to be changed to the particular installation.

2.3.2.1 Pre requisites

1. Create a domain services account for running the services eg. called fpHASrv, this user must be granted

administrative rights on the servers – please notice that using already present service accounts for FastPass such as

eg. the FPIisUser might result in issues.

2. Determine what domain user group that a user should be a member of in order to run the take over script. Make

sure that this group has administrative and logon rights on the servers

2.3.2.2 Step-by-step instructions

1. copy the files in the zip package a folder on the c-drive c:\HA\, this should include the empty folder so you have

the vbs files under c:\ha\ and the empty folder in c:\HA\ConfigLib\ - do this on both servers

2. Set the permissions on the c:\ha\ folder allowing full permissions for the created service account and for the

domain group from the pre-reqs.

3. Create a share for the c:\HA\ folder, call it HA$, allow both the service account and usergroup from the pre-reqs to

have full access

4. Edit the c:\ha\Config.vbs file and correct the partner servername to match the partner name for the server.(Eg. if

you have two server server1 and server2 then the config.vbs file on server1 should read server2 and vice-verse )

2.3.2.3 Testing the setup

Please follow these stopes to ensure that the scripts, users and shares are configured as it should be:

1. Run the take over script on Server2 TakeOverMasterRole.vbs

2. Check that the FastPass Services on Server1 after 20 seconds has been set to Manual and and stopped (All 6

services starting with Password Manager)

3. Now repeat this step running the script on Server1 and checking the Services on Server2 and leave Server1 as the

Master.

Testing the synchonization of settings from master to slave

1. On Server1 delete all the contents of the configLib\ folder

2. On Server1 run the create Sync job(Not the DoSync.vbs directly as we need to test the account the Task Scheduler

is setup to)


Status: Final of 10

Date: July 24, 2013

3. Validate that there is now new data in the ConfigLib folder on Server1

4. On Server2 På Server2, delete all the contents of the

<INSTALLPATH>\FastPassCorp\Configuration\FastPassServer\FastPassEngine\ folder

5. Run the Sync Job on Server2 using the Task Scheduler

6. Validate that files has now been created in the folder from step 4.

7. Now run the takeover script on Server2, setting Server2 to the master server and repeat steps 1-6 above changing

the servernames. End up setting Server1 as the master server again.

If some of the tests fail, please review the permissions of the accounts as well as file and share permissions.

FastPass Password Manager · The intended operation here is to have two frontend servers for...

Documents

Transcript of FastPass Password Manager · The intended operation here is to have two frontend servers for...