

Identity and access management
Loket to Active Directory integration: domain accounts per employer from Loket
With an integration between Loket and Active Directory, KoppelHet creates a domain account for a new employee in Loket in their employer's OU, with name, department and photo, and disables the account after the end of employment. The end date is also set as the account's expiry date, so it stops on time even if nobody acts.
What the integration does
Organisations with several employers in Loket and their own Active Directory often create accounts from a form filled in by a manager. With a lot of joiners and leavers that falls behind, and names with a partner name are written differently each time in the domain.
- IT installs a small KoppelHet program once on a server in the domain.
- KoppelHet fetches the changes per employer from Loket since the previous round.
- For a new employee the program creates an account in the employer's OU, with a logon name according to your rule and the name as the employee calls themselves.
- The photo from Loket goes to the account, resized.
- After the end of employment the account is disabled and moved to the leavers OU.
What to watch for with Loket and Active Directory
- Loket supplies the name in separate parts, including prefix and partner's name. A logon name in Active Directory may have at most 20 characters, so KoppelHet builds it from the own surname according to your rule, while the display name shows the partner's name if the employee uses it.
- If an employee changes their name usage, for example after marriage, KoppelHet updates the display name and email address, but the logon name stays the same. That keeps linked systems and folder permissions working.
- The photo in Loket can be larger than the 100 kB Active Directory allows for a photo. KoppelHet resizes it first, so the photo reaches the address book instead of the update failing.
- Loket sends no notifications to other systems. KoppelHet's platform requests the changes, and the program in the domain only collects the instructions; nothing needs opening in the firewall.
- Each employer in Loket gets its own OU. Group policy and email domain can then differ per employer, and a move between two employers moves the account instead of creating a new one.
- The end date of employment goes onto the account as its expiry date. If the program in the domain is off that day, the account still cannot be used after that date.
This integration is also part of joiner, mover, leaver.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Does a port need to be opened in our firewall?
No. The program in your domain only makes an outbound connection to KoppelHet's platform.
A payroll bureau manages our Loket. Is that possible?
Yes. The integration gets read access to your employers; the bureau's other clients stay out of view.
What can be traced afterwards for an audit?
Every action of the integration is recorded in the audit logging of the KoppelHet platform. KoppelHet works with an ISO 27001 certified management system.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Loket is read through the Loket REST API with OAuth (authorization code flow with refresh token), per employer through the mutations on employee and employment; fields include employeeNumber, firstName, prefix, lastName, prefixPartner, lastNamePartner, photo and the start and end date of employment.
- A KoppelHet agent on a Windows server in the domain writes employeeID (at most 16 characters), sAMAccountName (at most 20 characters), userPrincipalName, mail, givenName, sn, displayName, title, department, company, thumbnailPhoto (at most 102,400 bytes) and accountExpires, and moves accounts between OUs.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Loket | Field in Active Directory | Notes |
|---|---|---|
employeeNumber met werkgeverscode | employeeID | At most 16 characters |
firstName | givenName | |
prefix, lastName, prefixPartner en lastNamePartner | sn en displayName | According to name usage |
Naamgevingsregel | sAMAccountName | At most 20 characters |
Naamgevingsregel met domein per werkgever | userPrincipalName en mail | |
Werkgever | OU en company | |
Organisatorische eenheid | department en groepen | |
Functie | title | |
photo | thumbnailPhoto | Resized to below 100 kB |
Einddatum dienstverband | accountExpires en uitschakelen |
Related
ADP Workforce Now → Loket
ADP Workforce Now to Loket integration: hires, pay, hours and bonuses from ADP to the Dutch payroll run
AlexisHR → Loket
AlexisHR to Loket integration: employees of the Dutch company from AlexisHR into payroll
BambooHR → Loket
BambooHR to Loket integration: HR changes from BambooHR for Dutch payroll
Bullhorn → Loket
Bullhorn to Loket integration: placement as a concept employee in the right payroll administration