Custom LDAP Fields

AD FastReporter includes a large set of built-in fields covering standard Active Directory attributes, Exchange attributes, calculated values, and more. If your organization uses additional AD attributes — schema extensions, third-party application attributes, or custom attributes — you can add them as custom fields so they appear in reports alongside the built-in ones.

This is a Pro feature.

When to Use Custom Fields

Common scenarios:

• Your organization has extended the AD schema with custom attributes (e.g., employeeID, extensionAttribute1 through extensionAttribute15, or a custom badgeNumber attribute)
• A third-party application stores data in AD attributes that aren’t included in AD FastReporter’s built-in field list
• You want to report on an obscure standard attribute that AD FastReporter doesn’t include by default

Adding a Custom Field

To add a custom field:

1. Open the custom field dialog from the report form editor (the option appears when editing or creating a custom report form)
2. Fill in the following:

Display name — The name that appears in field lists and as the column header in reports. Choose something descriptive, e.g., “Badge Number” or “Extension Attribute 1.”

LDAP attribute — The exact LDAP attribute name as it exists in your Active Directory schema. This must match the attribute name in AD precisely (case-insensitive). Examples: employeeID, extensionAttribute1, physicalDeliveryOfficeName, badgeNumber.

Field type — The data type that tells AD FastReporter how to read and display the attribute value. Available types include:

Type	Use for
String	Most text attributes (names, descriptions, custom text fields)
Integer	Numeric attributes stored as integers
Date	Standard date/time attributes
AD Date	Large integer timestamps used by AD (e.g., accountExpires format)
DN	Distinguished Name references (single-valued, e.g., a reference to another object)
Multi-DN	Multi-valued DN attributes (e.g., a list of object references)
Boolean	True/false attributes

Choosing the correct type matters — if an attribute stores a large integer timestamp (like many AD date fields) but you select String, the value will display as a raw number instead of a readable date.

Report categories — Check which report types the field should be available in: Users, Computers, Groups, Exchange, Contacts, Printers, GPOs, and/or OUs. A field can be available in multiple categories. For example, extensionAttribute1 might be relevant for both User and Computer reports.

1. Click Save to add the field.

Using Custom Fields in Reports

After adding a custom field, it appears in the Available Fields list when you create or edit a report form in the selected categories. You can add it to any report form’s field selection just like a built-in field.

Custom fields also work with the filter system — you can create filter criteria based on custom fields using the operations appropriate for the field’s data type.

Custom fields are included in exports and email deliveries just like built-in fields.

Managing Custom Fields

Custom fields are stored in the local SQLite database. They persist across application restarts and upgrades. If you need to modify a custom field (change its display name, LDAP attribute, type, or categories), you can edit it from the same interface where you added it.

Tips

• If you’re unsure of the exact LDAP attribute name, you can look it up using the Active Directory Schema snap-in (schmmgmt.msc), ADSI Edit, or PowerShell: Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -Filter "name -eq 'attributeName'".
• Start with the String type if you’re unsure — it will display the raw value, which helps you determine if a different type (Date, Integer, etc.) would be more appropriate.
• Extension attributes (extensionAttribute1 through extensionAttribute15) are commonly used by Exchange and third-party applications. These are standard schema attributes in any Exchange-extended forest.