It turns out my memory of range retrieval is a bit off w.r.t. <http://msdn.microsoft.com/en-us/library/cc223242(v=prot.10).aspx>:
If a SearchRequest does not contain a range option for a given attribute, but that attribute has too many values to be returned at one time, the server returns a SearchResultEntry containing (1) the attribute requested without the range option and with no values, and (2) the attribute requested with a range option attached and with the values corresponding to that range option. The ordering of the values returned in a range retrieval request is arbitrary but consistent across multiple range retrieval requests on the same LDAP connection, provided that the attribute is not modified between successive range retrieval requests. I suspect a lot of the OpenLDAP->AD hate around this feature is based on the hand-wavey non-atomic / inconsistent read results... at least the results paging control uses a cookie. AD has some pretty odd restrictions around multivalues in general--but a lot of its other features are much more advanced than any other DSA. --Steve On Thu, Mar 22, 2012 at 11:29 AM, Michael B. Smith <[email protected]> wrote: > Interesting. I hadn't run into that fact before. > > It's documented in an expired RFC: > > http://www.ietf.org/proceedings/53/I-D/draft-kashi-incremental-00.txt > > but it never got approved. > > A quick search indicates that lots of LDAP servers and clients support it - > because Microsoft does and only for that reason. It appears that AD may be > the only one to require it. OpenLDAP is one that specifically does NOT > support it, because the project maintainer apparently dislikes MSFT's LDAP > implementation (he repeatedly refers to AD as "crap" in the articles I read). > Lots of end-user discontent is also expressed because those that are using > OpenLDAP as an AD proxy have to continually reimplement support for the > feature. > > -----Original Message----- > From: Steve Kradel [mailto:[email protected]] > Sent: Thursday, March 22, 2012 10:59 AM > To: NT System Admin Issues > Subject: Re: "ldapsearch" for Windows > > Active Directory is the only directory server I know of that supports or > demands the use of ranged attributes. They're mostly sensible to use when: > * you are fetching only one or a few objects > * you know in advance which attributes might have a great profusion of > multivalues > > For example, if you query for the "member" attribute on a very large group, > AD will only give you the first 1,500 values as per the MaxValRange LDAP > policy, *without any indication that there are more values*. Instead, one > must explicitly ask for the attribute description "member;range=0-5000" or > the like, and then examine every attribute name in the LDAP response message > to see if it indicates something like "member;range=0-1499", to see what > range of values the directory server was actually willing to provide--then > issue additional search requests to fetch the rest of the values until you > can infer from the response message that all the values have been exhausted > (you'll see "member;range=3000-*" at that point). > > All these searches are non-transactional, and it is probably safe to say the > end result is "undefined" if the group should change between requests for > chunks of the membership list. > > Personally I like and use the OpenLDAP tools often, as part of Cygwin; > "ZLdapSearch" is mostly helpful if you've some other requirement to stick to > .NET (such as the added safety of managed code), or want to use Windows > authentication methods. > > --Steve > > > On Thu, Mar 22, 2012 at 8:59 AM, Michael B. Smith <[email protected]> > wrote: >> LDAP directories have limits on the size of results that they will return. >> Consider a group with a million members. It could consume all of your >> available memory to return the result from the LDAP database. That isn't >> desirable. >> >> So, instead, there is a limit on the number of results returned in single >> API call. Typically around 1K. So, when using the API itself, you first >> request values 0-999, then 1000-1999, etc. Part of the result tells you >> whether or not there are more values to be requested. This API limit is >> hidden from you by many command line tools like dsquery, adfind, etc. >> (although all of them do have limits on the number of results that they will >> return, without setting some specific argument). >> >> Not to minimize Steve's contribution (it's great!), but there is a fairly >> recent port of OpenLDAP for Windows available at >> http://www.userbooster.de/en/download/openldap-for-windows.aspx that >> includes ldapsearch. >> >> -----Original Message----- >> From: Guyer, Donald [mailto:[email protected]] >> Sent: Thursday, March 22, 2012 8:48 AM >> To: NT System Admin Issues >> Subject: RE: "ldapsearch" for Windows >> >> This looks cool but, what does this mean? >> >> " Note: this program does not currently attempt to fetch range-based >> attributes, such as AD groups with over 1,000 members." >> >> Regards, >> >> Don Guyer >> Directory and Messaging Services >> Catholic Health East, ITSS >> >> >> -----Original Message----- >> From: Steve Kradel [mailto:[email protected]] >> Sent: Wednesday, March 21, 2012 6:15 PM >> To: NT System Admin Issues >> Subject: "ldapsearch" for Windows >> >> Cross-posting this from the ActiveDir list: this tool may be of interest to >> folks with non-AD directories, maybe you just don't like ldifde, or want to >> pipe LDIF from stdout to another program. >> >> I went ahead and knocked out a quick and dirty .NET LdapSearch. >> Source code is on GitHub: https://github.com/skradel/Zetetic.Ldap >> >> Here's a binary build: >> http://dl.dropbox.com/u/1742256/Zetetic.Ldap/ZLdapSearch_1.0.zip >> >> It is certainly no competitor for AdFind, but it is: >> * open source >> * plain old .NET 2 >> * LDAP v3 directory agnostic >> * a producer of carefully-managed LDIF output to handle binary values, long >> strings, and non-7-bit-ASCII characters properly. >> >> I might wrangle around the commandline options if there's interest to make >> it more of a drop-in replacement for ldapsearch, but it is pretty close as >> it stands. >> >> Note: this program does not currently attempt to fetch range-based >> attributes, such as AD groups with over 1,000 members. >> >> It *does* support (but does not require) paging on directory servers that >> support it. >> >> Insert standard "free software, no warranty, provided in hopes you will find >> it useful" disclaimer here. >> >> --Steve >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to [email protected] >> with the body: unsubscribe ntsysadmin >> Confidentiality Notice: >> This e-mail, including any attachments is the property of Catholic Health >> East and is intended for the sole use of the intended recipient(s). >> It may contain information that is privileged and confidential. Any >> unauthorized review, use, disclosure, or distribution is prohibited. If you >> are not the intended recipient, please delete this message, and reply to the >> sender regarding the error in a separate email. >> >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
