Confusing results with AD LDAP query and the modifyTimeStamp attribute

I see other AD-related questions here, so here's mine, and I'll try to succinctly detail the issue:

I am using both DSQUERY and LDP for doing queries against a Windows 2003 domain that is NOT in native 2003 mode yet. (There are still a few 2000 DC's.)

I am searching for an account that was definitely changed since 2001, and the GUI confirms this.

In the query, I have to use the modifyTimeStamp. (To save on unneccessary responses, I must use that attribute, and, yes, I know there are others that I can use, but this is an application limitation.) I am also aware that to read the modifyTimeStamp value, more permissions are required. We've created a special group that has read-only access to modifyTimeStamp and createdTimeStamp.

1) I have a query like
  "(& (objectclass=user) (|(modifyTimestamp>=20010128130028.0Z)) (objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.804:=2))  )"
2)  I am only looking for the attributes "cn,adminCount,modifyTimeStamp".
3) Yes, I know that modifyTimeStamp is special and requires rights to view it.
4) I expect to get a particular user that doesn't show up in the results.
5) I am binding with a "generic" user account which has the additional rights, being the member of a special group, to read the modifyTimeStamp attribute.
6) In the original results in step 1, I am getting results with the modifyTimeStamp, but it seems to be missing accounts.
7) to be more exact and limit the search, I changed the query to:
  "(& (objectclass=user) (objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.804:=2)) (|(cn=Divyah Smith) (cn=Kondal Smith))  ) "
8) Step 7 results in three objects, including the two expected users and the attribute data is correctly displayed. The modifyTimeStamp value is being displayed for each object.
9) I changed the query to:
 " (& (objectclass=user) (modifyTimestamp>=20090126120027.0Z) (objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.804:=2)) (|(cn=Divyah Smith) (cn=Kondal Smith))  ) "
10) The query in step 9 only results in one object!!

So, with these steps, I have shown:
1) The binding account can definitely read the modifyTimeStamp for some user objects.
2) There are user objects that are NOT displayed when modifyTimeStamp is part of the query.

My question is this: is there some ADDITIONAL security needed for other underlying attributes in AD in order to use the modifyTimeStamp in an LDAP query in AD?

Ultimately, I need to be able to allow this particular user account the rights to be able to use the modifyTimeStamp and createdTimeStamp in a query and get the attributes in the results. I can do the "black box" approach by making it a Domain Admin, but that sucks.

-- Rob --

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:

***Searching...
ldap_search_s(ld, "DC=mydom,DC=net", 2, "(& (objectclass=user) (modifyTimestamp>=20090126120027.0Z) (objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.804:=2)) (|(cn=Divyah Smith) (cn=Kondal Smith))  ) ", attrList,  0, &msg)
Result <0>: (null)
Matched DNs: 
Getting 1 entries:
>> Dn: CN=Kondal Smith,OU=AsiaPac,OU=Users,OU=Corp,DC=mydom,DC=net
	1> adminCount: 1; 
	1> modifyTimeStamp: 01/28/2009 13:34:10 Pacific Standard Time Pacific Daylight Time; 
-----------
***Searching...
ldap_search_s(ld, "DC=mydom,DC=net", 2, "(& (objectclass=user) (objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.804:=2)) (|(cn=Divyah Smith) (cn=Kondal Smith))  ) ", attrList,  0, &msg)
Result <0>: (null)
Matched DNs: 
Getting 3 entries:
>> Dn: CN=Divyah Smith,OU=AsiaPac,OU=Users,OU=Eng,DC=mydom,DC=net
	1> modifyTimeStamp: 01/26/2009 19:52:05 Pacific Standard Time Pacific Daylight Time; 
>> Dn: CN=Kondal Smith,OU=AsiaPac,OU=Users,OU=Corp,DC=mydom,DC=net
	1> adminCount: 1; 
	1> modifyTimeStamp: 01/28/2009 13:34:10 Pacific Standard Time Pacific Daylight Time; 
>> Dn: CN=Kondal Smith,OU=AsiaPac,OU=Users,OU=Eng,DC=mydom,DC=net
	1> modifyTimeStamp: 01/28/2009 14:22:10 Pacific Standard Time Pacific Daylight Time; 
-----------