AD Passwords Not Syncing to Office365

[SJ98]

Hello,

 

 

We've been doing some internal migration from on-premise to Azure, and we made a decision to migrate the active directory sync service from one server to another (so that we can shut the old server down).

Since then, all accounts that we make in AD will happily sync over to Office365 every half hour, but the passwords are a bit irregular.

 

My password for example, is one of my older passwords as I had changed it recently, and as you would expect, it should have updated to the new one on the next sync.

Here's the weird thing, I created the new Year 7 accounts on Friday, and tested one of their accounts by changing the password. It did eventually change it on Office365 to the new password, but the sync was a lot longer to realise the password had changed.

 

So I don't know how to proceed, because nothing is saying its wrong and certain stuff is still syncing over?

[Roberto]

certain stuff is still syncing over?

 

What's still syncing? How is password sync configured?

 

If your initial sync is running still then, iirc, normal password sync won't work until that's completed. What do the event viewer logs related to password changes say on the AD Connect server?

[SJ98]

The server where the initial sync was has been turned off for some time now - so I wouldn't expect this to be running.

The logs claim that everything should be working as normal.

 

Right now, If I create new accounts, they get synced every half hour and they do. But passwords do not. But I tested a student account on Friday, and the new password didn't work. Came back to work this morning and tried the new password again on O365 and it worked.

[Steve21]

How long did you wait on Friday? Password sync is much quicker than user, as it runs on a different sync cycle every 2 minutes (+ up to 15 mins delay between DC syncing if you have multiple due to replication etc), so within 20 mins top it should have changed if your sync is working fine

 

Steve

[SJ98]

I must've waited about an hour between the sync from memory.

[Roberto]

The server where the initial sync was has been turned off for some time now - so I wouldn't expect this to be running.

The logs claim that everything should be working as normal.

 

Ok. When you create (or change settings on) an AD Connect connection, the first sync that runs on that server, the "initial" sync if you will, will be a full sync. Additional syncs on that server are Delta syncs. I've seen passwords take a while to sync in exactly the way you describe when a full sync was in progress. So, is a full sync in progress?

 

With regards to logs, when you attempt to change a password, there should be logs in the event log on the AD connect server pertaining to the password change. Can you see them?

 

Right now, If I create new accounts, they get synced every half hour and they do. But passwords do not. But I tested a student account on Friday, and the new password didn't work. Came back to work this morning and tried the new password again on O365 and it worked.

 

So the password sync is taking place, but slowly.

 

How familiar with AD Connect are you? Are you familiar with the Synchronization Service Manager? That should show the sync progress, errors, etc. I really feel like the solution, or the beginning of one at least, might be there.

[SJ98]

Just a quick update - I have tried the password change on a test staff account that we have, and after about 2 hours (ish) it did change the password on O365.

But my password has not changed still?

 

The log that we can see is a delta log when looking at the Synchronization Service Manager. It doesn't look like a full sync is in progress? This was carried out sometime earlier last week/ the week before too.

We can't see any specific logs for password changes - where specifically would they be located in event viewer?

[robintech]

I'd pretend you have no sync and run the Troubleshooter

 

Invoke-ADSyncDiagnostics -PasswordSync.

 

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/tshoot-connect-password-hash-synchronization

[SJ98]

ittech2342323,

I ran that, the below is what it returned, X is our domain name that I have just replaced:

 

AAD Tenant - XPassword Hash Synchronization cloud configuration is enabledFalseAD Connector - XPassword Hash Synchronization is enabledLatest Password Hash Synchronization heartbeat is detected at: 08/05/2024 11:55:59 UTC Directory Partitions: ===================== Directory Partition - XFalseFalseFalse Last successful attempt to synchronize passwords from this directory partition started at: 8/5/2024 12:01:59 PM UTC and ended at: 8/5/2024 12:02:01 PM UTC Only Use Preferred Domain Controllers: False Checking connectivity to the domain... Domain "X" is reachable

[SJ98]

On Synchronization Service Manager, I can see there is a Delta Import log at 7:50 saying that there's 1 update. Clicking that update, I can see it was the test account and what OU it is in etc. This is a Delta Import on our domain name.

Then, there's a Delta Synchronization seconds later with the same information on the domain name.

Then, seconds after that, again states an update for an Export on our .onmicrosoft.com AAD

 

At 8:20, it comes up again on our domain name with a Delta Import with the same update information, just the one account that I have changed a password to.

Same cycle of information until 8:50. The logs after 8:50 (which is 9:20) does not have the update anymore.

 

EDIT: I have just changed my password, and the sync at 13:20 doesn't show any changed data. 0 on everything except Discovery > Filtered Objects = 2.

Edited August 5, 2024 by SJ98

[robintech]

I'm not sure then, was hoping it would say high number of failures or something about a local DC,

do the entra.microsoft.com audit logs show what UPN changed the test accounts password

[SJ98]

Yes, it says the name of the new server as the email

server [email protected]

[snagrat]

Check event log as password syncs are noted there.

 

The delta syncs do not do passwords so it will not show any changes.

 

Look for eventID 656 and 657

[SJ98]

Look for eventID 656 and 657

Thank you for providing these IDs.

These IDs do show up, but I can not see any of these IDs relating to my account specifically after I changed my password yesterday.

I can see there's an eventID for 656 and 657 for my staff test account, and even someone else who has had to change their password yesterday (again just a standard teacher).

 

So again I am not sure where it is going wrong? And the fact it takes longer than usual to sync the password?

[SJ98]

After looking into it further - it seems the whoever has set the new sync up mustn't have put specific OU's into the AAD sync, as I have moved an account from one OU to another, and all of sudden it has started to sync with the Synchronization Service.

Annoyingly I cannot access this as I have to wait for the person who has the password for the AD Connect so that we can manage what OUs get picked up.

 

It still doesn't explain why the sync is slow though? Is there somewhere in AD Connect where you can set how long the sync takes or something along those lines? I'll update again when I can actually get access to the configuration.

I would like to say that I've learnt quite a bit about diagnosis for this specific service, and I'd like to thank you all for your insightful knowledge in-case I need to diagnose certain things about this again in future.

[Roberto]

After looking into it further - it seems the whoever has set the new sync up mustn't have put specific OU's into the AAD sync, as I have moved an account from one OU to another, and all of sudden it has started to sync with the Synchronization Service.

Annoyingly I cannot access this as I have to wait for the person who has the password for the AD Connect so that we can manage what OUs get picked up.

 

I think you might have one or two OUs excluded for local accounts, leavers, or whatever, but by and large AD connect should be scoped to most or even all OUs.

 

It still doesn't explain why the sync is slow though? Is there somewhere in AD Connect where you can set how long the sync takes or something along those lines? I'll update again when I can actually get access to the configuration.

 

AD Connect Delta syncs should run every 30 mins or so on a normal basis and while you can manually trigger a sync more frequently if you need to do so, you shouldn't need to do that too often. I think you can change the scheduled sync but 30 mins is the most frequent option.

 

Password sync should happen more frequently, every 2 mins as has been said elsewhere. It might be worth looking in Entra ID at the Entra ID Connect setting in there to see what it thinks is going on with sync server health, etc.

 

I'd paste a screen shot to show you what I mean, but unfortunately one of my colleagues has nuked my dev environment and I can't share anything from prod.

Edited August 6, 2024 by Roberto

[snagrat]

After looking into it further - it seems the whoever has set the new sync up mustn't have put specific OU's into the AAD sync, as I have moved an account from one OU to another, and all of sudden it has started to sync with the Synchronization Service.

Annoyingly I cannot access this as I have to wait for the person who has the password for the AD Connect so that we can manage what OUs get picked up.

 

It still doesn't explain why the sync is slow though? Is there somewhere in AD Connect where you can set how long the sync takes or something along those lines? I'll update again when I can actually get access to the configuration.

I would like to say that I've learnt quite a bit about diagnosis for this specific service, and I'd like to thank you all for your insightful knowledge in-case I need to diagnose certain things about this again in future.

 

Any Admin account can do it. Just replace the username when going into the containers section and use the correct password

[SJ98]

Just to close off - the sync is now doing passwords of all users, including myself.

Apparently the settings were exported from our old one and then imported into the new one, but this can't be the case as the sync hasn't been working the way that it used to.

Either way, sorted now. Not tested how long the sync takes, but at least it works.