On 02/22/2016 06:29 PM, Howard Chu wrote:
Your logic is flawed: "Just because you may not get an error message when something bad has happened, we want to *never* get an error message when something bad has happened."
Yes and no. I do not care about the error. I just want my operation to proceed. It is actually very simple to do, isn't it? If the server really feels like it must indicate that it I'm doing a strange thing then I'm OK with that. I just want the operation to go on. I know what I'm doing.
Automated or not, large scale distributed or not, if two administrators are making overlapping changes to a single user's privileges at the same time, you have a broken system.
No. I do not have broken system. There are many use cases when that is valid. E.g. single admin adding user to a group manually during and emergency situation. And later make that change legit by following the proper processes, which tries to add the used to the group again. And it does not need to be a person doing that at all. When operation times out, you do not know if the request was processed or not. Most systems will re-try the operation. But if that operation was processed by the server then it will conflict with itself and end up with an error. Is that a broken system? That may happen even if there is no timeout. LDAP does not have distributed transactions, therefore the application may simply die between receiving an LDAP response and passing that information to upper layers. So the operation is likely to retry after restart. Or the information source and the LDAP may become inconsistent because someone simply screwed up. There are many ways how two databases on the network may become inconsistent. Too many. You say that if I consider inconsistency as a real possibility then my system is broken?
Yes, I can always read the entry first, compute changes and then modify it. But why do I need to do that? It takes two round trips and, client overhead and it does not guarantee a sucess anyway. Server can do that easily and reliably. Now, if my directory server is somewhere in the cloud tens of milliseconds away and I have millions of users to provision then each extra round-trip is a waste.
Yes, I do not need to read and entry. I just need to handle the resulting error. Then read the entry, modify the operation and retry. Maybe get the same error. Read entry again. And so on. Anyway, this is at least three round-trips instead of one. And it is strictly sequential. So, more waste. Yes, I do not need to do that for every entry. Only if I get a conflict. So if my data are fairly consistent this may a way to go. But that complicates the client. Good error handling is not easy to design and it is difficult to test properly. This is the hard way.
And now there is this simple and elegant control. It disables a "feature" that does not bring any benefit for me and it makes my life difficult. And the mere existence of that control means that obviously I'm not the only one having problem with this (in my opinion quite bad) part of LDAP spec. So why not use it?
If you don't have distinctly delegated administration zones, and you allow multiple admins to independently operate on the same population of users, you can *never* know if your security definitions are correct. Error messages of this nature are a clear indication that your delegations are broken.
Yes and no. Yes, you do not know the state of all systems exactly at every moment. But if you want to satisfy this requirement then LDAP is not the right tool for you anyway. To do that you will need strict ACID-like consistency, you will have to sacrifice availability, you will most likely need distributed transactions, you will need to coordinate backup and restore operations with a complex restore and harmonization ceremonies - all the things that LDAP servers are not really great at. We really cannot have that in practice. I'm quite sure you realize that. So now we are only discussing how well we can approximate the state of the systems. You are proposing one solution, I have another solution. But both solutions are approximating. You say that my solution is wrong. I know that it is not. My solution only accepts what's out there. In reality it is very common that there are many admins working independently over the same population. There are many operations (sometimes conflicting) coming from many independent sources. It is one of fundamental assumption of my design. I do not need an error to tell me that. I already know that. And that reality is not something that can be changed easily (if it can be changed at all). And even if we can somehow magically change that, the security and organizational policies are often a moving target anyway. They are changing faster than the data can adapt to them. In reality it is not always possible to make strictly consistent deterministic IDM system. We have learned that lesson very early. It looks like a much more practical solution is to make system that continuously approximates the data and makes sure that it eventually converges. That's what we have chosen to do with midPoint. It works well. Very well. It is not broken.
So, let's get back to the original question: does OpenLDAP support the control? Do I need to configure something to enable it? That's all I need.
Thanks.