1. Deployment Guides

1.1 Gateway Deployment

To deploy a secure and fully functional Gateway, certain core pre-requisites are required. These include considerations in infrastructure, networking, encryption, hardening, service account and permissions.

The following section explores each of the requirements in detail and guides best practices relating to the implementation of each.

Security Considerations

Before we continue, it is important to note that your safety and data privacy are our utmost concern. To secure communications between the MyPass Cloud platform and the Gateway, several network and application security measures are put in place as part of a deployment. These include

  • Mutual firewall policies to restrict the flow of traffic between the MyPass Cloud platform and Gateway server(s).
  • Transport layer security through the use of strong and modern encryption.
  • Application level configuration, including authorized caller configurations to restrict specific MyPass Cloud platform POD tenants to communicate only with specific Gateway server(s).

Apart from this, your deployment partner or MyPass Cloud engineer will advise you on other security controls such as server hardening and business continuity requirements. 

1.1.1 Hardware Requirements

The Gateway is a critical component in the operation of the MyPass Cloud platform, providing secure and reliable communication between MyPass and your organization’s user repositories.  Due to this, the Gateway must be performant and redundant (either on a hardware or virtualization level).

The Gateway runs in a Microsoft IIS web application on top of Microsoft Windows. To provision a Gateway server, use the following server specifications.

Minimum Hardware Requirements
  • 2 CPU cores (physical or virtual)
  • 4 GB RAM
  • 10 GB of free hard disk space (excluding OS requirements)
Recommended Hardware Requirements
  • 2 CPU cores (physical or virtual)
  • 8 GB RAM
  • 20 GB of free hard disk space (excluding OS requirements)

1.1.1 Software Requirements

The Gateway server utilizes web services hosted on a Microsoft IIS instance to allow incoming requests from the MyPass Cloud platform to your credential repositories. As such, a current Microsoft Windows Server with IIS is perfect to host the Gateway web services.

Minimum Software Requirements
  • Microsoft Windows Server 2016 or later (x86 or x64)
  • Microsoft Internet Information Server (IIS) v.10 or later
  • .NET Framework v. 3.5
Internet Information Services (IIS) Enabled Features

As part of the deployment of IIS on the Gateway, we require the following features to be enabled with the role.

  • Common HTTP Features
    • Default Document
    • Directory Browsing
    • HTTP Errors
    • Static Content
  • Health and Diagnostics
    • HTTP Logging
  • Performance
    • Static Content Compression
  • Security
    • Request Filtering
  • Application Development
    • .NET Extensibility 3.5
    • .NET Extensibility 4.5
    • ASP.NET 3.5ASP.NET 4.5
    • ISAPI Extensions
    • ISAPI Filters
    • Management Tools
    • IIS Management Console
    • IIS 6 Metabase Compatibility

1.1.1 Network Requirements

To establish a secure connection between the MyPass Cloud platform and your credential repositories, the Gateway is used to proxy traffic. All traffic to the Gateway will always originate from the MyPass Cloud platform.

The Gateway can be deployed within the local network or a DMZ, if you prefer. If the Gateway is deployed in a DMZ, only HTTPS (443) traffic needs to be allowed from the internet to the Gateway, while the ports required from the DMZ to the local network will depend on the credential repositories that are being accessed. More information on this can be found in the integration guide for each target credential repository.

Publishing the Gateway

To securely publish the Gateway to the MyPass Cloud platform, a few steps are required. These include:

The Gateway server must be provided with a PUBLIC IP ADDRESS that is presented via NAT (Network Address Translation) to the public internet. For Gateway traffic, this can be achieved through application delivery controllers or firewalls. 

The Gateway server must be provided with a PUBLIC IP ADDRESS that is presented via NAT (Network Address Translation) to the public internet. For Gateway traffic, this can be achieved through application delivery controllers or firewalls. 

Firewall rules needs to be configured on your edge appliance to allow the MyPass Cloud platform IP address pool to access your Gateway server over port 443 – incoming – TCP only.

MyPass POD1 Customers:

  • 102.37.104.14
  • 102.37.122.52
  • 102.37.124.197

MyPass POD 2 Customers:

  • 102.133.232.144
  • 40.120.25.31
  • 40.120.25.105

To securely encrypt traffic between the MyPass Cloud platform and the Gateway, you need to take a few actions:

  1. An existing (customer owned) or new web server SSL certificate must installed on the Gateway server to allow incoming SSL connections to Microsoft IIS. (e.g. gateway1.yourcompanyname.xyz)
  2. The certificate must be added to the server and installed on the Default Site within IIS, ready for the deployment of the Gateway web services.
  3. A public DNS A-record (associated with the domain name of the loaded certificate) should be created to resolve the hostname (on the certificate) to the public NAT IP address of the Gateway server (e.g. gateway1.yourcompanyname.xyz -> 41.32.4.123)
  4. Finally, the protocols and ciphers of the published certificate can be updated on the Gateway server to only allow modern and strong encryption.

Once all the above-mentioned requirements have been successfully implemented, communications between the MyPass Cloud platform and the Gateway server can be validated.

To do this, please email your deployment partner, MyPass Project Manager or simply create a request by emailing [email protected].

1.1.1 Groups & Service Accounts

The final step before the Gateway web services can be deployed involves the creation of service account(s) and groups used to run the application pools for the Gateway services. 

These service accounts can be created on the Gateway server or, if available, within Active Directory. If a single Gateway is deployed either option can be chosen, but should multiple Gateway servers be deployed, the use of Active Directory as a central authentication and authorization store is recommended.

The services, accounts, groups and permissions required for the integration into credential repositories can be found in the integration guide for each system.

This group controls the access for local / domain users who perform administration and configuration tasks on the Gateway.

  • Group Type: Active Directory Security Group or Local Computer Group
  • Group Name Example: MP-GWGroup

This account is required to host the Microsoft Internet Information Services (IIS) application pool in which the Gateway web services application will run. The Gateway installer will create this account during the setup process. Please ensure the account executing the installer has the appropriate permission to create an account in the specified target repository (either Active Directory or the local server)

  • Account Type: Active Directory User Account / Local Computer User Account
  • Account Name Example: MP-IISUser
  • Account Permission: 
    • If the gateway server is not domain joined (local computer), the account must be part of the Users and the IIS_IUSRS groups on the local server.
    • If the gateway server is domain joined (member server), the account must be part of the Domain Users and IIS_WPG security group within Active Directory
    • Additional Special Permissions: Log on as a batch job

This account is required to perform all administration and configuration on the Gateway.

  • Account Type: Active Directory User Account / Local Computer User Account
  • Account Name Example: MP-GWUser
  • Account Permissions:
    • If the gateway server is not domain joined (local computer), the account must be part of the Users group on the local server.
    • If the gateway server is domain joined (member server), the account must be part of the Domain Users security group within Active Directory
    • Additional Special Permissions:
      • Log on locally (on the gateway server(s))
      • Member of the MPGWGroup group (custom group created above as part of the “MyPass Gateway Administrators Group”)

1.1.1 Security Recommendations

Since the primary role of the Gateway is hosting a set of web services using Microsoft Internet Information Service (IIS), the recommendations will focus on securing this role. Normal security best practices relating to firewall configuration, patching and monitoring should still be addressed.

To harden the security posture of the Gateway server, we recommend the following:

  • Do not run the MyPass Gateway (IIS) on a domain controller or with any other dedicated functions.
  • Install only the IIS modules you need (as described in the Gateway software prerequisite section)
  • Ensure that server roles are kept separate.
  • Keep your antivirus, malware, EDR/XDR software up to date.
  • Isolate web applications if more that one exists on the server.
  • Implement the principle of least privilege when assigning permissions to the service account for the Gateway.
  • Make periodic backups of the server or IIS configuration.
  • Never deploy a gateway without using transport layer encryption, and take care to configure accepted SSL ciphers and protocols.
  • Ensure that incoming firewall ports only allow HTTP, TCP on port 443.
  • Configure the outgoing firewall configuration if DMZ or HIPS is used between the Gateway and target credential repositories.
  • Always ensure that only authorized MyPass  Cloud platform POD Accepted Call  IPs as listed on your Gateway.

1.1.1 Backup Recommendations

To recover the Gateway in the event of a failure, both the IIS configuration and the application files need to be restored. There is no dynamic content or database instances on the server, so the content that needs to be backed up only includes:

  • Microsoft IIS Application Configuration: This can be achieved with APPCMD or through configuration in whichever backup solution is implemented. For information on APPCMD reference, click here.
  • SSL Certificates
  • Gateway Application Content: All file content for the Gateway is stored in the folder: C:\Program Files (x86)\FastPassCorp
  • MyPass specific Registry Keys: All registry information for the MyPass Gateway is stored in the key:
    • Computer\HKEY_LOCAL_MACHINE\SOFTWAR E\FastPassCorp
    • Computer\HKEY_LOCAL_MACHINE\SOFTWAR E\Wow6432Node\FastPassCorp A/S

1.2 Integrating Credential Repositories

1.2.1 Microsoft Active Directory Integration

MyPass Cloud supports easy integration into multiple Microsoft Active Directories from a single or multiple Gateway servers. The configuration is done by your MyPass Cloud engineer assigned to your project or by requesting changes via [email protected].

All communications to the target Active Directory infrastructure are routed via the Gateway server. Integration is done through secure or SSL mode. Note that using SSL requires changes to your Active Directory deployment. Secure mode is the default mode used by Microsoft Active Directory internally (for synchronizing passwords between Domain Controllers).

MyPass Cloud requires the following to access a Microsoft Active Directory Domain via your Gateway.

INFORMATION DESCRIPTION
Domain Name
The full qualified domain name of the domain like mycorporation.com.
Domain Alias
A label typically the same as the NetBIOS name for the domain which is what is shown in desktop login interfaces.
Connection Mode
The connection mode to use for the communication. Microsoft Active Directory offers the modes normal, secure and SSL but Password Manager only supports Secure and SSL mode. The secure mode used Kerberos for the authentication which is dependent on normal domain communication from the Password Manager Gateway Server and to the Domain Controller in addition to communication on port 389 (TCP). The SSL mode requires a certificate to be implemented on the Domain Controller which is not a trivial task but then as an advantage it only requires communication on port 636 (TCP) from the Password Manager Gateway Server and to the Domain Controller.
Domain Account Name
The name for the account with privileges to read user attributes and to reset passwords.
Domain Account Password
The password for the account specified.

To support redundancy, MyPass Cloud can be configured to access multiple Gateway servers and multiple domain controllers in the same domain. For configuration purposes, the following information must be configured for each connection to a Domain Controller.

INFORMATION DESCRIPTION
Domain Controller
The fully qualified hostname or IP address for a domain controller. If SSL mode is desired for the communication then the fully qualified hostname is required.
Gateway Server
The Password Manager Gateway to use as offset for the specified Domain Controller.

All parameters are stored in the MyPass Cloud Encrypted data store. The next section explains the LDAP operations performed against Microsoft Active Directory and the required privileges for the Domain Account to function.

1.2.1 Service Account Permissions

MyPass Cloud requires a Microsoft Active Directory service account with specific permissions to discover and interact with end-user accounts in the domain. This includes the ability to read account and group information, reset and change passwords and unlock accounts. The following section explores how to create an Active Directory service account and how to delegate the appropriate permissions to it.

Delegating Permissions

The following steps provide simple guidance on how to delegate permissions to you service account once it has been created using your naming standard.

  1. Open Active Directory Users and Computers (ADUC).
  2. Right-Click the OU to grant MyPass password management permissions.
  3. Select Delegate Control.
  4. Click Next in the Delegation of Control Wizard.
  5. Add the users and/or groups you want to delegate permissions to. Click Next.
  6. Select the Standard task to delegate. In this case, we have chosen the permission to Reset user passwords and force
    password change at the next logon. Then click Next.
  7. Click Finish to set the permissions in Active Directory.
  1. Return to Active Directory Users and Computers (ADUC).
  2. Find the OU for delegation. Right-Click the OU and select Properties.
  3. Confirm whether you can select the Security tab at the top of the Properties window. If the tab is visible, select the Security tab. Should the tab not be visible, please enable Advanced Features in the Active Directory Users and Computer (ADUC), under the View menu option.
  4. Under the Security tab, click Advanced to view the permissions to apply the special permissions.
Effective Attribute Permissions

The Gateway requires read permissions granted to the Domain Account on several default attributes for each user. The attributes are shown in the table below.

ATTRIBUTE ACCESS DESCRIPTION STORED
DistinguishedName
Read
The unique name in LDAP format for the user.
Yes
sAMAccountName
Read
The short unique name for the user (the old style login name).
Yes
objectClass
Read
The AD object
Yes
cn
Read
Common Name for the user.
Yes
sn
Read
Sur Name also editable in Active Directory Users and Computers.
Yes
givenName
Read
First Name also editable in Active Directory Users and Computers.
Yes
displayName
Read
Full Name also editable in Active Directory Users and Computers.
Yes
description
Read
Description also editable in Active Directory Users and Computers.
Yes
department
Read
Department also editable in Active Directory Users and Computers.
Yes
title
Read
Title also editable in Active Directory Users and Computers.
Yes
manager
Read
Manager also editable in Active Directory Users and Computers.
Yes
phone
Read
Phone also editable in Active Directory Users and Computers.
Yes
mobile
Read
Mobile Phone also editable in Active Directory Users and Computers.
Yes
mail
Read
E-mail address also editable in Active Directory Users and Computers.
Yes
lockouttime
Read
Used to determine whether a user has been locked because of too many failed login attempts.
Yes
userAccountControl
Read
Used to determine whether a user has been disabled.
Yes
memberOf
Read
The Groups a user is member of.
Yes
primarygroupid
Read
Used to determine the primary Group of a user.
Yes
userPrincipalName
Read
The user principal name of the user.
Yes
pwdLastSet
Read
Used to determine whether a user has been locked because of too many failed login attempts.
Yes
userCertificate
Read
Used when Email Encryption is enabled.
Yes

The list of attributes can be customized and extended. If required, the Read permission for these attributes must also be granted.

1.2.2 Reset Password Operation

The resetting of the password is only possible if the user has passed the configured alternative authentication methods and if the user holds the “Change Password” privilege.

By default, the password reset operation performs a two step process. This process is intended to honour your domain password policies and auditing requirements. The operation initially generates a random password and then performs a subsequent password change operation. In doing so, all Active Directory password policies like age and history are checked, and the password history count is incremented on each operation.

Required permissions

The Password Reset function requires read permissions granted to the Domain Account on a number of attributes that are all listed in the Discover Account table. Furthermore, it requires permissions granted to the Domain Account on the attributes shown in the following table.

ATTRIBUTE ACCESS DESCRIPTION STORED
lockouttime
Write
Used to determine whether a user has been locked because of too many failed login attempts.
Yes
pwdLastSet
Read-Write
When the user last set the password.
Yes
userAccountControl
Read-Write
Used to determine whether a user has been disabled.
No
msDS-User-Account-Control-Computed
Read
Used to find out the LOCKOUT setting.
No
ntSecurityDescriptor
Read
No
logonHours
Read
Used to get user’s valid logon hours
Yes

Besides the listed attribute rights the function also requires the privileges listed in the following table granted to the Domain Account.

PERMISSION ACCESS DESCRIPTION
ResetPassword
Execute
Method used to set the password.
Domain Account Privileges

Besides the listed attribute rights and privileges, the password reset operation also requires the following privileges to be granted to the Domain Account on the Domain Policy object.

ATTRIBUTE ACCESS STORED
maxPwdAge
Read
No
minPwdAge
Read
No
minPwdLength
Read
No
lockoutDuration
Read
No
lockoutObservationWindow
Read
No
lockoutThreshold
Read
No
pwdProperties
Read
No
pwdHistoryLength
Read
No
objectClass
Read
No

1.2.3 Change Password Operation

The password change operation is performed as part of the Password Change end-user transaction in MyPass Cloud. This is done to perform the actual change of the password (only if the user has passed the configured alternative authentication methods and only if the user holds the “Change Password” privilege).

The Password Change function requires read permissions granted to the Domain Account on several attributes, which are all listed in the table below. No other privileges are required.

ATTRIBUTE ACCESS DESCRIPTION STORED
pwdLastSet
Read
When the user last set the password.
Yes
userAccountControl
Read-Write
Used to determine whether a user has been disabled.
Yes
msDS-User-Account-Control-Computed
Read
Used to find out the LOCKOUT setting.
No
ntSecurityDescriptor
Read
No
logonHours
Read
Used to get user’s valid logon hours
Yes

Besides the listed attribute rights, the password change operation also requires the privileges to check password policy and previous operations.

ATTRIBUTE ACCESS STORED
maxPwdAge
Read
No
minPwdAge
Read
No
minPwdLength
Read
No
lockoutDuration
Read
No
lockoutObservationWindow
Read
No
lockoutThreshold
Read
No
pwdProperties
Read
No
pwdHistoryLength
Read
No
objectClass
Read
No

1.2.4 Unlock Account Operation

The account unlock operation is performed as part of the Unlock Account end-user transaction MyPass Cloud. This is to perform the actual unlock of the account (only if the user has passed the configured alternative authentication method).

The Account Unlock function requires read permissions for the Domain Account to several attributes, which are all listed in the table below.

ATTRIBUTE ACCESS DESCRIPTION STORED
Lockouttime
Write
Used to determine whether a user has been locked because of too many failed login attempts.
Yes
pwdLastSet
Read
When the user last set the password.
Yes

1.2.5 Group Discovery Operation

MyPass Cloud uses a discovery operation to track users placed in group, removed from groups and changes in information on user accounts. This information is used to trigger notification processes (e.g. password reset reminders) as well as allocation/deallocate MyPass Cloud licensing. For this to function correctly, the following permissions are required in Active Directory.

ATTRIBUTE ACCESS DESCRIPTION
name
Read
The name of the group.
distinguishedname
Read
The unique name in LDAP format for the group.

1.2.6 Microsoft Entra ID Integration

1.2.1 eDirectory Integration

The MyPass Connector for eDirectory is used by the MyPass cloud to reset passwords for eDirectory LDAP accounts.

MyPass Cloud supports easy integration into multiple eDirectory user repositories from a single tenant or Gateway. The integration is implemented using TCP communication. Encryption must be used through either SSL or TLS. 

MyPass Cloud requires the following parameters to be configured to be able to access an eDirectory server.

PARAMETER DESCRIPTION
ConnectingString
LDAP://SERVERNAME>[:PORT]
Base DN for Users
The Base DN where FastPass will search for users eg. O=Target
Encryption Mode
SSL/TLS –please make sure that SSL certificate is trusted and naming is correct
Admin Account
This is the DN of the admin account having the necessary rights to reset passwords for the end-users. Eg. cn=Admin,O=target
Admin Password
The password for the above account.

The Gateway server responsible for the connection to eDirectory. This server must trust the root certificate of the eDirectory server. Furthermore, MyPass should have an admin account with the ability to complete the following operations:

  • Lookup the accounts using the CN attribute.
  • Reset Passwords by modifying the userPassword attribute.
  • Unlock accounts by modifying the lockedByIntruder and loginIntruderAttempts attributes.

By default, the connector will reset the password to a random password, unlock the account & finally attempt to change the password as an ordinary user. This process is done in the instance where Password History is required.

eDirectory Configuration Testing

Your MyPass Cloud engineer canprovide a simple testing tools for the MyPass Connectors to be used in validating you configuration. This tool uses all the same calls the Gateway will make, but provides interactive feedback.

The tool has options to check “Check Connection”, “Reset Password” and “Change Password”. Start testing by providing the connection details and clicking the “Check Connection” button. Logging is done in the same folder as the tool resides.

If you require any assistance, please contact your MyPass Cloud engineer or submit a request at [email protected].

1.2.1 SAP Integration

MyPass Cloud supports a wide range of SAP versions, encompassing both ABAP and Java-based systems. This includes major versions like HANA, ERP (ECC), NetWeaver, S/4 HANA, CRM, SCM, SRM, and Solution Manager. Additionally, it supports various business software modules such as ADP, SAC, ABAP, AFS, BW, BI, and others like FICO, GRC, EHDM, HRMS, IDT, IBP, KW, IBP, PS, PP and SD and more. 

The communication between SAP and MyPass Cloud consists of the following components:

  • The Gateway server SAP Connector (already installed on your gateway).
  • A SAP function module installed on all required instances. (Note that this is not connecting to SAP CUA (Central User Administration).
  • Creating a Privileged account in SAP for use by the Gateway.
Communications

The SAP Connector for MyPass Cloud uses standard patterns and ports to connect to SAP instances. To achieve this, the following ports are used:

  • 32## ports for SAP GUI
  • 33## ports for RFC (Remote Function Call).

Note: that ## denotes the SAP System Number (SYSNR).

SAP Configuration

To communicate between SAP and MyPass Cloud (via the Gateway server) you have to install a module on your SAP installation. The function module is called:

				
					Z_FPC_PASSWORD_CHANGE

General role/profile for all users. End-users require access to remote logon and can check their own password via a remote-enabled function module. Otherwise, MyPass Cloud will not be able to check that the password change has happened. The required SAP Authorization Objects are listed below:

AUTHORIZATION OBJECT FUNCTIONS VALUES
S_RFC
RFC_TYPE
RFC_NAME
ACTVT
FUGR
SYST
16 - Execute
SAP Configuration Testing

If required, your MyPass Cloud engineer can provide a simple account testing tool to you. You can use this tool to validate your SAP configuration by running the password check and password reset operations.

This will ensure that the system is ready for operation. The tool is packed together with all files needed at runtime and can thus be executed from any Windows computer with .NET and access to the SAP instances being tested.

1.2.1 Microsoft SQL Server Integration

The MyPass Connector for MSSQL is used by the Mypass Cloud to reset passwords for internal database users on MSSQL systems. The connector is installed on your Gateway server by default.

MyPass Cloud supports easy integration into multiple MSSQL systems from a single implementation.  The communication to the MSSQL is done from the Gateway server. The integration is implemented using TCP communication, and this can optionally be implemented to use encryption. Technically, it connects to the database and executes a stored procedure with the actual logic to reset the password of the MSSQL user. The stored procedure has to be installed before the connector will work. MyPass Cloud requires the following parameters to be configured to be able to access an MSSQL server.

PARAMETER DESCRIPTION
Hostname
A fully qualified hostname, a hostname or an IP address
Port
The Port that the server is listening on for the specified instance
Database
The Database in which the Stored Procedure is implemented
Stored Procedure
The name of the Stored Procedure to be called
Account
The name for the account with privileges to execute “alter login...” commands
Password
The password for the account specified
Encryption
Boolean value which decides whether or not encryption shall be used. Encryption requires extra configuration on the server. See www.microsoft.com for details

The various parameters are not actually used by the Connector but are just used to construct a valid formatted MSSQL Connection String, which can be customized beyond the rules of the listed parameters.

Configuring MSSQL Settings for Connector
  • Open the “SQL Server Configuration Manager” through the “Start”, “Microsoft SQL Server”, “Configuration Tools”, “SQL Server Configuration Manager” menu.
  • Navigate the “Protocols for …” and select the “TCP/IP” protocol and select “Properties” from the context menu.
  • In the “Protocol” tab select “Yes” for the “Enabled” property.
  • In the “IP Addresses” tab, specify the desired port (e.g. 1433) for the “TCP Port” under the “IP All” section, or a different one if desired. After selecting “OK” , the following prompt will be shown.
  • Now restart the MSSQL service to complete the configuration.
Configuring MSSQL Database System Account
  • Open the “Microsoft SQL Server Management Studio” and connect as “SA” or any other administrator account.
  • Navigate to the “Security” node and expand to the “Logins” node.
  • From the context menu of the “Logins” node select “New Login”.
  • With the “General” page selected specify the “Login name”; select the “SQL Server authentication” and specify a valid password. Make proper choices for the other selections and then select the “Server Roles” page.
  • Select the “sysadmin” server role and click “OK”.
Configuring MSSQL Stored Procedure For Connector
  • Open the “Microsoft SQL Server Management Studio” and connect as “SA” or any other administrator account (possibly also the newly created account).
  • Navigate to the “Stored Procedures” node under the master database.
  • Click on the “New Stored Procedure” from the context menu of the “Stored Procedure” node.
  • The stored procedure code can be obtained from your MyPass Cloud engineer. Past this code into the window and and click on the “! Execute” button on the toolbar.
  • Expand the “Stored Procedures” node and select the “FPC_ResetPassword” node, and select “Execute” on its context menu.
  • Fill in the parameters and click “OK” to execute.

If successful, the result will be shown as this, and the configured environment is now ready to be used by the MyPass Cloud platform.

SQL Configuration Testing

Your MyPass Cloud engineer can provide you with a simple testing tool that will allow you to test your stored procedure and account configuration before providing all details for integration.

The tool allows you to validate various operations like “Check Connection”, “Reset Password” and “Change Password”. Logging is also provided in the folder “C:\TargetLogs” and is in “Debug” LogLevel, meaning that a lot of details are written to these logs for troubleshooting purposes.

Please contact us if you struggling, we would be more than happy to help. You can find us at [email protected].

1.2.1 IBM Integration

For effective integration with IBM iSeries, MyPass Cloud requires an OS/400 version V4R5 or above. Additionally, a dedicated service account needs to be set up to enable connection to the system. It’s also important to ensure that the Password Level on the iSeries system is set to at least level 2 to facilitate proper synchronization with MyPass Cloud.

The method used by MyPass Cloud to reset passwords for IBM Z/OS or iSeries depends on the specific system setup. Generally, we utilize either an LDAP connector or an SSH connector. The choice between these two options is based on the infrastructure and requirements of the environment in question. 

When the connector sets a password for a user, it will login to instance using a service user that possesses the privileges required for this operation. Necessary administrator privileges:

  • *SECADM (Security Administrator)
  • *ALLOBJECTS (only required if MyPass should be able to set passwords on elevated eg. Secadm accounts)
Remote Command (*RMTSRV)

The Remote Command port is used for connecting to the iSeries machine. Therefore, the Remote Command exit point needs to be configured.

IFS

If there are machines connected to the iSeries using IFS and you wish to to make use of synchronization from AD, you would require at least iSeries Password level 2. (Password Level 1 can be used when limiting the AD Password Policy using the Password Filter)

SSL

The default setup is to use SSL connection between the iSeries and the Gateway server. This setting can be changed by setting the SSL mode key to false in the file: \FastPassGateway\bin\ConnectorIBMSystemI\fpc101.properties

For SSL, please follow IBM’s description on how to let IBM Tool Box for Java and iSeries communicate over SSL.

The MyPass Cloud includes a tool for getting the Java keystore created on the Windows Server in an easy manner. Please ask your MyPass Cloud engineer to assist with this step.

Connector Command

The Connector uses the IBM Tool Box for Java. The Java class AS400 is used to connect to the AS/400 host over SSL. The following command is run to set a password.

				
					CHGUSRPRF USRPRF (user) PASSWORD (password) STATUS (*ENABLED) PWDEXP (*NO)

This command can be changed in the fpc101.properties file on your Gateway server. This file is located in the main directory with the connector typically (\program files\FastPassCorp\FastPassGateway\bin\ConnectorIBMSystemI).

A typical customization is to change the line to add the password expiration feature on iSeries for the user. This can be done using the parameter below.

				
					PWDEXPITV (*SYSVAL)

To see a list of other parameters please refer to this link (please check if this corresponds to your iSeries version): http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/cl/chgusrpr.htm

The connector logs operations to a log file. The location of the log and the debug level can be set in the log4j.properties file. (this file is also located besides the connector in the classes directory)

1.2.1 Oracle Integration

The MyPass Connector for Oracle is used by the MyPass Cloud to reset passwords for internal database users on Oracle systems. This is based on either native Oracle users or users residing in different tables. The connector is installed along with the Gateway server but licensed individually and on per-user basis.

MyPass Cloud supports easy integration into multiple Oracle systems from a single implementation. The communication to the Oracle database is done from the Gateway server. The integration is implemented using TCP communication, and this can optionally be implemented with encryption (depending on the Oracle deployment). Technically, it connects to the database and executes a stored procedure with the actual logic to reset the password of the Oracle user. The stored procedure has to be installed before the connector will work. MyPass Cloud requires the following parameters to be configured to be able to access an Oracle server.

PARAMETER DESCRIPTION
Hostname
A fully qualified hostname, a hostname or an IP address
Port
The Port that the server is listening on for the specified instance (1521 default)
Database
The Database in which the Stored Procedure is implemented
Stored Procedure
The name of the Stored Procedure to be called
Account
The name for the account with privileges to execute “alter login...” commands
Password
The password for the account specified
Oracle Path on Gateway
The Path to the Oracle Instant Client Bin folder

The various parameters are not used by the Connector but are just used to construct a valid formatted Oracle Connection String. All parameters are stored in the Gateway server, and sensitive information like account, password and the connection string are stored with strong encryption.

Integration

MyPass Cloud provides different integration options. These are located on your Gateway server in the following installation directory. \FastPassCorp\FastPassGateway\bin\ConnectorOracle\

  • FPC_PasswordReset_ForDatabaseUsers.sql: This procedure (FPC_PasswordReset_ForDatabaseUsers) can be used out of the box to reset password on Oracle native users (The privileged user account must have Alter User Rights).
  • FPC_PasswordReset_ForTableUsers.sql: Holds an example on handling passwords when they are stored in a table. The example creates a small example table and installs the procedure FPC_PasswordReset_TableUser
  • FPC_PasswordReset_EBSUser.sql: This procedure must be used for Oracle E-Business Suite integration

To install the stored procedure, you can use either Application Express SQL Workshop, SQL Developer tools or the command line. If you require any assistance in this process, please reach out to your MyPass Cloud engineer.

Logging

The connector logs operations to a log file. The location of the log is \FastPassCorp\logs\Gateway-UserRepository-Oracle.log, and the LogLevel is by default “Debug” but can be customized from the registry. Logging will never contain passwords or other sensitive information.

1.2.1 CLI/SSH Integration

MyPass Cloud provides multiple options for command-line integration to applications and systems. These include CLI and SSH integrations. To ensure a successful integration with a system, some basic elements should be in place. First, a method for interacting with the remote system user’s password. To determine if integration is possible, please answer the questions below:

  • Is it possible to reset any user’s password using command line execution, web service request, API or using access to data storage? (There might be multiple possibilities; all should be mentioned)
  • If so, can the operation be executed locally from the MyPass Cloud, the Gateway, or does it require execution on a remote server?
  • Is the password on the remote system encrypted? If so, is the encryption method or DLL accessible? Or will the provided integration method take care of the encryption?
  • Is there a password policy on the remote system or any special requirements?
  • (Optional) Can the user be locked? What are the rules for this? Should MyPass Cloud unlock the user when resetting the password?
  • (Optional) Is there a “User Must Change Password at next logon” flag in the system, and should this be set?
  • Does the system require any upper/lower-case manipulation with the username or password?

The Generic CLI (Command Line, API, Web Service and SSH) Connector is used by the MyPass Cloud to reset passwords on a custom remote system that provides some kind of application or command line integration options (e.g. script).  The CLI connector empowers customers to build their own integrations into MyPass Cloud.

The connector is installed along with the Gateway server installation and provides many options for configuration. The following section explores these options in greater detail.

When the Generic CLI Connector is executed, it calls a specific program or application logic to action specific options on target systems. To transfer the data to the program, MyPass Cloud will either encode Base64 or use custom encryption.

From that point, it is up to the executable to set the password on the target system. MyPass Cloud will use state management to determine when and if the application/executable/logic was successfully executed.

In the event of a success code, the transaction will be set accordingly. In the event of a failure code, the automatic retry feature will go into action. Finally, a user that is not present will result in the transaction being aborted, as this indicates that the user ID in question has no account on the target system. The text will along with the code be saved in the Gateway server logs for the connector (Gateway-CLIconnector.log).

Parameters

When defining a generic call, the following parameters are available:

  • Check Connection: This value provides the path to a  Check Connection script/logic on the remote server.
  • Reset Password: This value defines the path to the Reset Password script/logic on the remote server.
  • InstanceID: (Optional) This value will be sent as a parameter to the scripts and can be used to determine which user repository is executing the connector. Use this when multiple endpoints are serviced from the same script/logic.
  • Working directory: The working directory for the executable/script.
  • Admin Account: If specified, this value will be sent to the executable as a parameter.
  • Admin Password: The password for the above account.
  • Method: This value determines how MyPass will transfer the password to the remote script. The following options are available:
    • None – the password is passed in clear text (Not recommended)
    • Base64 – the password is encoded in base64
    • Custom – MyPass offers the ability to build your own encryption algorithm.
  • Assembly path: Path to the encryption DLL – Used when Custom Encryption is chosen.
  • Class Name: Class name – Used when Custom Encryption is chosen.
  • Username Manipulation: (Optional) Tells if MyPass should upper or lowercase the username before sending it to the connector.
  • Password Manipulation:(Optional) Tells if MyPass should upper or lowercase the password before sending it to the connector.
  • Unlock After Reset: (Optional)Not used in the current version.
  • Mode: These Impersonation settings control which user is creating. This can be used to limit the access to a client certificate when using certificates. Possible values are:
    • None
    • Impersonate as FPIIS user
    • Impersonate as a specific user
  • Account: The account to be used for impersonation if “Impersonate as a specific user” is chosen.
  • Password: The password for the above account.
Execution of Application/Executable

When calling the script parameters will look like this:

				
					<Reset Password script> <Operation> <Encoding> <AdminUser> <AdminPass> <Instance name> <username> <Password>

Where:

  • Reset Password script is the script name from above
  • Operation is ResetPassword
  • Encoding is: None, Base64 or Custom (Chosen above)
  • AdminUser: is the admin username given above
  • AdminPass: is the password for the above account
  • Instance name is the name put into the Instance name field
  • Username is the username for the user who’s password we are setting
  • Password is the password
Execution of Application/Executable

The output from the script must be in one of the following codes. The output will be shown in the log for the connector. If the return code is 3, then MyPass Cloud will retry the operation.

				
					0; <TEXT> eg: 0; Password user johnd successfully set

2;<TEXT> eg: 2; The user johnd in not present In this system

3;<TEXT> eg: 3; Failed to set password for JOHD–system is unavailable
Connector Sample

A sample connector is included in the Gateway server installation under the following path: \FastPassCorp\FastPassGateway\bin\ConnectorCLI

There is a readme file explaining how to get the connector working. The sample connector implements a simple connector setting passwords on local MSSQL users by use of the osql.exe program.

1.3 Password Hygiene Filter for Active Directory

MyPass Password Hygiene Filter is a value-add to MyPass Cloud customers that allows for quick and easy alignment of multi-vendor password policies via a simple agent deployment to Microsoft Active Directory Domain Controllers. The Password Filter can be installed as a stand-alone product or in conjunction with other MyPass tools.

The Password Filter can:

  • Be installed in under 15 minutes as an Active Directory add-on.
  • Supplements Active Directory Group Policies without overruling existing policies.
  • Can be installed in Normal or Silent Mode for large deployments.
  • Should be installed on all domain controllers to be effective.
  • Works for Password Reset and Password Change
  • Logs to Windows Server Event Log.
  • Is configurable via a simple XML file for custom rules such as dictionaries and regex definitions.
Supported Platforms

The Password Filter is distributed in a single MSI-file installer package for all supported platforms. It can then be installed silently by specifying options on the command line or in a configuration file.

The MyPass Password Filter supports the following Windows Operating Systems.

OPERATING SYSTEMS LIMITATIONS
Windows Server 2008 32-Bit / 64-Bit
None
Windows Server 2008 R2 32-Bit / 64-Bit
None
Windows Server 2012 64-Bit
None
Windows Server 2012 R2 64-Bit
None
Windows Server 2016 (version 1607)
None
Windows Server 2019 (version 1809)
None
Windows Server 2022
None
Windows Server 2025
None
Installation Steps

The Password Filter can be installed in GUI mode, which is described and illustrated in the following installation steps.

  • To start the installation, you must be logged on as a user with administrative privileges. Then start the installer or open a command prompt as Administrator, FastPass-PasswordFilter.msi. This will pop up the InstallShield Wizard program.
  • After a few moments, the program will automatically proceed to the following screen.
  • Click the “Next” button to continue, and for the “End User License Agreement” screen to be displayed.
  • Click the “Next” button to proceed. This will take you to the “Installation Confirmation” screen.
  • Click the “Install” button to proceed. This will initiate the installation process and pop up the “Installation Progress” screen. If the installation was successful, the wizard will automatically shift to the “Rule File Path” screen.
  • To close the InstallShield Wizard, click the “Finish” button.
Command Line Silent Installation

The Password Filter can be installed in silent mode. Please note that the Visual C component will NOT automatically install in GUI mode. Please make sure that the Microsoft Visual C++ 2010 Redistributable Package (x86) is installed (which can be found here http://www.microsoft.com/en-us/download/details.aspx?id=5555) on the system prior to installing the package in silent mode.

The following installation parameters are available:

  • /s – Indicates that the installer will run in silent mode.
  • /v”/qn” – This argument is used to specify the values of public properties for the silent installation.
  • /v”/qn INSTALLDIR=C:\Program files (x86)\PasswordFilter” – Passes the installation directory value to the installer while running silently.
				
					// If you want to install the password filter using the default installation directory %ProgramFiles%\FastPassCorp\PasswordFilter, then execute the following command:
FastPass-PasswordFilter.msi/s /v”/qn”

// Or if you want to specify the installation directory, execute the following command:
FastPass-PasswordFilter.msi/s /v”/qn INSTALLDIR=C:\PasswordFilter”
Uninstalling the Filter

The Password Filter can be uninstalled from the Control Panel (similar to other Windows-based software). Since it is required to activate the filter in the Windows LSA service, a reboot of the serveris  required.

1.3.1 Password Filter Configuration

Configuration File Location

There is only one configuration file for the Password Filter and it is named “PasswordFilterRules.xml”. This file contains the operation configuration and filter rules. This file is located at the installation path under

				
					// File location
// <drive>\FastPassCorp\Configuration\FastPassPasswordFilter

// Basic structure
<?xml version="1.0" encoding="UTF-8"?>
<filterrules>
<configuration>
</configuration>
<filters>
</filters>
</filterrules>

The “configuration” node contains the configuration of event logging level and operations, which the password filters supports.

				
					<configuration>
<loglevel>2</loglevel>
<Operations>
<PasswordChange>false</PasswordChange>
<PasswordReset>true</PasswordReset>
</Operations>
</configuration>
Logging

There are four valid “loglevel” values for password filter:

  • 0 – Verbose, information, warnings and errors will be logged to event log.
  • 1 – Information, warnings and errors will be logged to event log.
  • 2 – Only errors will be logged to event log.
  • 3 – Warnings and errors will be logged to event log.
Supported Operations

Password filter supports two types of operations:

  • PasswordChange: If set to true, then the password filter will apply its password rules while changing the password.
  • PasswordReset: If set to true, then filter rules would be applied while resetting the password.
Filter Configuration

The “filter” node contains the rules that will be evaluated for the password operations. Filter node examples are provided below.

				
					<filters>
    <!--1: Requirement for length -->
    <!--<filter match="yes">^.{6,}$</filter>-->
    
    <!--2: Requirement for dictionary -->
    <filter match="no" ignorecasing="true">.*(p[a@]ssw[o0]rd|qwerty|123).*</filter>
    
    <!--3: Requirement for special character -->
    <!--<filter match="yes">.*[\,.\;'\-()\s\:\!\?\"]+.*</filter>-->
    
    <!--4: Requirement for uppercase letter -->
    <!--<filter match="yes">.*[A-Z]+.*</filter>-->
    
    <!--5: Requirement for lowercase letter -->
    <!--<filter match="yes">.*[a-z]+.*</filter>-->
    
    <!--6:Requirement for accented character -->
    <!--View http://en.wikipedia.org/wiki/Unicode,see lists of Unicode codes --><!--<filter match="yes">.*[\u00C0-\u017F]+.*</filter>-->
    
    <!--7:Requirement for accented character -->
    <filter match="yes" accountnamepattern="^az.*$">^[a-zA-Z0-19]{8,8}$</filter>
    
    <!--8:Requirement for accented character -->
    <filter match="yes" groupnamepattern ="^ApplyFilterGroup$">^[a-zA-Z0-19]{8,8}$</filter>
    
    <!—-9: Apply rule to specific AD group -->
    <filter match="yes" ignorecasing="true" groupnamepattern="^FilterGroup$" groupnamepatternmatch="True">^.{8,}$</filter>
    
    <!—-10: Apply rule to user NOT it a specific AD group -->
    <filter match="yes" ignorecasing="true" groupnamepattern="^FilterGroup$" groupnamepatternmatch="False” valuetype="Keyword">AccountNameCheck</filter>
    
    <!—-11: These rules will do as AD Complexety -->
    <filter match="yes" ignorecasing="true" valuetype="Keyword">AccountNameCheck</filter>
    <filter match="yes" ignorecasing="true" valuetype="Keyword">FullNameCheck</filter>
    <filter match="yes" ignorecasing="true" valuetype="Keyword">CharacterVarianceCheck</filter>
</filters>

Each filter has a match attribute. This informs the engine whether the filter requires the pattern to either be matched in the password or if the pattern should not match the password. Another attribute is to ignore the casing, which comes in handy when adding dictionary words. The groupnamepattern attribute applies a filter to a specific group – however, the groupnamepatternmatch attribute will notify you when it is to be nullified. If the groupnamepatternmatch is false, the rule will be applied to all users and not members of the group. Please note that the user has to be a direct member of the group. Nesting will not work. The Keyword attribute enables specific internal password checks as explained below.

  • Rule 1: The first rule simply requires the password to be at least 6 characters long.
  • Rule 2: Dictionary example, denies the passwords eg: pAssword, P@ssw0rd, myPASSWord22, qwerty etc.
  • Rule 3: Requires one of the special characters to be present.
  • Rule 4: Requires uppercase
  • Rule 5: Requires lowercase
  • Rule 6: Demands unicode intervals C0 –17F. Read more about it here: http://en.wikipedia.org/wiki/Unicode
  • Rule 7: Applies the rule only to account IDs (SamAccountnames) matching the a pattern. Eg. user: az1234
  • Rule 8: Applies the rule only to accounts in the group fitting the groupname pattern. Users must be a member of a group matching the pattern for the rule to be applied. Please note that nested groups are not supported, the user must be a direct member of a group which names fits the pattern.
  • Rule 9: Applies the specific rule to an Active Directory group of users.
  • Rule 10: Applies the specific rule to users not members of the Active Directory group
  • Rule 11: Applies Password Complexity matching Active Directory to all users
Please note that the Keyword rule CharacterVarianceCheck, AccountNameCheck and FullNameCheck match the requirements for AD Password Complexity as defined here: https://technet.microsoft.com/en-us/library/hh994562.aspx
 
Please note: After any rules have been modified in the PasswordFilterRule.xml file, the filter will automatically reload the file.

1.4 Password Sync Interceptor for Active Directory

MyPass Cloud supports SSPR and password sync from multiple Microsoft Active Directories from a single tenant. As part of this, MyPass Cloud can capture password changes on Microsoft Active Directories and forward these to other integrated credential repositories. 

To achieve this, MyPass Cloud has a small software package installed on Microsoft Active Directory Domain Controllers to capture and securely forward passwords to the MyPass Cloud for synchronization. The Interceptor installs a hook into the domain controller so every Password Reset and Password Change can be securely forwarded. The Interceptor has to be installed on all Domain Controllers of the domain for effective operation.

Requirements

For the Interceptor to function, both .NET version 4.6.2 or higher and MSDTC DTC (Distributed Transaction Coordinator) must be running on the server domain controller.

Installation Steps
  • Open up the installer and execute the installer.
  • In the “License Agreement” screen, read through & accept the license agreement by clicking on the “Next” button.
  • You should then see the “Customer Information” screen. The user can now enter their User and Organization name and click on the “Next” button.
  • In the “Destination Folder” screen, click on the “Change” button to change the location where the application is installed.
  • For the password synchronisation target configuration, there are two options. The “Server Name” option is commonly used in normal on-premise environments. We do, however, recommend using SSL encryption in the communication with the database. If you have SSL set up on the database server, please follow the following instructions to install the certificate on the DC server. In the case where you’re using a domain server & certificate, this step is not required. Use the MMC snap-in to export the Trusted Root Certification Authority used by the server certificate. To use SSL encryption, you must install a certificate on the server. Follow these steps to install the certificate by using the Microsoft Management Console (MMC) snap-in.
  • We are ready to install the Interceptor. To continue, click on the “Install” button.
  • The Installation process is now complete. To close this dialog, click on the “Finish” button. 
Command Line Silent Installation

It is also possible to install the Interceptor using the command line. When installing, you will need to give the Interceptor the name of the MyPass Cloud server you are connecting to. Please give the FQDN of the server and make sure the name is resolvable. After the installation has completed, you will need to reboot the machine before the Interceptor will work. (If you need to make a custom connection string to the database, you will need to use the GUI to install.)

				
					/quiet SERVER = tenant-sync-fqdn
Custom Password Capturing Values

The Interceptor provides a few configuration options that control its operation. These options are controlled through 4 registry values for filtering of account passwords to be synchronized and 4 registry values for the control of creating events in Windows Event Log.

To locate and edit the Registry, open and enter regedit.

				
					HKEY_LOCAL_MACHINE\SOFTWARE\FastPassCorp\Password Interceptor

For every new value, right-click on any blank surface on the right side of the window and create each registry value as “String Value”.

Each filter value is treated as a single regular expression in .NET.

  • AccountNamePatternAllow: Filters which specific account name pattern can be forwarded by the interceptor
  • AccountNamePatternDeny: Deny specific account name pattern from being forwarded by the interceptor
  • GroupNamePatternAllow: Allow which group name pattern can be forwarded by the interceptor. The value will check on every group item found in the “memberOf” attribute.
  • GroupNamePatternDeny: Deny specific group name pattern from being forwarded by the interceptor

Between the allow and deny filters, the deny filter is the stronger one. This means if both filters are enforced, the deny filter will deny any users who are allowed by the allow filter. Account and group name filters are equally weighted; if both are enforced and a user fails with one of the filters, the user reset is not forwarded. The account name is the SAMAccount name, the group name is the DN of the group name, eg: “CN=myusers,OU=Groups,OU=somewhere,DC=Domaim,DC=local”

Some examples to allow sync of the users in a specific group.

				
					// To all only the users in myusers group
GroupNamePatternAllow = "CN=myusers,OU=Groups,OU=somewhere,DC=Domaim,DC=local"

// To specify only the group name, not the OU (the below will still work if the group is moved in the OU structure.):
GroupNamePatternAllow = "CN=myusers,"

// To deny users in any group with the name “_admin” in it:
GroupNamePatternAllow = "_admin"
Custom Event Logging Values

The following 4 registry values control the event log entries that are written to domain controller local event logs.

  • EventLogGenerateEventForFailedPassingAccountNamePatternAllow = false / true
  • EventLogGenerateEventForFailedPassingAccountNamePatternDeny = false / true
  • EventLogGenerateEventForFailedPassingGroupNamePatternAllow = false / true
  • EventLogGenerateEventForFailedPassingGroupNamePatternDeny = false / true

If these values are set to true, the Interceptor will create an event in the Event log depending on which value is true. These event log values create an event every time a password is not forwarded, by their respective registry filter value.

  • EventLogGenerateEventForFailedPassingAccountNamePatternAllow: An event is created when AccountNamePatternAllow failed to forward the password
  • EventLogGenerateEventForFailedPassingAccountNamePatternDeny: An event is created when AccountNamePatternDeny failed to forward the password
  • EventLogGenerateEventForFailedPassingGroupNamePatternAllow: An event is created when GroupNamePatternAllow failed to forward the password
  • EventLogGenerateEventForFailedPassingGroupNamePatternDeny: An event is created when GroupNamePatternDeny failed to forward the password