How does Joinly sync Kenjo to Active Directory?

Joinly reads each HR change in Kenjo in the cloud through the API, then hands the action to the Joinly AD Agent inside your network, which makes the change in Active Directory. Kenjo holds the authoritative employee record; the agent is the only component that touches your domain.

1. Joiner. HR completes the hire in Kenjo. Joinly reads the new record, determines the role from office, department, team and area, 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.

2. Mover. When someone changes department, team, office or area in Kenjo, 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 position is removed, so permissions stay aligned with the actual job.

3. Leaver. When Kenjo records that someone has left, Joinly instructs the agent to disable the AD account and optionally move it to a disabled-users OU, so there are no orphaned accounts left active after a leaver.

Example: An e-commerce and fulfilment company runs Kenjo and an on-premise AD across two warehouses. It hires a picker for its Rotterdam site. Joinly reads the Kenjo record, and the AD Agent creates the user in the Rotterdam > Fulfilment OU, sets a unique sAMAccountName built from a name rule, and adds the Warehouse-Ops group. Because the picker has no prior email, the login is generated from scratch. When that picker later moves to Returns, 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 Kenjo 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. Kenjo has no native AD provisioning, so there is no baseline to fall back on, and every decision falls to people.

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

• Permissions that don’t keep up (privilege creep). When movers change team or site, 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 — a real problem in high-turnover, shift-based fulfilment teams.

Joinly vs. the Entra provisioning agent for AD

Kenjo has no native path to on-premise AD, so the nearest alternative is Microsoft’s Entra provisioning agent fed by a custom Kenjo import. It can write attributes, but it stops short of the part that actually decides access. Here’s how the two compare for a Kenjo-driven AD setup.

Watch-outs when connecting Kenjo to Active Directory

A few details decide whether this connection stays reliable at scale.

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

• OU placement from Kenjo structures. Office, department, team and area don’t map one-to-one to your OU structure, and in an SME the data is often lighter than in enterprise HCM. Joinly builds explicit rules that place each user — and move them on a transfer — into the correct OU.

• API key scope on the Connect plan. The Kenjo API is enabled per account and each key is scoped. The key must be granted the office, department, team, area and employee endpoints. Joinly tells you exactly which scopes to enable, so the sync has the data it needs without over-granting access.

• High turnover and rehires. Shift-based workforces churn, and the same person may return. Joinly matches returning people to their existing AD object where possible instead of creating duplicates, and disables leavers promptly.

• 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 Kenjo change triggered it. For NIS2 that matters directly: access can be traced back to an authorised HR source rather than an ad-hoc request. 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 an e-commerce and fulfilment company with around 900 employees across two warehouses and a head office, running Kenjo for its shift-based teams but still living in an on-premise Active Directory for its warehouse and finance systems. Every new picker, packer or returns handler starts as a Kenjo record that IT processes by hand in AD — creating the object, choosing the OU, inventing a login, adding groups. Most warehouse staff have no email when they start, so there is nothing to copy, and with seasonal peaks the queue never empties. New joiners wait until day two or three for their account.

Connect Kenjo to Active Directory with Joinly and that work disappears. The Joinly AD Agent creates each user in the right OU on time, builds a unique sAMAccountName from a name rule, adds the correct security groups, moves people on a transfer between warehouses and disables accounts promptly on the leave date — all driven by the HR change in Kenjo.

“Warehouse staff start without an email, so every account was a manual build in AD. Now the object lands in the right OU with a unique login before the shift starts, transfers move themselves, and we can show the auditor exactly which Kenjo change created every bit of access.” — Head of IT, e-commerce and fulfilment company

The outcome this setup is designed for: onboarding drops from days to zero touch for shift staff, privilege creep from old teams is eliminated, and the team can walk into its next NIS2 assessment with a complete, source-backed audit trail.