AD Integration Tip: Dealing With More Than 1,000 Users

Reader Scott Merrill pointed out something to me in an e-mail regarding a Registry change that might be necessary in some Active Directory integration scenarios:

Finally, I would like to share one registry change that we’ve found to be necessary in our AD integration. By default, the MS LDAP server only returns 1,000 results. As a university department with more than 1000 active students, this limitation has caused us some frustration.

This KB article shows how to increase the number of results returned in a query:

We recently set MaxPageSize to 5,000. I don’t know if this will
introduce additional problems down the road, but at least it lets me fully enumerate all our AD users from a Linux machine with `getent passwd`.

If you have an Active Directory domain with more than 1,000 users in the DN specified in your LDAP configuration, then this is a Registry change you’ll want to investigate. Otherwise, you could find that your UNIX/Linux servers aren’t able to fully enumerate all the users in the domain.

Thanks, Scott!

Tags: , , , , ,


  1. Brian Desmond’s avatar

    This is a really bad idea. This is not an AD limitation, it’s an application programming issue. This is the LDAP page size – standard thing across any LDAP directory. 1,000 is the max number of records returned in a result set so the app has to support paging to get more.

    This is not a best practice and yes it can cause problems. The other problem is once you do it once, you set the precedent to keep doing it.

  2. slowe’s avatar


    OK, fair enough. How would you suggest handling this problem, then?

  3. Anders’s avatar

    Atleast libnss_ldap has support for paging although it’s not enabled per default in all installations.
    I would assume that winbind also handles paging.

    Changing the pagesize should be the absolute last thing you consider doing (and yes, that’d be after bashing developers heads).

  4. Jef’s avatar

    I would agree that messing with the maxpagesize is a very bad Idea.

    As Brian said, as soon as you set it to 5,000, what if you grow to 5,001? Or even 10,000?

    It’s a constant chasing the number as you grow, while all the time you are introducing potential issues with the infrastructure because of the load you may place on it.

    Now how easy is it for you to tell an App owner to “Fix their app” and use paging? Unfortunately that is not always an easy task, but I tend not to want to change infrastructure to support an application, especially when supporting paging is a solution.


  5. slowe’s avatar

    OK, I hear everyone saying just how bad it is to increase MaxPageSize, but I don’t hear anyone telling us how to fix the problem that increasing MaxPageSize fixes. It’s all well and good to say “Don’t do that!”, but what people really need is “Do this instead”. Anyone care to provide that information?

  6. Jef’s avatar


    I agree that I should offer some helpful information other than just saying “don’t”, so I wrote up some information here which I hope provides some help:

  7. Jan Ivar Beddari’s avatar

    Ah, this old problem again :-) Luckily there is now a lot of sample code around the net that shows how you can do paged searches against AD correctly.

  8. Doug Woodgate’s avatar

    Below is from the man page of nss_ldap, it should work like this, but I still had problems with it I think. I was running into an issue that some users wouldn’t show up under a global getent passwd, but would with getent passwd username. I figured this was the cause, and may be, but under Red Hat Server 5, it apparently doesn’t work. How I fixed it was appending a search filter in ldap.conf

    Enables support for paged results.

    When paged results are enabled (see above), specifies the number of entries to return in a single page. The default is 1000.

    Search Filter I applied to reduce the count and make it feel a little quicker.
    nss_base_passwd dc=mybpc,dc=net?sub?&(objectCategory=user)(uidNumber=*)


Comments are now closed.