LDAP: querying for user in entire domain using sAMAccountName

I am using python-ldap module to work with AD on Windows 2003 R2 server.

When I search for ObjectClass=Person, I see that some services are also returned in the query results. I want to know how I can change my query so that only user entries are returned, Also can you please point me to any documentation that focuses on this.

Here is a snippet from my ipython commandline:

    ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
    l=ldap.initialize(server)
    l.simple_bind_s(user, password) 
    user_filter = '(&(objectClass=person)(sAMAccountName=ouuser1))'
    base_dn='DC=id-ad, DC=idea, DC=com'
    qres=l.search_ext_s(base_dn, ldap.SCOPE_SUBTREE, user_filter)
    print qres

The result I get is

    [('CN=ouuser1,OU=newou,DC=id-ad,DC=idea,DC=com',
      {'accountExpires': ['9223372036854775807'],
       'badPasswordTime': ['0'],
       'badPwdCount': ['0'],
       'cn': ['ouuser1'],
       'codePage': ['0'],
       'countryCode': ['0'],
       'displayName': ['ouuser1'],
       'distinguishedName': ['CN=ouuser1,OU=newou,DC=id-ad,DC=idea,DC=com'],
       'givenName': ['ouuser1'],
       'instanceType': ['4'],
       'lastLogoff': ['0'],
       'lastLogon': ['0'],
       'logonCount': ['0'],
       'memberOf': ['CN=ougroup1,OU=newou,DC=id-ad,DC=idea,DC=com'],
       'name': ['ouuser1'],
       'objectCategory': ['CN=Pe开发者_运维技巧rson,CN=Schema,CN=Configuration,DC=id-ad,DC=idea,DC=com'],
       'objectClass': ['top', 'person', 'organizationalPerson', 'user'],
       'objectGUID': ['@\x87C\\\xdf\xbe\xe0M\x8c\xb7S-\xf4\x00.\xd0'],
       'objectSid': ['\x01\x05\x00\x00\x00\x00\x00\x05\x15\x00\x00\x00\x8c\xc6\xd8N\xe3`\x16\xe0\x96\xcf4\xabb\x04\x00\x00'],
       'primaryGroupID': ['513'],
       'pwdLastSet': ['0'],
       'sAMAccountName': ['ouuser1'],
       'sAMAccountType': ['805306368'],
       'uSNChanged': ['417845'],
       'uSNCreated': ['417839'],
       'userAccountControl': ['512'],
       'userPrincipalName': ['ouuser1@id-ad.idea.com'],
       'whenChanged': ['20110909055335.0Z'],
       'whenCreated': ['20110909055335.0Z']}),
     (None,
      ['ldaps://ForestDnsZones.id-ad.idea.com/DC=ForestDnsZones,DC=id-ad,DC=idea,DC=com']),
     (None,
      ['ldaps://DomainDnsZones.id-ad.idea.com/DC=DomainDnsZones,DC=id-ad,DC=idea,DC=com']),
     (None, ['ldaps://id-ad.idea.com/CN=Configuration,DC=id-ad,DC=idea,DC=com'])]

The entries that I want to eliminate are.

(None,
  ['ldaps://ForestDnsZones.id-ad.idea.com/DC=ForestDnsZones,DC=id-ad,DC=idea,DC=com']),
 (None,
  ['ldaps://DomainDnsZones.id-ad.idea.com/DC=DomainDnsZones,DC=id-ad,DC=idea,DC=com']),
 (None, ['ldaps://id-ad.idea.com/CN=Configuration,DC=id-ad,DC=idea,DC=com'])]

I recently had this problem crop up when our AD team enabled AD's built-in DNS features (DNS Application Partitions). I had lots of existing code that would iterate over LDAP results like so:

for record in records:
    for key, value in record[1].items():
        # Do stuff with the returned keys/values here

The change caused my code to break because suddenly there were now results just like yours:

(None,
      ['ldaps://ForestDnsZones.ourdomain.com/DC=ForestDnsZones,DC=ourdomain,DC=com']),

The fix is relatively simple:

for record in records:
    if record[0]: # Add this conditional
        for key, value in record[1].items():

If the first item in the tuple returned by AD/LDAP is None then that means it's an LDAP referral. These can be safely ignored since we don't follow referrals (because they're inherently broken; they don't tell you which credentials are necessary to connect to the referred destination).

More info: This situation will only crop up if you're querying against the entire domain (e.g. your base_dn is 'dc=whatever,dc=yourcompany,dc=com' with no 'ou=something'). It happens because AD thinks of its DNS record service as a "peer" to the global domain. So when you query for anything using just the global domain as your base_dn it will append these strange extra records to the end of every successful query (mostly: if all Domain Controllers are configured the same--which they may not be!).