Duplicate Groups in 1Password after re-deploying SCIM Bridge
Hi, we received a warning about the version (1.3.1) of our SCIM bridge expiring over the weekend.
As a result, we recreated a SCIM bridge following the official instructions using the latest version (v1.6.2 - in DigitalOcean) and this is now configured successfully with our Azure Enterprise App. Logging into this new SCIM bridge indicates health is all good.
However, when a provisioning cycle was initiated in the Azure Enterprise App, all the groups in 1Password got duplicated so we are now in a position where we have best part of 500 duplicated groups in 1Password (provisioned by the newer SCIM bridge) which aren't assigned to the vaults that the previously provisioned groups are assigned to.
I've raised a support ticket via email however am awaiting a response, so if anyone has any ideas as to how this can be resolved in the meantime that'd be much appreciated.
(I'm obviously aware that I could go through every group 1 by 1, assign to vaults manually (again) then delete the groups provisioned by the old SCIM bridge, however that process would be incredibly time consuming and I'm concerned as to why a SCIM bridge update would cause this to happen - I would have though it would have matched the group names etc. I'm also concerned that this may happen again should a further update be required)
Thanks in advance,
Chris
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
If it helps, I've just looked at the SCIM bridge logs and noticed loads of warnings as below:
[LOG] [1.6.2] XXXX/XX/XX XX:XX (WARN) FindGroupWithName found group XXXXXXX in XX, but is protected, skipping
Please can someone advise what may have caused the groups to be seen as "protected"?
Thanks
Chris0 -
Thank you for the update @chrisgreenhalgh! I see that my colleague Alice has already replied to your email, so I will let you continue the conversation over there :+1: I am happy to leave this discussion open in case someone from the community would like to jump in too though.
ref: HKX-74121-755
0 -
Thanks @ag_ana .
If it helps any other users, it looks like the issue was caused by the fact that all the previously-provisioned groups lost the old "Provisioning Manager" account when the SCIM bridge was redeployed, but didn't have the new "Automated Provisioning User" account added to them instead.
To resolve this, I needed to do the following (using the 1Password CLI - in conjunction with PowerShell):
1. Ensure that the "Provisioning users & groups" toggle in the Integrations section is set to off.
2. Obtain a list of Group UUIDs that were created at the time the new SCIM bridge ran a provisioning cycle (i.e. the duplicate groups)
3. Delete those groups (using theop delete group [GroupUUID]
command).
4. Add the "Automated Provisioning User" to the previously-provisioned groups and set the role as 'Manager' (usingop add user [UUIDOfAutomatedProvisioningUser] [GroupUUID] --role manager
)
5. Re-enable the "Provisioning users & groups" toggle in the Integrations section.0 -
Thank you for the update @chrisgreenhalgh! I am sure the community will find it useful :)
0