This article goes over commonly asked questions and commonly reported issues regarding Addigy Identity.
There are many moving parts of Addigy Identity, and thus many questions. If you do not see your question/issue here, please reach out to us by emailing support@addigy.com or submitting a ticket here.
The Addigy Identity login process is looping - why?
When there is a login loop occuring, this is likely because an improper value was entered in the Addigy Identity configuration settings.
If you are experiencing this and you use Azure as your IdP, kindly reference this article for more information.
If you are using Google or Okta, ensure that the proper values were copied over from the IdP and placed in the relevant field in the Addigy Identity settings.
Why am I receiving a white screen after authenticating?
A white screen after authenticating is likely due to passwordless authentication. As of now, Addigy Identity does not support passwordless authentication.
If passwordless authentication is not being used, kindly submit a ticket and we will be happy to investigate further.
Error: "Operation was denied because the current credentials do not have the appropriate privileges"
This error typically occurs when there is an IdP-managed passcode policy in place that conflicts with a device-level passcode policy.
If a user is seeing this error, we recommend verifying if there are two passcode policies in place, and if so, check whether the two passcode configurations conflict with each other. The following command can be used to list the current passcode policy on a device:
pwpolicy -getaccountpolicies | grep -A1 '>en<' | awk -F '>|</' '{print $2}' | grep -v 'en'
Error getting user information from [IdP]
The following information is applicable if your Addigy Identity settings require a client secret.
If the client secret for your IdP's web application expires, is input improperly, or is deleted from the IdP while still in use in the Addigy policy, an error message similar to the following may appear during sign-in attempts:
Resolving the issue with the client secret will prevent this error and allow for successful sign-in attempts. This may include:
- Creating a new client secret and updating the Addigy policy's Identity settings (if the client secret has been expired or deleted)
- Providing the correct value for the client secret (See our article on configuring Identity with Azure)
Unrecoverable error. SecurityAgent was unable to create requested mechanism AddigyIDSync:VerifyUser.
This error may occurs if a security software is blocking AddigyIDSync. Configuring your security software to allow AddigyIDSync and perform another Identity Sync.
Why am I being prompted to update my password?
A user's Identity Provider (IdP) password must match the password of the local account it's synced to for sign-in to occur. These passwords can become out of sync after changing or resetting either the IdP (Azure/Google/Okta) password or the local account password.
How do I sync my Azure/Google/Okta password to a local account?
Syncing for the first time
Select an existing user account on the device and provide its password.
Syncing after a password change/reset
The following prompt appears when the IdP password does not match the local account password on the device. Provide the local account password to re-sync the passwords.
Note: If the local password is changed the next sign in will sync the password back to the IdP password.
I can't remember my local account password. What are my options?
If you are prompted to update your password and do not know the current password of your local user account, it will need to be reset. This can be done via a couple of methods:
- In GoLive, select the Users tab and select the Reset Password button under the Actions column.
- In Recovery Mode, by following the steps in our article Fixing broken Keychains ( Secure Tokens) using Recovery Mode.
Note: if FileVault is enabled, the Recovery key will be needed to access Recovery Mode.
How does password syncing work when FileVault is enabled?
If FileVault (FV) is enabled prior to Identity being deployed, users will log into the FV window with their local account password. Then the Identity window will appear. After syncing their IdP password to their local account and signing in, their FV password will now be their IdP password.
If FileVault is enabled after Identity is deployed, users will log into the FV window with their IdP password, as it would already be synced and is the same as their local password.
My user selected the wrong local account to sync with. What do I do?
If the wrong local account was selected to sync with the identity user, you can reset this process by deleting the alias within Users & Groups. This can be done as follows:
- Navigate to System Settings > Users & Groups
- Right click the affected user and hit Advanced Options
- Scroll down to aliases and delete the entry that follows this format:
addigy.synchronized.user:*insert user email here*
Additionally, we have a separate article which contains a script to unsync a identity user from a local macOS account here.