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 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.2 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.3 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.4 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.5 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.6 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

2. Integrating Credential Repositories

2.1 Microsoft Active Directory

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.

2.1.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.

2.1.1 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

2.1.1 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

2.1.1 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

2.1.1 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.

2.2 Microsoft Entra ID

2.3 eDirectory

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].

2.4 SAP

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.

2.5 Microsoft SQL Server

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].

2.6 IBM iSeries

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)

2.7 Oracle

2.8 CLI & SSH