Home / server / Questions / 462965
Accepted
Brett Rigby
Asked: 2013-01-05 05:08:35 +0800 CST

Limitations of Custom Fields in Active Directory

  • 772

I am currently looking into the possibility/feasibility of using Custom Fields in Active Directory for storing information per user within our domain network, but have a few questions regarding the custom fields themselves, namely:

  1. What are the limitations of these fields, if any?
  2. Is there a maximum field length?
  3. Is there a maximum number of custom fields available per user?
  4. Are there any known read/write performance issues (from C#) with using them for this purpose?
active-directory

2 Answers

  1. Best Answer

    edit: Wrote this answer before I knew you were talking about Exchange, so it's more about AD in general.

    Yes there are limits. Your first consideration might be that the attribute you want to use is not indexed. This is as easy as clicking a checkbox to change. Indexing an attribute makes queries involving that attribute faster, at the cost of database and replication size.

    Secondly, your custom attribute may not be replicated to Global Catalogs. This may be an issue if you have many domains and you might need to access this information from another domain. This is also easy to fix, but again, be mindful that you're adding replication load.

    There are a ton of attributes already in the AD schema that are not being used. Perhaps you can repurpose some of them. For instance, the Likewise/Powerbroker and Centrify clients that allow Linux computers to join AD domains... no AD schema extensions are required because those clients use preexisting attributes in AD to store Unix-specific information.

    Yes attributes have a set size limit, and that limit is different for every attribute. Not just size limit, but they can be different types of data as well. A multi-valued string, for instance. Each attribute can also have a specific allowed range, security descriptor, etc. These constraints are fixed as part of the schema. Here is a reference of Active Directory attributes... the info is a little old but the idea is the same. You have linked attributes, ANR (ambiguous name resolution) attributes, etc., that all behave a little differently and have different purposes.

    As a last piece of advice - consider any changes you make to your AD schema permanent and irreversible. So do it only after a lot of forethought and planning.

    • 3

  2. Are there any known read/write performance issues (from C#) with using them for this purpose?

    A multivalued attribute offers better query performance than using a single-valued attribute and separating multiple pieces of information with delimiters. Just like SQL Server, if a query wildcard is prefixed with an *, the performance will be poor. When you query for a non-wildcard value or a wildcard suffixed value, and it matches one of the values in a multivalued attribute, the query succeeds. Some people are unaware of that advantage.

    Attributes may also be indexed, and you should consider doing that.

    If you have multiple domains and need the information available in other domains than the object that has the attribute, you may want to add the attribute to the Global Catalog (sometimes called the Partial Attribute Set or Filtered Attribute Set).

    Schema Management - Attribute Properties

    Indexing in Active Directory

    Creating More Efficient Microsoft Active Directory-Enabled Applications

    • 2