CloudAccess nor provisoning users correctly in Office 365 after Office 365 connector re-install

  • 7022322
  • 14-Nov-2017
  • 14-Nov-2017


Cloud Access 3.0
Office 365 connector


CloudAccess setup and working well in a test environment. The Office 365 connector was installed and users were provisioned and SSOd to Office 365 back end.

All users are synchronised with AD every 2 hours with AD Sync, where users should be created to function properly in O365. should be the default and should be an alias.

 After removing and re-installing the connector, the behaviour changed. What started to happen is as follows:

1. Admin created a user in AD called "NCATEST1" and added it to a provisioning group, "CORP-O365 K1" Which is the F1 license type.

2. Admin waited to see it provisioned in Office 365, and then ran an AD Sync.

3. The immutable Id in the Cloud copy of the NCATEST1 account does not match the Immutable ID of the AD copy of the account, so AD sync generates and Error and as a result, auto generates another account to sync with the local account.

The end result is that we end up with a junk account which is linked to the local account, and an orphaned "In Cloud" account, which is created by NCA which is linked to nothing.


Go to the NCA system, under the O365 connector -> configure -> Advanced Options -> ImmutableID encoding) and set value to 'native' for your environment. With the churn of the re-install of the O365 connector, this setting defaulted back to 'base64' encoding, causing the above issue.


When a user is imported into NCA, we store the guid of the user (either AD or eDir) in an attribute named 'adroitBISObjectID'.

We use this attribute thru the system quite a bit actually, to make sure accounts don't get hijacked, etc.

This value is stored, for lack of a better word, in 'native' format.

This is also the value that is sent to O365 as the immutableID when the user is provisioned, then used later for the identifier in the saml assertion attribute.


By default, the O365 connector base64 encodes this value, both for provisioning the user and for the saml attribute.

The end result, if you like, is that the immutableID is double-encoded, but doesn't really matter, as long as the immutableID of the O365 account (in O365) and the saml assertion match.

Everything works fine this way.

Now, let's bring Azure AD sync into the mix. .

Azure AD sync tool does something similar to NCA, in synching accounts from your AD system out to O365.

The tool, though, only uses the 'native' value for the user guid, so what happens is we get a mismatch between what adroitBISObjectID -> O365 connector base64 -> immutableID and what Azure AD sync thinks the account identifier should be.

This is the reason why the O365 connector now has the option for immutable ID as a connector setting (base64 or native).

When the connector is set to 'native' mode, the connector itself, and the osp, will not 'double encode' the adroitBISObjectID as the immutableID for the O365 account, it will just use the stored value.

As long as the values match, in native mode too, the assertion works.


Here's what's happening in the above case. I believe, with the re-install of the O365 connector, that the connector defaulted back to 'base64' encoding.

When the accounts get provisioned (or re-provisioned), the connector matches on the UPN, checks for which encoding to use, then updates the immutableID.

Then AD sync comes along to finish up the attribute sync, and probably is only matching on guid, so it might not recognize the existing account, and create the 'zombie' account that they are seeing.


Changing the immutableID encoding in the NCA connector settings WILL NOT automatically do any reprovisioning, Neil.

It only changes the behavior of the account management (provisioning or updating via the connector) for the immutableID attribute, and how the OSP reads and sends the immutableID value in the saml assertion.


If the local IDVault adroitBISObjectID value, and the O365 immutableID don't match. (i.e. the encoding is mis-matched), then when the user tries to SSO via the browser from NCA to O365, they will get an error that looks like this:

Sorry, but we’re having trouble signing you in.

We received a bad request.
Additional technical information:
Correlation ID: 43aa5746-b28c-4cd7-8e12-8a0aef303a4a
Timestamp: 2017-11-14 13:59:59Z
AADSTS51004: To sign into this application the account RGxHV25LRDAxMG0rcitaSzN3MzhUdz09 must be added to the 862d5818-daaa-4ab9-80b5-c6b8473aa718 directory.

The problem here is that the immutableID value in O365 is the 'native' value, and the connector/OSP is set to base64, so the assertion values don't match.

To resolve this for the connector, you'd have to change the immutableID encoding (under advanced options) to 'native'.

The only way to 'fix' this problem (for this particular user) is to remove the user from the mapped account group, wait for NCA to sync out the change, the re-assign them to the (AD) group so that NCA will reprovision them.

The flow is that the O365 connector will match the account based on the UPN during the re-provision, then update the immutableID to the 'native' value.

Because the connector is now set to native as well, the assertion would also match.


To "fix" this for every user, to make sure that immutableIDs would match for everyone, the admin would have to make sure the connector is set to 'native', would have to remove the account mapping from the group(s) in policyMapping (deprovision/disable everyone in O365), then add the mapping back, which would re-provision/enable all the users, and update all of their immutableID values to the 'native' value.

Going forward, CloudAccess dev team will change the default encoding on the connector to 'native' now that azure ad sync is being used out there more and more.