In the course of my AdMod Beta tests I found a couple of bugs in AdFind and am correcting those as well. I also may have found a bug in the Microsoft LDAP API that I have pinged one of my good MSFT friends on. Whether it is a bug or not I need to put something into AdFind to correct for it.
AdFind has a switch called -maxe, this is Max Entries which should be output. All it does is simply sets the SizeLimit property of the LDAP query which I submit through ldap_search_init_page. The desired impact is that the server limits the result size to the SizeLimit specified.
In my testing I wanted to undelete about 50,000 of the several million deleted objects. I can either do this with the -upto switch in AdMod or more intelligently I restrict the number of DNs passed into AdMod by specifying -maxe for AdFind… Well interestingly I am watching what I call the “dot counter” on Admod which prints a dot/period (.) for every 1000 records (by default, of course I gave you a switch to modify that called -dotcount) it reads in and I watched it go past what I expect was about 50 dots and then go past what I I knew for absolute sure was at least one hundred dots.
So I ran AdFind and used the -maxe switch coupled with the -c switch, that of course simply prints out a count of the number of records. That count should be, IMO, the same as what I specified for -maxe… I’ll be darned if it didn’t count all couple of million objects.
In testing I quickly ascertained that the issue occurred anytime -maxe was set higher than the current page size. So by default 1000 or whatever value under 1000 I specified via -ps.
Here is what RFC 1823 says about SizeLimit…
ld_sizelimit A limit on the number of entries to return from the search.
A value of zero means no limit;
That seems pretty straightforward.
My “guess” on why this is a problem is that ldap_search_init_page (Microsoft specific call from what I can see) is a standard extended search call with the paging built in to make it easier to do paging with the Windows LDAP API. Prior to MSFT paging didn’t seem so popular and even now the other directories and app dev guys who work on other directories get touchy about having to use paging on AD. So my guess is that when building this function someone didn’t take into account the case of a SizeLimit being specified that exceeds the page size (i.e. what you get back in a single call to the LDAP Server). Now this could have been a conscious design decision or it could be an unexpected side effect of how it was implemented. I personally expect the latter but hopefully will hear back one way or the other. If I get the time, I will try to dig into the source and find it. If it is a bug, I will get it officially bugged so it can be corrected and tracked. If it isn’t a bug then I will push to get some documentation on the API call in MSDN so it is obvious that is what is happening. I have been using the Microsoft LDAP API for six or so years now and this and I have never seen and docs indicating that is what happened.
Oh while I am here talking about the Windows LDAP API implementation, it sure would be nice to have some ldap_x_extended_s calls for doing updates/renames/deletes that return the extended error info so you don’t have to switch over and use the ASYNCH calls instead and then call out to ldap_result, et alii.
joe
So a minor update here. I am in touch with one of the MSFT LDAP Dev guys. The appropriate RFC here isn’t 1823. He didn’t mention which one it is but I now think it may be 2696 and I think it even more emphasizes there is an issue here. I will let you know the response when it is all said and done with if I can.
As for the second part, it was indicated that ldap_get_option with LDAP_OPT_SERVER_ERROR should work, I will test it out, if so that will be great! I was told how to do this previously by someone else at MSFT and I never questioned it, glad I did now. 🙂
Also, let us know how we should handle the larger errata to this post. As described over mail, this is by design. I can post a writeup of our thread or you can post one, whatever you’d rather.