Identity and access management
Keka to Active Directory integration: domain accounts per office, with expiry on the exit date
With an integration between Keka and Active Directory, a new employee from Keka gets a domain account in the OU of their office and worker type, with job title, groups and manager, and the account expires on the exit date in Keka. KoppelHet builds that integration with a small program in your domain.
What the integration does
Organisations that use Keka worldwide for HR and have their own Windows domain for their offices in Europe often create accounts in that domain by hand. They go through email or tickets, and an exit often only reaches IT after the last day.
- We record which offices belong to this domain and which Keka groups become which security group.
- An administrator sets up event triggers in Keka with a webhook to KoppelHet.
- On a notification the platform fetches the employee and sends the program in the domain an instruction.
- The program creates the account in the right OU, with job title, groups and manager.
- An approved exit becomes the expiry date; a cancelled exit removes it again.
What to watch for with Keka and Active Directory
- A webhook from Keka only contains the employee's identifier, the event type and the subdomain. The platform then fetches the employee through the API, so the program in the domain never talks to Keka itself and the data comes from one source.
- Keka gives the worker type for every employee and whether someone is a contingent worker. KoppelHet puts external workers in their own OU with a shorter expiry date, so a different policy can apply there than to permanent employees.
- An exit in Keka is only final after approval, and HR can still cancel it afterwards. KoppelHet sets the exit date as the expiry date as soon as the exit is approved, and removes it on a cancelled exit, so someone who stays after all can simply keep working.
- The exit date comes from Keka as a date with a time. An Indian tenant and a Dutch domain are hours apart; KoppelHet converts the date to the end of the working day in the office's time zone before setting accountExpires.
- Keka allows fifty API requests per minute. For the first fill of the domain KoppelHet only requests the employees of this office, in pages of two hundred, and after that only those changed since the previous run.
- Keka has three managers per employee, namely reportsTo, an l2Manager and a dotted line manager. In Active Directory, manager is a single reference to the manager's account, as a distinguished name. KoppelHet only uses reportsTo, looks up the account through employeeID and leaves the field empty if the manager works outside this domain.
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 anything need to be opened in the firewall?
No. Keka's webhook arrives at the KoppelHet platform; the program in the domain only makes an outbound connection.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Keka API (https://{company}.keka.com/api/v1) with a token from login.keka.com/connect/token (client_id, client_secret, api_key, scope kekaapi). GET /hris/employees with lastModified and employmentStatus (Working, Relieved); fields employeeNumber, jobTitle, groups, reportsTo, city, countryCode, workerType, contingentType, exitDate and exitStatus. Event triggers (Settings > Communications > Event Triggers) with a webhook action.
- A KoppelHet agent on a Windows server in the domain fetches instructions through an outbound connection and writes employeeID, sAMAccountName, userPrincipalName, givenName, sn, displayName, title, department, manager and accountExpires, manages groups and moves accounts between OUs.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Keka | Field in Active Directory | Notes |
|---|---|---|
employeeNumber | employeeID | At most 16 characters |
Naamgevingsregel | sAMAccountName en userPrincipalName | sAMAccountName at most 20 characters |
firstName en lastName | givenName, sn en displayName | |
jobTitle | title | |
groups | department en beveiligingsgroepen | |
city en workerType | OU | |
reportsTo | manager | |
exitDate | accountExpires |
Related
Keka → ADP iHCM
Keka to ADP iHCM integration: salary structure, variable payouts and leavers of the Dutch pay group to ADP
Keka → AFAS Profit
Keka to AFAS integration: Dutch employees from Keka in payroll
Keka → Arbodienst (SIVI)
Keka to the occupational health service via SIVI: sickness leave requests as absence reports
Keka → DATEV
Keka to DATEV integration: the German entity from Keka to the tax adviser in DATEV