The password self-reset process itself remains consistent, but the required authentication method introduces variations in the use cases and impacts the level of user identity verification prior to allowing a password change. The Core, Pro and/or IGA solution supports multiple authentication methods, which can even vary based on user group.

The first step is selecting the authentication method. After that, the self-reset process proceeds as usual.

1. Password Self-Reset with Company Login
   • Users can change their password after logging in with their existing company credentials. The new password is automatically provisioned to the directory.
   • Limitation: If users forget their current credentials, they cannot access the password self-reset service. It requires knowledge of the existing password.
   • Security Level: Low
   • Supported Authentication Methods:
     • AD login (username and password)
     • ADFS login (AD SSO)
     • Entra SSO
     • Local user login (SAML / OpenID)
2. Password Self-Reset with One-Time Password (OTP) – Add-On
   • Users can initiate a password reset from the M42 login page by selecting "I forgot my password." They provide their email or phone number and receive a message containing a one-time password (OTP). After successful authentication, the user sets a new password, which is then provisioned to the directory.
   • Requirement: The user’s phone number or email must exist in the Core/Pro or IGA solution.
   • Security Level: Medium
   • Supported Authentication Methods:
     • One-Time Password, SMS
     • One-Time Password, email
     • One-Time Password, authenticator application
3. Password Self-Reset with Bank ID Authentication (eID)
   • Users can initiate a password reset from the M42 login page by selecting "I forgot my password." They are redirected to authenticate using their selected bank’s identification method. After successful authentication, the user is directed to the Core/Pro or IGA solution, where they can define a new password. The password is then automatically provisioned to the directory.
   • Requirement: The user's social security number must be available in the Core or Pro solution.
   • Security Level: High
   • Supported Authentication Methods:
     • Swedish Bank ID
     • Finnish Trust Network (FTN)
     • Suomi.fi (Finland)
     • Mobiilivarmenne (Finland)

This use case is for Core/Pro solutions agent users, and it removes the need of accessing the directory in cases where user calls and requests password related activities like password change or unlocks. 

Accordion Body

Defining the password management use cases is straight forward, and it requires both technical and functional information from the customer. 

Definition workshop takes around one (1) hours, in cases where password is allowed to be changed towards one (1) directory. 

In the definition workshop participants 

• Ensures that technical preparations are done and functional preparations are ongoing
• Reviews the use case, and validates that data is up to date (users, mobile phone numbers, email addresses or social security numbers)
• Schedules dates for configuration, testing and production usage start. 

Participants: 

• Directory/authentication specialist(s)
• M42 solution agent/admin user

Technical preparations:

• Test environment
  • Test environment for the M42 solution (including Self-Service, if password self-reset use case)
  • Test environment for the directory/directories
    • If Active Directory, and no test environment available, also separate test OU in production can be used as test environment. In these cases, it is important that the service accounts are separated, and those have accesses only to correct OU's used for test and production. 
• Directory service account:
  • One for test and one for production
  • Create new service account into the directory or expand rights for the existing one(s)
  • Service account need to have rights to change users passwords, unlock passwords, and activate accounts.
• Authentication
  • One-Time Password
    • All users who are allowed to change their own password from Self-Service need to be found from the M42 solution and they all need to have valid email address or mobile phone number
      If any imports, or mass-updates are needed ensure that needed work is included in the delivery scope.
  • Bank ID authentication
    • All users who are allowed to change their own password from Self-Service need to be found from the M42 solution and they all need to have valid social security number
      If any imports, or mass-updates are needed ensure that needed work is included in the delivery scope.
    • In case of suomi.fi authentication customer needs to have correct permissions from DVV to use the method.

Functional preparations: 

• Communication towards end-users
  • Notice also external users
• Training (videos, guidelines, instructions)
• Governance and auditing requirements

Testing: 

• Check chapter: System- and user acceptance testing

Production usage:

• Ensure governance and audit requirements are fulfilled (daily/weekly/monthly/quarterly/yearly reporting) according to company policies
• Review daily that there are no provisioning errors 
• If password policy changes, remember to update end-user instructions
• Ensures that users who are no longer allowed to change their password does not have accesses to the service.
• Ensures that mobile phone numbers, email addresses and social security numbers are continuously valid and up to date.

IGA Account Actions 

Is the data card which starts provisioning towards the directories, when IGA admin or Service Desk Agent changes users password or other action type is needed to perform like activate account or unlock account. 

Ticket

Ticket data card can be used for starting password change for the user by using following attributes

• Quick fill - Option: change password from ticket
• Customer - user whose password is going to be changed
• Transform button “change users password” which opens new IGA Account Actions data card, and copies customer information to the data card

IGA Service Request

Provisioning is started from IGA Service Request when password is changed using self-reset service in Self-Service. 

Always remember: 

1. Configure use cases first into test environment
2. Follow up correct instructions according the environment type and the M42 solution
   • Password self-reset for new environment
   • Password self-reset for existing environment
   • Password reset for Service Desk Agents for new environment
   • Password reset for Service Desk Agents for existing environment
   • Password reset for IGA Admins for new environment
   • Password reset for IGA Admins for existing environment
3. Perform system and user approval testing in the test environment
4. Fix all possible findings and perform re-testing
5. Move configuration into production environment
6. Validate that configuration is correctly moved to the production environment

Configuration instructions for password self-reset to new environment

These instructions applies when password reset is installed to own separate environment, or it is configured to new environment (baseline version 2025.1 or newer). 

• Self-Service
  • Validate that change my password service is published (if not publish the service)
• Authentication
  • Ping your delivery manager for assistance, if you haven't configured the 
  • Follow up correct authentication instructions according to selected authentication method
• Core, Professional or IGA solution
  • Follow correct configuration instructions for the directory, test the connection.

Configuration instructions for password self-reset for existing environment

• Create new One-Click-Demo (OCD) environment
• Self-Service
  • Create a new Self-Service site for password reset service
  • Import “change my password” service from (OCD) environment to the customer environment
  • Check that MyServices and other settings are same in the OCD and customer environment
  • Publish the service
• Authentication
  • Create new realm to the Secure Access component
  • Ensure that users are directed to Self-Service site where you published the password reset service
  • Follow correct Secure Access configuration instructions for the authentication method
• Core and Professional solution
  • Most likely customer already has connector towards the directory, so move to next step, but if needed create the new connector, follow correct configuration instructions according to the directory
  • Create event-based tasks according to the directory 
    • For Entra ID: Azure IGA Service request: Verify, Add, Remove
    • For AD: AD IGA Service request: Verify, Add, Remove
    • For OpenLDAP: OpenLDAP IGA Service request: Verify, Add, Remove
  • Validate that attributes, settings and mappings are same in the OCD and customer environment
  • Validate that IGA Service Request template contains all needed attributes, handlers and listeners
  • Verify that IGA Change Password Workflow uses correct event-based tasks you created
  • Publish IGA Change Password Workflow

Configuration instructions for Service Desk Agents for new environment

• Follow correct configuration instructions for the directory, test the connection.

Configuration instructions for Service Desk Agents for existing environment

• Create new One-Click-Demo (OCD) environment where you can export/copy configuration to existing enviroment
• Do following configuration changes into ESM (compare to OCD):
  • Ticket -template:
    • new attribute: Password reset
    • new attribute: Change customer password
    • edit class: Ticket description
      • attribute order numbers edited
    • new transform: IGA Account Actions
    • edit attribute: Self-Service item
      • “Show in view only”
    • edit listener: presave.FAIL changing ticket type to Service Order
    • new listener: presave.FAIL resolving without resetting password
    • edit worflow: Ticket workflow:
      • new workflow selection criteria: Status “equal to” 07 - Resolved.
  • Quickfill -template:
    • edit attribute: Type:
      • add value: Service Order
    • new attribute: Quickfill for password reset ticket?
    • new attribute: Self-service item
    • new datacard: Password reset from Ticket
  • Self-service item -template:
    • new datacard: Manual password reset
    • new attribute: Allow manually created requests
  • IGA Account Actions -template:
    • new attribute: Referring ticket
  • Permissions:
    • Service Desk Agent -role:
      • in Organization -module, IGA Account Actions -template: RCU
      • in Organization -module, IGA Account Actions -folder: RCU
      • Ticket -template, Password reset -attribute:
        • Read -permission
      • Ticket -template, Self-Service item -attribute:
        • all permissions must be allowed
• Also, do necessary changes according to chapter “Configuration instructions for IGA Admins for existing environment”

Configuration instructions for IGA Admins for new environment 

• Follow correct configuration instructions for the directory, test the connections.
• Validate if there is need to modify IGA Account Actions template or Account Management Action Workflow.
• Validate if there is need to modify permissions for "IGA Account actions" folder.
• Validate IGA Account actions related views:
  • All account actions by user
  • User's requesting most password reset's (yearly)
  • Account actions for disabled accounts
  • Account actions done out of office hours

Configuration instructions for IGA Admins for existing environment

• Create new One-Click-Demo (OCD) environment. 
• Create needed connections. Follow correct configuration instructions for the directory, test the connection.
• Create needed event-based tasks according to the directory 
  • Azure IGA Admin Actions: Reset, unlock, activate
  • AD IGA Admin Actions: Reset, unlock, activate
  • OpenLDAP IGA Admin Actions: Reset, unlock, activate
• Copy IGA Account Actions template and Account Management Action Workflow from OCD to existing environment. 
• Create "IGA Account actions" folder to Organization module for "IGA Account Actions" datacards.
• Set correct permissions for "IGA Account actions" folder.
• Created needed IGA Account actions related views:
  • All account actions by user
  • User's requesting most password reset's (yearly)
  • Account actions for disabled accounts
  • Account actions done out of office hours
• Verify that Account Management Action Workflow uses tasks you created from orchestration nodes. 
• Publish Account Management Action Workflow.

Testing preparations: 

1. Testing is done in test environment and against test directory (or test OU)
2. Create test users to the directory, and ensure that all needed information is in place
3. Ensure that end-users, agents and admins have correct accesses to Self-Service and to the M42 solution. 

Testing instructions for end-users:

1. Login using one of the test users and follow up the use case steps
2. After successful password change, login with the new credentials
3. Try testing also setting a password which does not match company policies
4. Validate that Self-Service has correct info text's, instructions, logo, colours, service names etc.
5. Validate password change requests are visible in my request view

Testing instructions for Service Desk Agent and IGA Admin:

1. Login to the Core or Professional solution
2. Create a new ticket and follow up the use case steps
3. Go to connector settings, disable connection to the directory and try re-testing password change
4. Change the settings back, and re-test password change
5. Test also other action type scenarios 
6. Validate that reports, views and dashboards are showing correct information
7. Login with the test user and validate that password change was successful