Fancied taking a break from refactoring in v4.0.x. https://github.org/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/sites-avai... The idea is that you can "listen" on DNs within your LDAP directory. You then use the updates you receive to create/invalidate cache entries, or send CoA/DM messages to reflect the changes that have occurred in LDAP. Feel free to try it out, with the normal caveats about v4.0.x. Cookie synthesis isn't there yet, but isn't too hard for OpenLDAP. It'd really help if people using directories other than OpenLDAP that support RFC 4533 could provide their cookie blobs, and an export of their rootDSE with operational attributes. I can then add cookie synthesis for those directories, which'll allow you to do the initial sync without downloading a complete copy of the directory first. -Arran Arran Cudbard-Bell FreeRADIUS Core Developer FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
Fancied taking a break from refactoring in v4.0.x.
https://github.org/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/sites-avai... /ldap_sync
The idea is that you can "listen" on DNs within your LDAP directory.
You then use the updates you receive to create/invalidate cache entries, or send CoA/DM messages to reflect the changes that have occurred in LDAP.
Nifty feature. But please put a fat note into the comments that the syncrepl client will not see an entry getting deactivated if server-side ACLs make deactivated entries invisible to the syncrepl client. (That's the reason why I don't use syncrepl in Æ-DIR clients.) Ciao, Michael.
On Apr 27, 2017, at 4:21 AM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
Fancied taking a break from refactoring in v4.0.x.
https://github.org/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/sites-avai... /ldap_sync
The idea is that you can "listen" on DNs within your LDAP directory.
You then use the updates you receive to create/invalidate cache entries, or send CoA/DM messages to reflect the changes that have occurred in LDAP.
Nifty feature.
But please put a fat note into the comments that the syncrepl client will not see an entry getting deactivated if server-side ACLs make deactivated entries invisible to the syncrepl client. (That's the reason why I don't use syncrepl in Æ-DIR clients.)
If a modification to an entry removes it from the set of entries accessible by the sync user, the sync user will not receive a notification that the entry has changed? If so, then yes, that is a gotcha... but also just configure your ACLs correctly... There's no reason the user your binding with should have that sort of restriction. -Arran
Arran Cudbard-Bell wrote:
On Apr 27, 2017, at 4:21 AM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
Fancied taking a break from refactoring in v4.0.x.
https://github.org/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/sites-avai... /ldap_sync
The idea is that you can "listen" on DNs within your LDAP directory.
You then use the updates you receive to create/invalidate cache entries, or send CoA/DM messages to reflect the changes that have occurred in LDAP.
Nifty feature.
But please put a fat note into the comments that the syncrepl client will not see an entry getting deactivated if server-side ACLs make deactivated entries invisible to the syncrepl client. (That's the reason why I don't use syncrepl in Æ-DIR clients.)
If a modification to an entry removes it from the set of entries accessible by the sync user, the sync user will not receive a notification that the entry has changed?
Yupp. If your use-case is updating the cache then the entry will just expire normally later but will not be removed immediately.
If so, then yes, that is a gotcha... but also just configure your ACLs correctly... There's no reason the user your binding with should have that sort of restriction.
For some reasons I consider my de-activation ACLs to be quite correct. ;-] Ciao, Michael.
On Apr 27, 2017, at 12:15 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On Apr 27, 2017, at 4:21 AM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
Fancied taking a break from refactoring in v4.0.x.
https://github.org/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/sites-avai... /ldap_sync
The idea is that you can "listen" on DNs within your LDAP directory.
You then use the updates you receive to create/invalidate cache entries, or send CoA/DM messages to reflect the changes that have occurred in LDAP.
Nifty feature.
But please put a fat note into the comments that the syncrepl client will not see an entry getting deactivated if server-side ACLs make deactivated entries invisible to the syncrepl client. (That's the reason why I don't use syncrepl in Æ-DIR clients.)
If a modification to an entry removes it from the set of entries accessible by the sync user, the sync user will not receive a notification that the entry has changed?
Yupp.
If your use-case is updating the cache then the entry will just expire normally later but will not be removed immediately.
If so, then yes, that is a gotcha... but also just configure your ACLs correctly... There's no reason the user your binding with should have that sort of restriction.
For some reasons I consider my de-activation ACLs to be quite correct. ;-]
Because you don't want the fact that a user has been disabled to be mirrored to other instances of the same directory? At least in OpenLDAP it's perfectly fine to have a dedicated user with its own set of ACLs which you can bind as if you want to perform replication. I don't understand your point... -Arran
participants (2)
-
Arran Cudbard-Bell -
Michael Ströder