Extension attributes

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.

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.

Get-AzureADApplication | Get-AzureADApplicationExtensionProperty

Get-AzureADApplication

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

extension_7283baeed75243cfa267d2f11e8d7735_testAttribute

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

Attributes that cannot be imported into CoreView

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.

To check if an on-premise attribute can be imported into CoreView, use the following command:

$user = Get-ADUser -Identity $identity -Properties postOfficeBox

$user.postOfficeBox.GetType()

If the result is ADPropertyValueCollection then we cannot import it into CoreView, as it is an Array and not a String.

 

 

 

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:

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

If you have the necessary permissions to modify organization settings, you can set up these attributes by following these steps:

1. Navigate to “Settings” > “My organization” > “Settings” > “Extension attribute mapping”,
2.  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:

extension_{applicationId}_{attributeGivenName}

extension_{applicationId}_{attributeGivenName}

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

Within the CoreView portal, you can utilize the configured attributes in several key areas:

Import functions

• Full import: Conducted every 24 hours.
• On-premises import: Conducted every 6 hours.

Reports 

In user-related reports, you can add columns using the friendly names of the attributes and apply filters as needed.

Virtual Tenant

The attributes you've configured will appear as delegation filters for users. Use their friendly names to search and incorporate them into your Virtual Tenant configurations.

Management actions (accessible only through the wizard)

• User category:
  • Create user
  • Edit user properties
  • Edit user properties in bulk
  • Set portal attributes
• On-premises category:
  • Create on-premises user
  • Create synchronized user
  • Edit user properties
  • Edit synchronized user

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.