To begin the integration process, we first need your organisation’s Azure AD tenant ID.
To get the tenant ID:
- Navigate to the Azure Portal (you will need the AAD admin credentials)
- Navigate to ActiveDirectory
- Navigate to Properties
- Copy the “Directory ID” (this is the tenant ID)
- Send it to us. You can send it to us in a message on Dekko.
From this, we will create a link for you which just needs to be clicked. Upon visiting this link, you will be prompted for the AAD admin credentials. After entering the credentials, you will be presented with a page that will ask you to accept the app permissions listed in the screenshot below:
If a change request is required for accepting these permissions, you can include the list in the request details.
As part of these permissions, the extra AAD field required for Dekko will be created automatically, so you don’t need to create it.
The only steps for rollback would be removing these permissions, described here.
From this step, we will begin the testing phase.
The ReadWrite.All permission is required to provide the ability to reset a user’s password [more details below] from Dekko (the ‘trusted user’ facility). The permission is specifically required because changing the password will alter one of the fields in AAD, as part of the user’s Dekko password is stored in AAD extension attribute.
An example where this would be if an AAD account is removed or recreated, or the extension attribute is damaged in some way, and access to that person’s Dekko original account needs to retrieved. It is fairly unlikely that this permission will ever be utilised, but will be very valuable in emergency situations.
Note that that the ‘yes’ in the ‘Admin consent required’ column means that if the facility is used, the AAD admin must give permission for that instance. Depending on your logging configuration, you will be able to see that the only activity being performed during a write activity is an altering of the single attribute.
This permission does not grant Dekko the ability to transfer any data to or from AAD or any other system, and the Dekko backend strictly does not have access to AAD for any function other than token validation at log in.
The ReadBasic.All Is a subset permission to ReadWrite.All and only grants Dekko that ability to display information from AAD on the Dekko front end (names, avatars, email addresses, etc.).
How Dekko AAD integration works
The AAD password is not actually the Dekko account password. The first time an AAD user tries to log in to Dekko using AAD, Dekko creates their account and stores part of the new random Dekko user password in an AAD extension attribute, which contains the hash of the email address and a random (security) GUID. This is what the extension will look like:
To subsequently log in to Dekko, the first part of the password is retrieved from the AAD extension attribute upon successful AD authentication, then the user’s security ID is retrieved and combined with the first part. This creates a complete user password. Crucially, if the information in the extension attribute is lost, the account will be lost with it. This is where the trusted user facility becomes useful.