This project is read-only.

Attribute Scope Queries return null values in 11038

Jan 30, 2012 at 12:15 PM

I've had a play with the new syntax for Attribute Scope Queries coming in 2.1 (using build 11038).

First, one thing to note is that I have to specify the Where method with "user" otherwise I get no results:


.Where(u => Filter.Equal(u, "objectclass", "user"))


This is the same behaviour as with the old syntax, though.  Perhaps it's an AD thing?

Second, the bigger concern is that the new syntax returns null entries when the attribute is not set on the original objects.

This is the query I'm using:

    var response2 = context.Query<UserObject>(System.DirectoryServices.Protocols.SearchScope.Base,
        .WithControls(new[] { new System.DirectoryServices.Protocols.AsqRequestControl("member") })
        .Where(u => Filter.Equal(u, "objectclass", "user"))
        .Select(u => u.mail);

    foreach (var email in response2)

And what I set looks like thi:
If I ToList() the results, I see:

[0]     ""
[1]     ""
[2]     null
[3]     ""
[4]     null
[5]     null
[6]     ""
This is valid from the pov that those entries don't have the mail attibute set.  But if I run an ASQ using System.DirectoryServices.Protocols, it doesn't return anything for entries that don't have the attribute set - I'd just get the four email addresses.


Jan 31, 2012 at 4:22 AM

I'm using AD LDS and I don't require a filter to retrieve the values.  I'm not sure why your query requires it.  As for the null entries I believe that behavior is correct.  You would have 7 entries, but only 4 of them would have a mail attribute.  I got the same behavior with S.DS.P.  If you want nulls to be removed you would have to apply a constraint.  You can either apply it at the server or on the client:

//server side produces: (&(objectclass=user)(mail=*))
.Where(u => Filter.Equal(u, "objectclass", "user") && u.mail != null)
//client side:
.ToList().Where(mail => !string.IsNullOrEmpty(mail))


Jan 31, 2012 at 6:31 PM

Well, I feel like a fool.  I can't find my original test S.DS.P query and when I created a new one it behaved exactly as you said.


My point about the filter was badly phrased.  Now that I reread it, when I wrote 'one thing to note is that I have to specify the Where method with "user" otherwise I get no results' it appears that the stress is on the word have whereas it belongs on the word user.  I was copying your example from here and when I put "*" I got nothing but when I put "user" I got some results.  I followed your lead (in your reply) and .LogTo'd the output and I get:

.Where(u => Filter.Equal(u, "objectClass", "*"))
// gives    Filter: (objectClass=\2a)
// whereas

.Where(u => Filter.Equal(u, "objectClass", "user"))
// gives    Filter: (objectClass=user)
The problem being with the translation of * as a special character.