Sync passwords to Active Directory

Sync passwords to AD — the toggle in Active Directory settings — makes your on-premise connector apply password changes made in Realsmart to the matching AD account, so a person has one password for both. It needs the connector installed and running (see Set up Active Directory sync).

How it works

Once the toggle is on, every password change made in Realsmart is queued for the connector. The connector collects the queue each time it runs — how often that is depends on the scheduled task on your server (a full run, or a password-only run) — and sets the password on the AD account with the same username. Passwords are stored encrypted, only ever read by the sync, and never displayed anywhere in Realsmart.

While your school's cloud sync is paused for the summer, the connector collects nothing: changes wait, and the latest one per person goes to AD when sync resumes.

A password only counts as done when the connector reports that AD has set it, so it stays in Pending password updates on AD password updates until then. If the connector collects a password and never reports it set — AD refused it, or the connector couldn't find the account — Realsmart offers it again on the connector's first run at least 6 hours later, up to 4 times in all. With a password-only run every few hours that takes about a day; if the connector only runs once a night, it takes four nights. Then it stops: the person is listed under Not confirmed by AD on AD password updates, and the failure shows in Logs. A newer password for the same person always replaces one that is still waiting.

The AD password updates page shows the log of captured changes, how many are still waiting for AD to confirm, anyone AD never confirmed, and when the connector last ran.

Email confirmations

When the connector confirms passwords have been set in AD, a summary email goes to the Email in the Technical box under School settings → Details → School contacts. It's sent at most once an hour, with a subject like AD Sync - 12 passwords updated, and lists every password updated in that hour, so a bulk reset produces one email rather than one per person. If more than 100 users were updated in the hour, the email lists the first 100 and gives a count for the rest — the full record is always on the AD password updates page. If the school has no technical email saved, no email is sent. Passwords AD never confirmed aren't emailed; they're listed under Not confirmed by AD on that page.

What is sent

Any password change made in Realsmart, whichever way it happens:

• A person changing their own password — on their Profile page in SmartLogin, or when Realsmart makes them change it at sign-in.
• An admin setting a password for one user, or for a selection in bulk (Users → Password actions → Set password).
• Passwords imported from a CSV or generated by the password wizard.
• Reset to default — from a user's edit page, the Users bulk actions, or the Reset passwords page.
• Changing the school default with Also update existing members who still have the old default password ticked in Password settings — every member moved to the new default is sent.

What isn't sent

• Nothing happens when you turn it on. Enabling the toggle only captures changes made from that point on — it doesn't push anyone's current Realsmart password to AD. So your current default won't become the AD password just by enabling the feature; see Step 3 for how to line existing users up.
• Brand-new accounts. The connector creates a new AD account with the Default staff / student password from Active Directory settings, not the Realsmart default. The account picks up the Realsmart password the first time it's set or reset in Realsmart afterwards. A password set in Realsmart shortly before the account existed is still tried up to 4 times (see How it works), so it reaches the new account if the connector creates it in that time.
• Passwords your domain rejects. Your AD domain's own password policy still applies. The connector sets passwords as an administrator reset, so AD checks complexity and length; password history and minimum age normally apply only when people change their own password. If AD refuses a password, that AD account keeps the password it already had. Realsmart tries the password up to 4 times (see How it works), then lists the person under Not confirmed by AD on AD password updates. Fix the cause — usually a password that meets the policy — and set or reset the password again. It's worth checking the Realsmart default meets your AD policy before you reset a whole year group. The connector's log on your server (see Set up Active Directory sync) records each person it couldn't update, and why.