This project is read-only.

objectClass=user allows objects different than Users


Hi guys,
I noticed that the FilterConstants.cs file declares the filter as:
internal const string ObjectClass = "objectClass";
this kind of filter allows computers and other object types if it is not combined with a objectCategory filter.

Then, if you are not combining categories and classes by configuration, a small workaround is filtering by object category
internal const string ObjectClass = "objectCategory";
It is worth mentioning some commonly used ldap queries

By declaring the ObjectClassWithAttribute but not using it yet..., it inspires me a possible way to set attributes like an enum,
Let's say we have an enum like:
    public enum ObjectCategoryEnum
        User ,
        Person ,
        Contact ,
        Computer ,
        Group ,
Then the constructor of the DirectoryTypeAttribute can have a constructor like
public DirectoryTypeAttribute(ObjectCategoryEnum category)
   : base(Enum.GetName(typeof(ObjectCategoryEnum), category).ToLower())
Then it would be possible to declare 'my' users class as
public class LdapUser : EntryObject
{ ...
In case of complex type combinations, give us the possibility to set any string, and acknowledge this is a raw directory type filter by setting an explicit parameter in order to not breaking its current usage:
  [DirectoryType("(&(|(|(&(objectclass=user)(objectcategory=person))(objectcategory=group))(objectclass=contact))"), IsRawDirectoryType=true]
    public class LdapUser : EntryObject
Best regards, Paulo


Karaken12 wrote Nov 8, 2013 at 9:59 AM

Hi, Paulo. Thanks for reporting this one.

I have found the same issue with my own AD setup, and the way I have been getting around it is to use an ObjectCategory property, and match against that. However, this isn't really a bug, because it's doing what it should: mapping the ObjectClass property.

My suggestion is this: modify the DirectoryType attribute so that it will optionally take a class and/or a category. e.g.
public class UserOrComputer { ... }
public class UserOrContact { ... }
[DirectoryType(Category="person", Class="user")]
public class User { ... }
(mappings from technet.)

What do you think? Would that work for you? Personally I prefer this to the enum idea, because there might be installations where people have created their own object categories, and the enum wouldn't do that.


paulovila wrote Nov 8, 2013 at 12:17 PM

Hi Tom, I think that it could work for most cases, even for mine, nevertheless I'd never deny the possibility of defining complex type queries. Maybe by adding CustomObjectTypeFilter as a named parameter in the same constructor that you are proposing. Just be careful of multiple named parameters like CustomObjectTypeFilter + Category + Class, because it would allow inconsistency in the definition itself. (If someone defines CustomObjectTypeFilter there cannot be defined Category nor Class and vice versa)

I discard creating a new attribute class, because the syntax in C# is fair enough rich so that it can handle this situation in an elegant way.

That is why I though of separate what is 'well known' in active directory with an enumerated, than some eventual complex requisites.

I think that with an enumerated it'll be covered 98% of cases. And this 2% rest, is for smart people that deeply understands AD syntax.