How does Joinly sync Rippling to Active Directory?

Joinly reads each HR change in Rippling in the cloud, then hands the action to the Joinly AD Agent inside your network, which makes the change in Active Directory. Rippling holds the authoritative employment record; the agent is the only component that touches your domain — your AD stays the directory of record.

1. Joiner. HR completes the hire in Rippling. Joinly reads the new employee, determines the role from department, role and work location, and instructs the AD Agent to create the user in the correct OU, build the sAMAccountName and UPN from your rules, and add the right security groups — timed to the start date recorded in Rippling.

2. Mover. When someone changes role, department or work location in Rippling, Joinly tells the agent to move the user to the matching OU, swap security-group membership and update attributes. Access that no longer fits the new role is removed, so permissions stay aligned with the actual job.

3. Leaver. On the termination date recorded in Rippling, Joinly instructs the agent to disable the AD account and optionally move it to a disabled-users OU, so no orphaned account stays active after someone has left.

Example: A distributed startup runs Rippling for HR and payroll but keeps an on-premise Active Directory domain for its file servers and line-of-business apps. It hires a support engineer with a start date next Monday in the Customer Success team. Joinly reads the record, and on Monday morning the AD Agent creates the user in the Sites > Remote > CustomerSuccess OU, sets the sAMAccountName to a unique pattern, and adds the CS-Engineers group. When that engineer later moves to the Implementation team, the agent moves the object to the new OU and swaps the groups the same day.

What manual AD account management costs

Without automation, every account starts as a Rippling notification that an admin works through in Active Directory Users and Computers by hand — creating the object, choosing the OU, building the sAMAccountName, adding groups. Rippling can push to AD through the Entra provisioning agent, but it’s built to be the identity provider and offers limited OU placement and no real role-to-group logic, so when AD is your directory of record the decisions still fall to people.

• Onboarding delays. New joiners wait for an AD account and group access while a request sits in a queue, losing productive days in their first week.

• Permissions that don’t keep up (privilege creep). When movers change role or department in Rippling, old security-group membership often stays attached, so people accumulate rights they no longer need.

• Forgotten offboarding. Accounts that aren’t disabled on time are a security and audit risk, and a stale enabled account in your domain is exactly what an auditor flags.

Joinly vs. Rippling’s own provisioning into AD

Rippling can write to on-premise AD through the Entra provisioning agent, but it’s designed to be the identity provider, and it stops short of the part that actually decides access. If your domain is the directory of record, here’s how the two compare.

Watch-outs when connecting Rippling to Active Directory

A few Rippling-specific details decide whether this connection stays reliable and stays under your governance.

• Rippling wants to be the IdP. Rippling is built to be the identity provider. If your on-prem AD is the directory of record, you don’t want Rippling running a parallel identity system — Joinly keeps AD as the directory and uses Rippling purely as the HR source, so your domain stays authoritative.

• OU placement from Rippling structures. Role, department and work location don’t map one-to-one to your OU structure. Joinly builds explicit rules that place each user — and move them on a transfer — into the correct OU.

• sAMAccountName uniqueness and length. AD limits the sAMAccountName to 20 characters and it must be unique across the domain. Joinly builds it from your rules with a fallback pattern, so duplicate names never produce a collision or a truncated, unreadable login.

• No inbound SCIM endpoint. Rippling is an outbound IdP, not a downstream SCIM app, so you can’t treat it like a standard SCIM source feeding AD. Joinly reads the Rippling REST API directly, which is how Rippling actually exposes employee, department and role data.

• Service-account permissions. The agent acts under a service account with delegated rights. Joinly works with least-privilege delegation scoped to the target OUs, so the agent can create, move and disable users without domain-admin rights.

Joinly handles each of these by default with custom mapping and transformation.

Always audit-ready

Every account action the Joinly AD Agent performs is logged in the Joinly cloud: who was affected, when it happened, which OU and groups changed and which Rippling change triggered it. For NIS2 that matters directly: access can be traced back to an authorised HR source rather than an ad-hoc request — and the trail covers the domain you govern, not just what Rippling did on its side. Joinly is ISO 27001 certified, runs in an EU data centre in Amsterdam, applies least-privilege by default, and is built to meet NIS2 and ISO 27001.

Example case

Take a distributed startup with around 350 employees that adopted Rippling for HR and payroll but still runs an on-premise Active Directory domain for its file servers, VPN and a few line-of-business apps. Rippling keeps positioning itself as the identity hub, but the AD security groups that gate the file shares and the VPN are governed in the domain — so every new hire still starts as a manual job in Active Directory Users and Computers: create the object, pick the OU, build the login, add groups.

Connect Rippling to Active Directory with Joinly and that work disappears. The Joinly AD Agent creates each user in the right OU on the start date, builds a unique sAMAccountName, adds the correct security groups, moves people on a transfer and disables accounts on the termination date with a 30-day grace window — all driven by the HR change in Rippling, while AD stays the directory of record.

“We use Rippling for HR, not as our identity system. Now an account is simply ready in the right OU on the start date, transfers move themselves, and we can show the auditor exactly which Rippling change created every bit of access in our domain.” — Head of IT, distributed startup

The outcome this setup is designed for: onboarding drops from days to zero touch, the on-prem domain stays the single directory of record, and the team can walk into its next NIS2 assessment with a complete, source-backed audit trail.