CoreView features a predefined set of attributes for user entities that we routinely import and manage. To expand upon this core set, we now offer tenants the ability to define additional user attributes, with a limit of up to 45. Throughout this article, we refer to these as extension attributes and custom attributes.
It's important to note that custom attributes refer to those from your local Active Directory and are distinct from the attributes managed in Exchange
This functionality enables you to configure these attributes in our portal. You'll have the capability to import them—both through full imports and on-premises imports—manage them via various management actions, and leverage them within Virtual Tenant for filtering reports and user entities.
Configuration requirements for cloud-only attributes
These attributes are hosted within Azure Active Directory.
Instructions to manage on-cloud attributes
To view the extension attributes already configured in your tenant, connect to Azure Active Directory and execute the following cmdlet. It will list all the extension attributes that can be mapped on our platform:
Get-AzureADApplication | Get-AzureADApplicationExtensionProperty
To create new extension attributes, first obtain a list of all applications by running:
Get-AzureADApplication
Use the ObjectId value from the list to create a new extension attribute. For example:
New-AzureADApplicationExtensionProperty -ObjectId "from the above call object id" -Name "Name" -DataType "String" -TargetObjects "User"
Cloud attributes follow a naming pattern: extension_{applicationId}_{chosenName}
. For example:
extension_7283baeed75243cfa267d2f11e8d7735_testAttribute
Attributes exclusive to the cloud can be applied to all cloud-based entities.
On-premises custom attributes
The default schema of Active Directory includes the primary attributes most organizations need. However, there may be situations where you need to add new custom attributes and link them to the user class.
While this document does not provide instructions for creating new custom attributes in Active Directory, we suggest consulting the following article for guidance: How to Create a Custom Attribute in Active Directory.
To obtain a comprehensive list of on-premises attributes that can be integrated with our system, use the PowerShell command below:
PowerShell command
#include DataTypes: Bool(1), Int(2), GeneralizedTime (23-24) and DirectoryString(64)
$allowedTypes = 1,2,23,24,64
$schemaNaming = (Get-ADRootDSE).schemaNamingContext
$attr = (Get-ADObject -SearchBase $schemaNaming -Filter * -Properties lDAPDisplayName, omSyntax).Where({ $allowedTypes -contains $_.omSyntax}) | Select-Object lDAPDisplayName, @{
Name = 'DataType'; Expression ={
if( $_.omSyntax -eq 1){
"Bool"
}
elseif( $_.omSyntax -eq 2){
"Int"
}
elseif( $_.omSyntax -eq 23 -or $_.omSyntax -eq 24){
"DateTime"
}
else{
"String"
}
}
} | Sort-Object lDAPDisplayName
$attr | Out-GridView
At present, managing Unicode string types that may contain multiple values poses a challenge. Specifically, this issue arises when a value fetched from Active Directory is stored within an ADPropertyValueCollection
class.
The output of the script will include two properties: “LDAP display name” and “Data type”.
Please note that you cannot configure the attributes listed below, as CoreView automatically imports them:
List of non-configurable attributes
- UserPrincipalName
- GivenName
- sn
- l
- c
- Department
- physicaldeliveryofficename
- PostalCode
- st
- StreetAddress
- Title
- DisplayName
- facsimiletelephonenumber
- mobile
- telephonenumber
- WhenCreated
- DistinguishedName
- lastlogontimestamp
- ObjectGUID
- whenChanged
- Proxyaddresses
- lockouttime
- userAccountControl
- sAMAccountName
- msDS-UserPasswordExpiryTimeComputed
- objectSid
- pwdLastSet
- employeeID
- employeeNumber
- accountExpires
Synchronized attributes
These attributes are synchronized from your local Active Directory (AD) to the cloud.
To synchronize custom user attributes from on-premises to your Azure tenant, refer to the Microsoft guide: Azure AD Connect sync: Directory extensions.
Synchronized attributes may follow one of two naming conventions: they can retain their on-premises name or adopt the cloud naming pattern as previously described. Due to this variation, we recommend using the name as it appears post-synchronization. This approach ensures the system accurately recognizes the custom attribute across both on-premises and cloud environments.
To synchronize these attributes, you must flag the on-premises attributes for synchronization. After Azure AD Connect runs, the attributes will also be present in the cloud and can be listed using the cmdlet provided in the cloud section.
Once synchronized, these attributes can be assigned to all users, whether they are in the cloud or in your local AD environment.
Instructions for setting attributes in CoreView
Please be aware that although there are various data types available for configuration within your local environment, CoreView supports only four data types. Each type has a designated number of slots:
- String - 30 slots
- Integer - 5 slots
- Boolean - 5 slots
- DateTime – 5 slots
![](https://static.helpjuice.com/helpjuice_production/uploads/upload/image/15740/direct/1694512610523-on-premises-import-process-extension-attributes-mapping.png)
If you have the necessary permissions to modify organization settings, you can set up these attributes by following these steps:
- Navigate to “Settings” > “My organization” > “Settings” > “Extension attribute mapping”,
- For each attribute, you will need to configure:
- Account Type (On-Cloud, On-Premises or Synchronized)
- Extension Name (Microsoft name)
- Friendly Name
- Data Type (String, Int, Bool, or DateTime)
Extension name formats
The format of the extension name will vary depending on the selected account type:
For on-cloud account types
The naming pattern for on-cloud attributes must adhere to the following structure:
extension_{applicationId}_{attributeGivenName}
In this pattern:
- The prefix
extension_
is constant. - The
{applicationId}
is the identifier you select when creating the attribute in Microsoft Azure. - The
{attributeGivenName}
is the name you assign to the attribute.
It is crucial that any on-cloud attribute follows this naming convention. If the pattern is not met, the import process and actions within our system will not work properly.
For on-premises account types
When configuring attributes for on-premises account types, use the exact name as it appears in your local Active Directory environment. There are no restrictions on naming here, but accuracy is crucial. The name must match precisely; otherwise, the import process and actions may not function correctly.
It is critical to avoid using any attribute names that are already listed as non-configurable in the on-premises section. Using these names could result in the failure of your on-premises import process.
For synchronized account types
When an on-premises attribute is synchronized with your cloud environment, it becomes accessible in both Azure Active Directory and your local Active Directory. For such attributes, adopting the on-cloud naming format is recommended:
extension_{applicationId}_{attributeGivenName}
Using this pattern ensures that the attribute can be utilized for imports and actions across all account types seamlessly.
Friendly name
The friendly name serves as an internal identifier, allowing you to assign a clear and understandable label to each configured attribute. Remember, the friendly name is what will appear in reports as the column title, in Virtual Tenant settings, and in management actions.
For on-cloud patterns, the friendly name will default to the attributeGivenName
. However, you have the flexibility to assign any name you prefer.
Using configured attributes in CoreView
Import functions
- Full import: Conducted every 24 hours.
- On-premises import: Conducted every 6 hours.
Reports
Virtual Tenant
Management actions (accessible only through the wizard)
Basic rules for actions:
- If the attribute is on-cloud, it will be accessible for all on-cloud users and for synchronized users. However, for synchronized users, it will only be set in Azure Active Directory.
- If the attribute is on-premises, it will be available for both on-premises and synchronized users. For synchronized users, it will only be set in your local Active Directory.
- If the attribute is synchronized, it can be set for all users. Depending on the user type, it will be visible only in Azure Active Directory for cloud users, only in Local Active Directory for on-premises users, or in both directories for synchronized users.