Whitelisting, Active Directory and SIEM

On this page:

Setup and Compatibility

Maintenance

Browsers

Dekko encourages the use of up-to-date browsers to get the most out of our platform and promote good general security risk management practices.

To see the current and previous Chrome versions click here.

To see current and and previous Edge versions click here.

To check your current browser version enter the following in to your address bar:

Chrome: chrome://settings/help

Edge: edge://settings/help

Whitelisting

As a web application Dekko requires whitelisting in corporate network/device environments where strict firewall and filtering systems may be in operation. The following is inclusive for DekkoLynx encrypted conferencing.

To allow Dekko to function reliably the follow needs to be added to whitelisting policies:

Network/firewall/VPN/AV/Proxies/DNS

• Whitelist all subdomains of Dekko (*.dekko.io)

• Open TCP 443 (HTTPS) and allow UDP 10000-20000 (SRTP) for *.dekko.io for DekkoLynx traffic

Browser Policies

Cookies:

• Allow au.dekko.io

• Allow [*.]au-api.dekko.io

Pop-ups (for AAD SSO windows):

• Allow au.dekko.io

Optionally, it is recommended that cookie and data clearing settings are enabled:

Open

Devices/Notifications

• Allow microphone and camera device permissions for au.dekko.io (for DekkoLynx), either via browser policy or manually by prompt:
  
  

  Open

  

   

• Allow notifications for au.dekko.io (for DekkoVault)

Azure Active Directory integration

Dekko natively supports Azure Active Directory integration. Custom integrations with alternative SSO services such as Okta are supported on a per-engagement basis. Please contact us for more information.

AAD - Getting started

To begin the integration process, we first need your organisation’s Azure AD tenant ID.

To get the tenant ID:

1. Navigate to the Azure Portal (you will need the AAD admin credentials)

2. Navigate to ActiveDirectory

3. Navigate to Properties

4. Copy the “Directory ID” (this is the tenant ID)

5. 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. The link will have the following format:

https://login.microsoftonline.com/<Tenant_ID>/adminConsent?client_id=<Dekko_App_ID>&redirect_uri=<redirect_URL>

After entering the credentials, you will be presented with a page that will ask you to accept the app permissions.

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.

AAD - Assigning Dekko access to users

There are multiple options for granting personnel access to register and log in to Dekko, described in the Microsoft documentation page here. 

Access to a resource (Dekko) can be assigned on an individual basis, to all users in an AD, or users in a group. Dekko recommends the group option, as this provides the most precise control. Steps for creating a group are here. 

If your organisation has already established user groups and wants to grant Dekko access to a subset of those users, groups can be created within groups by following these steps. Finally, to grant Dekko application access to the group, follow these steps.

Optionally Conditional Access controls can be set up to limit where/when/how a user can access Dekko, for example, within the organisation’s network, only during business hours, or with a strict authentication type.

AAD - Account migration

If your organisation started using Dekko with ‘Personal’ logins for users, accounts are automatically migrated the next time they log in after integration.

For example if a ‘Personal’ Dekko log in, ‘john@company.com’ exists and an AAD integration is established, the next time this user authenticates using the AAD account ‘john@company.com’, all data such as groups, files, messages, contacts and meetings will remain. The only difference will be the way the user is authenticated in to Dekko. The ‘Personal’ Dekko log in for this user will also no longer work.

Users external to an AAD-integrated organisation do not need to be in a common AAD to internals - any mix of users from different organisations with different authentication methods can interact freely on Dekko.

AAD - Permissions Explained

ReadWrite.All

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.

ReadBasic.All

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.).

AAD - 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.

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.

SIEM integration

Dekko can communication with SIEM tools such as Splunk, which is the current supported application. Dekko uses Syslog for SIEM integration and as such can be used with a myriad of tools; please contact Dekko if you use an alternative SIEM tool.

To connect Dekko to your SIEM:

1. Open the tenancy manager and select the ‘Splunk’ tab
   
   

2. Tick the ‘Enable Splunk’ radio button, then enter you Splunk endpoint and token, then press ‘Save’: