How Do I Allow Non-Desktop Users to Reset Their Own Passwords?

Applies to: Nerdio Private Cloud (NPC) and Nerdio for Azure (NFA) Professional and Enterprise (RDS)

Refer this KB article if you need help to determine if you are a NFA user.

Exception: This article does not apply in NFA Hybrid AD setups (domain trust between Azure and alternate environment), and in NFA AVD setups.

Important Note: We highly recommend performing the following steps using a test user before introducing the new functionality to production users

  • Setting up new Integration Policy (to sync groups other than the default of VDI / RDS and IT Department Group) – primarily used for non-desktop users to reset passwords externally
    • Create a new security group that the new users will be members of (i.e. Non-Desktop Users)
    • Log in to SMS Admin Portal (http://dc01:2000)
    • Under Policies, select User Integration Policies
    • Select 'Add New User Integration Policy'
      • Set the Name (description field) – such as “Non-Desktop Users”
      • Mark to be Enabled, Directory Type of AD, Refresh Interval of 5 minutes (the lowest), Default Prefix as System, and AD lockout check interval at 15 seconds (lowest)
      • Depending on if the group needs 2FA access, set the User Group Policy to 2FA Users, otherwise select Default User Group Policy (bypass 2FA on desktop login, but requires 2FA for PRWS access)
      • Set the priority to match – higher number takes precedence. By default: IT Department Group is priority 1, VDI / RDS Users are priority 10, and 2FA users are priority 20
      • Under the Data Source tab, can leave all settings default except for Group Name – set this to the name of the Security Group used to sync the new users (i.e. Non-Desktop Users)
      • No changes needed under Data Mapping tab
      • Under Data Filtering tab, de-select phone number required (unless the policy is for 2FA users)
      • No changes needed under Data Transformations
      • Click Save to finish
    • Add members to the new security group, and then click Sync All in SMS Passcode Admin Portal and verify Imported Users count for the new Integration Policy matches appropriately


  • Manual vs Synced Personal Passcode
    • By default, personal passcodes are minimum 4 digit codes that users will specify individually within the Self-Service Website (http://dc01:3000). This is accessible only within the environment or across a VPN tunnel – cannot be accessed externally
    • Users that need to reset AD passwords and do not have a desktop, or do not have access to DC01 across the network would need to have their personal passcode specified for them, either on an individual basis or by syncing from an AD attribute.
    • If syncing the personal passcode from an AD Attribute, I’d recommend using the Pager field as that’s available to edit in NAP.
    • To enable syncing the personal passcode (sync will overwrite any pre-existing user assigned passcodes, even if the AD attribute is empty), find and edit the desired User Integration Policy within the SMS Passcode Admin Portal (for example, Non-Desktop Users):
      • On the Data Mapping tab, for the Personal Passcode field, change the selection box from ‘Do not import’ to ‘Import from attribute(s)’. Enter the attribute from which the passcode should be synced (for example, ‘pager’)
      • Select Save to finish
      • Verify under Maintain Users by editing a user that’s assigned to the Integration Policy that their personal passcode is now showing as syncing from AD (under the User Group Policy Settings tab)
    • When not syncing the personal passcode, to edit an individual users passcode (to assign or reset), find the user under Maintain Users and select Edit
      • Under the User Group Policy Settings tab, find the Personal Passcode field.
      • The field will either say ‘No personal passcode has been defined’ or ‘User-specified passcode has been defined’ - Select the Override checkbox to assign or change the passcode
      • Enter the users new passcode, and select Save to finish


  • Password Reset Website (PRWS) functionality
    • PRWS is an external facing website that’s hosted on RDGW01 (NFA) or SG01 (NPC). The website would be located at (NFA) or (NPC)
    • NAP has an option under Security Settings to enable or disable licensing for the PRWS functionality (disabled by default).
      • Enabling the PRWS license will allow users to reset their AD password externally without needing to be logged into the network. They must have a Personal Passcode previously specified and also have a mobile phone number assigned to their account that can receive either a text message or voice call.
    • If the license happens to not be enabled when NAP turns the feature on, it can manually be enabled in the SMS Passcode Admin Portal
      • Under Policies, select User Group Policies
      • For each User Group Policy present, select Edit and go to the License Tab
      • Select the Granted checkbox for Password Reset CAL, then select Save to finish
    • The service backing PRWS is installed to DC01, and requires credentials of a user account that has the ability to reset passwords. By default, we provide the administrator credentials, but other admin user account would work.
      • To change credentials, on DC01 launch the SMS Passcode Configuration Tool (orange circle with a gear icon)
      • On the Password Reset tab, enter a username and password under ‘Password reset account’. This user object will be the one executing password reset changes
      • Note that no server name needs to be specified, since the service is running on the domain controller
      • Select Test to confirm the service is working, and select Safe to apply.


  • SMS Passcode / PRWS User Experience
    • In order for 2FA or PRWS features to work, users must have a phone number assigned to their AD object – this is generally added via NAP when the user is created
    • When signing in to a VDI or RDS session with 2FA enabled, users will login as normal and then be prompted for a 2FA code. They will receive a text message (followed by a voice call if not entered within the given time frame) with a unique code that must be entered in order to log in
    • The Password Reset Website is available for all AD users, provided their user account has been synced into SMS Passcode from AD. Using PRWS requires the user account have an assigned mobile number (that can receive texts or voice calls) and also a personal passcode
      • The personal passcode is generally less secure than their password, minimum of 4 characters by default, and should be something that’s easily recalled in case they forget their AD password
    • Users with access to DC01 (typically VDI/RDS users) can set their personal passcode by signing in to the Self-Service website at http://dc01:3000 using their AD credentials. The personal passcode can be changed or updated at any time
      • The only exception here is if the personal passcode field is being synced from an AD attribute, in which case users cannot override their passcode at SSWS
    • When using the PRWS, users will visit the website and enter their FQDN (typically email address)
    • Next they will be prompted for their personal passcode – note that this is NOT their AD password, this is the passcode that is either set by the user or by the admin
      • If there is no personal passcode specified, the field will still appear but no input will be successful. A personal passcode is required
    • Once the correct passcode is entered, they will then be prompted for a 2FA code. They will receive a text message (followed by voice call) at the phone number specified on their AD user account
      • If they do not have a mobile number assigned to their account, the PRWS will display an error and kick back to the starting screen. A phone number is required for the AD password to be changed
    • Users will have a limited amount of time to enter the generated 2FA code, and a timer is displayed on the screen
    • Once the 2FA code is entered, users are prompted to enter their new AD password. Once entered, PRWS will change their password in AD


Was this article helpful?

0 out of 0 found this helpful
Have more questions? Submit a request

Comments (0 comments)

Article is closed for comments.