Extension attributes

  • Last update on October 3rd, 2023

In CoreView we have a predefined schema of attributes that we import and manage for user entities. To increase this base schema, we now give each tenant the possibility to define different user attributes (up to 45). In this document we use the terms extension attributes and custom attributes to name them, beware the custom attributes define local AD custom attributes and are not the ones you can manage in Exchange.

This feature will help you set them up on our portal, and it will give you the possibility to import them (full import and on-premises import), manage them through multiple management actions, and finally use them for Virtual Tenant to filter reports and user entities.

What do you need to configure? Cloud-only

On cloud

They live on Azure Active Directory.

Instructions to manage on-Cloud attributes

To see which ones you have already configured in your tenant you can run the following cmdlet, after connecting to Azure Active Directory, it will return all available extension attributes that can be mapped on our side:

Get-AzureADApplication | Get-AzureADApplicationExtensionProperty

To create new ones, you will need to retrieve the list of all available applications with:

Get-AzureADApplication

Then you can use the value on the column ObjectId to create a new extension attribute, for example:

New-AzureADApplicationExtensionProperty -ObjectId "from the above call object id" -Name "Name" -DataType "String" -TargetObjects "User"

All cloud attributes will have a specific pattern, formed by extension_{applicationId}_{chosenName} similar to:

extension_7283baeed75243cfa267d2f11e8d7735_testAttribute

Cloud-only attributes will be available to be assigned to all entities in the cloud.

 
 

On-premises

The Active Directory schema contains the main attributes that an organization generally requires, but, if necessary, it's possible to add new custom attributes and associate them with the user class. 
This document does not offer a guide on creating a new custom attribute in the Active Directory; however, we recommend this article: How to Create a Custom Attribute in Active Directory.

The following PowerShell statement aims to provide a way to retrieve the full list of potential on-premises attributes that can be mapped on our side:

PowerShell statement

#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
 
 

The script's output contains two properties: “LDAP display name” and “Data type”. 
You cannot configure the following attributes because CoreView already imports them:

Not configurable attributes list

  • 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

These are the attributes that have been synchronized from your local AD to the cloud.

If you need to synchronize on-premises custom user attributes into your Azure tenant, Microsoft explains how to synchronize them on Azure using the Azure Ad Connect: Azure AD Connect sync: Directory extensions.

They have two different name patterns, either the same as for the on-premises attributes (so with just the name given) or with the cloud pattern as explained above. Since there is this difference, we suggest always choosing the synchronized name.

This way allows the engine to correctly identify the customer attribute configured in both contexts: on-premises and cloud.

To create them you will have to mark the on-premises only to be synced, once the Azure Ad Connect will run you will have them available in the cloud as well and you will be able to list them with the cmdlet mentioned in the cloud section. 
Synchronized attributes will be available to be assigned to all users in the cloud and also on your local AD environment.

Where and how to set them on the CoreView portal

Show instructions

Keep in mind that for on-premises ones there are a lot of different data types to be configured in your local environment, however in CoreView we only support 4 data types, and each has a fixed number of slots available:

  • String - 30
  • Int - 5
  • Boolean - 5
  • DateTime – 5

If you have permission to edit organization settings to set them up you will have to navigate to “Settings” > “My Organization” > “Settings” > “Extension Attribute Mapping”. For each you will have to configure the following:

  • Account Type (On-Cloud, On-Premises or Synchronized)
  • Extension Name (MS name)
  • Friendly Name
  • Data Type (String, Int, Bool, DateTime)
 
 

Extension name

This will have different formats based on the account type chosen.

On-cloud

The pattern should always look like this:

extension_{applicationId}_{attributeGivenName}

Basically, the first part is always fixed (extension_), then you can find the ApplicationId chosen when creating the attribute on Microsoft and finally, the last part is the name you have created.

For any attribute created on-cloud that does not follow this pattern, our import/actions will not work properly.

 
 

On-premises

You should use the name given on your local AD environment, there are no limitations here, but remember it should be exactly the same, or again import/actions will not work. It is very important not to use any of the ones mentioned above in the on-premises section, otherwise, your on-premises import process will always fail.

 
 

Synchronized

Once an on-premises attribute is synchronized to your cloud environment the attribute will be available both in Azure Active Directory and in your local Active Directory.  
The ideal pattern for this situation is to use the on-cloud format, this will allow us to use it for import/actions for all account types.

 
 


Friendly name

This is an internal name, the purpose of this is to be able to assign an understandable name to each attribute configured. Keep in mind that the friendly name is what you will find in the report (as the column title), in VT settings, or in the management actions. 
On-Cloud patterns will be automatically set with the attributeGivenName, but feel free to give them whatever name you want.

Where and how to use them in CoreView

  • If the attribute is on-cloud it will be available for all on-cloud users and for synchronized ones (in this case, it will be set only on Azure Active Directory).
  • If the attribute is on-premises it will be available for on-premises and synchronized users (for the second one it will be set only on your local AD).
  • If the attribute is synchronized it can be set for all users, based on the user you will see it only on Azure Active Directory for cloud users, only on Local Active Directory for on-premises users, or everywhere for synchronized users.