Password writeback/sync issues

[koakd]

I inherited a JumpCloud MDM and the #1 complaint from users is that resetting their password in JC does not sync it everywhere. We have two directory integrations, MS365 and on-prem AD. The on-prem AD integration seems to be broken, as my none of the users were imported via it, and the JumpCloud AD group is empty. Yet, for some reason, all the users that were imported via MS365 had their Directory changed to on-prem AD. I assume this is why password sync does not work.

I have been testing moving a user back to the MS365 directory, but I'm hitting a wall when they reset their password- it resets JC and MS365, but it never triggers a writeback to on-prem. I know Password Writeback is working, because If I reset the password through 'My Account' in MS365 it writes back correctly. Any advice?

[BrightRodger]

Hi @koakd it seems as you might have a few things going on.

First the M365 integration and AD integration can often be configured and bound to a user simultaneously. It sounds like your users are not bound the M365 connector, and that when you do bind users to the M365 connector that JumpCloud successfully takes over the ownership of that user and can update the password.

Then it also appears the JumpCloud Sync agent config needs to be verified. Note that it is possible to use JUST the sync agent within JumpCloud, bind a user directly to that AD directory, directly, NOT add them to the "JumpCloud" user group, and this will allow the updates of user passwords FROM JumpCloud into your AD environment. Here is how to configure the Sync agent properly.

Here is what a user bound in this manner looks like (See the user without the AD Integration icon)

Lastly, you mention  "I know Password Writeback is working, because If I reset the password through 'My Account' in MS365 it writes back correctly." This leads me to believe that when you are updating a user's password within M365 that the password change is also propagated to on-Prem AD.  If that's the case this likely means this user is considered a "Directory Synched" user and that you are likely propagating this user to AzureAd via the AzureAd Connect app running on your on-prem AD server. 

For JumpCloud to reliably control and update the user within AzureAD that user must be a "Cloud Only" user and not a Dir-Synched / Hybrid / Directory Synched user. Meaning the user must not be one that is constantly updated via another utility from on-prem AD.

The most common scenario is that users are converted to Cloud Only within AzureAD, 2 way sync is configured between JumpCloud <-> Active Directory, and JumpCloud is the source-of-truth for users and passwords and propagates those user changes to AzureAD and to AD directly.  AD and AzureAD are not directly connected with this configuration.  This allows a user to update their password within AD (if they are on an AD-member windows computer for example), or within JumpCloud (using CTRl-ALT-DEL on a JumpCloud managed windows device for example), and the password will be synced to all places.

If you can reply back with some specifics of how your environment is setup we can give some additional direction!