Attributes Exported to Azure AD
The following table describes the attributes exported from the IIJ ID Service to Azure AD.
User
| IIJ ID | Azure AD | Comments |
|---|---|---|
| Name | displayName | The value of "ID" is used for "displayName" when a name is not configured. |
| ID | userPrincipalName | |
| ID (local part only) | mailNickname | The local part of the "ID" value is used for "mailNickname." (Example: iij-taro for an ID of iij-taro@example.jp) |
| Last name | surname | |
| First name | givenName | |
| Enabled/Disabled | accountEnabled | |
| Language | usageLocation | |
| Position | jobTitle | |
| Department | department | |
| Phone number (Type: work) | telephoneNumber | |
| Phone number (Type: mobile) | mobile | |
| Phone number (Type: fax) | facsimileTelephoneNumber | |
| Application linking, external ID or UUID | immutableId | Attributes to be exported are determined according to the following priority. 1. "Application-linking ID" |
| Language | preferredLanguage |
[ Reference ]
When exporting a user to Azure AD, the user is associated with the existing Azure AD users using the following Azure AD attribute.
- When federated with Azure AD (federated): immutableId
- When not federated with Azure AD (managed): immutableId (userPrincipalName if immutableId does not exist)
As a user has been exported to Azure AD, the objectID of the Azure AD user is saved in IIJ ID(*1), and subsequent association is performed using the Azure AD user’s objectID attribute.
*1 objectID values that have been saved in an IIJ ID cannot be changed.If you want to perform association using immutableId or userPrincipalName again, you will need to deprovision the user once.
[ Note ]
Depending on the specifications on the Azure AD side, federation must be disabled when the immutableId attribute is updated.
If federation with Azure AD is maintained, export processing will end up in error.
Group
| IIJ ID | Azure AD |
|---|---|
| Group name | displayName |
| Group description | description |