[GH-ISSUE #1052] [FEATURE REQUEST] Allow synchronization with Microsoft Entra ID #376

New issue

Open

opened 2026-02-27 08:16:56 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 08:16:56 +03:00

Owner

Originally created by @tiehfood on GitHub (Nov 26, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/1052

Motivation

I want to manage my users in Microsoft Entra ID, but in my local LAN I want to be independent from cloud services.
Ideally I could sync the users from Entra ID to lldap and use lldap as local source for my users.

Originally created by @tiehfood on GitHub (Nov 26, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/1052 **Motivation** I want to manage my users in Microsoft Entra ID, but in my local LAN I want to be independent from cloud services. Ideally I could sync the users from Entra ID to lldap and use lldap as local source for my users.

kerem added the

labels

2026-02-27 08:16:56 +03:00

kerem commented

2026-02-27 08:16:56 +03:00

Author

Owner

@nitnelave commented on GitHub (Nov 26, 2024):

It looks like the way to go is with the Microsoft Entra Connect https://learn.microsoft.com/en-us/entra/architecture/sync-ldap

I haven't tried making it work (and I'm not likely to go through an entire AD setup just to test LLDAP). You can give it a try. However, I don't really expect it to work out of the box; Windows in general and AD in particular is more geared towards heavy-weight situations, enterprise. As such, it requires a lot of features from the LDAP server, many of which are likely not implemented. There's an effort to implement a basic schema message in LLDAP, to support reporting the current schema, but I don't expect it to work well with AD. In particular, any synchronization from AD back to LLDAP is most likely going to fail, the gap is just too big.

Some of the blockers:

no per-user objectClass (in LLDAP, object classes apply to all users or all groups)
no per-class attributes
no attribute rules
lots of mutation operations are not implemented via LDAP, only via GraphQL
the directory structure is fixed (one OU for users, one for groups)

And so on. Synchronization would likely require us to implement a full-fledged generic LDAP server, which is entirely out of scope for LDAP.

Maybe there's a way to connect the AD instance to just read from LLDAP. In that case, you may stand a chance, as long as all you need from your AD is users and groups (no custom object classes, no machines, ...). Feel free to give this a try, and we can see what's missing.

@nitnelave commented on GitHub (Nov 26, 2024): It looks like the way to go is with the Microsoft Entra Connect https://learn.microsoft.com/en-us/entra/architecture/sync-ldap I haven't tried making it work (and I'm not likely to go through an entire AD setup just to test LLDAP). You can give it a try. However, I don't really expect it to work out of the box; Windows in general and AD in particular is more geared towards heavy-weight situations, enterprise. As such, it requires a lot of features from the LDAP server, many of which are likely not implemented. There's an effort to implement a basic schema message in LLDAP, to support reporting the current schema, but I don't expect it to work well with AD. In particular, any synchronization from AD back to LLDAP is most likely going to fail, the gap is just too big. Some of the blockers: - no per-user objectClass (in LLDAP, object classes apply to all users or all groups) - no per-class attributes - no attribute rules - lots of mutation operations are not implemented via LDAP, only via GraphQL - the directory structure is fixed (one OU for users, one for groups) And so on. Synchronization would likely require us to implement a full-fledged generic LDAP server, which is entirely out of scope for LDAP. Maybe there's a way to connect the AD instance to just read from LLDAP. In that case, you may stand a chance, as long as all you need from your AD is users and groups (no custom object classes, no machines, ...). Feel free to give this a try, and we can see what's missing.

kerem commented

2026-02-27 08:16:56 +03:00

Author

Owner

@languagegame commented on GitHub (May 18, 2025):

Microsoft Entra ID is free to use, so why not just manage all your users there? Or create a second Entra ID tenant for your local users. If you also need an LDAP server on your LAN for legacy applications and you want to avoid having to setup a full active directory domain, AzureAD-LDAP-wrapper might work. It only supports NT4 style authentication though (no Active Directory or Kerberos)

@languagegame commented on GitHub (May 18, 2025): Microsoft Entra ID is free to use, so why not just manage all your users there? Or create a second Entra ID tenant for your local users. If you also need an LDAP server on your LAN for legacy applications and you want to avoid having to setup a full active directory domain, [AzureAD-LDAP-wrapper](https://github.com/ahaenggli/AzureAD-LDAP-wrapper) might work. It only supports NT4 style authentication though (no Active Directory or Kerberos)

kerem referenced this issue

2026-02-27 09:09:26 +03:00

[PR #376] [CLOSED] build: fix release content #706