Addigy Identity Troubleshooting – Addigy

This article will go over common Addigy Identity issues and provide troubleshooting steps on how to resolve said issue. 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?

A login loop is likely caused by an improper value that was entered in the Addigy Identity configuration settings. For your specific Identity provider please see below:

Azure: When a login loop occurs after a sign-in attempt, it is usually due to an issue with the client secret provided in a policy's Identity settings. Confirm that the data provided in the policy's client secret field is the Value from Entra, and not the Secret ID. Since the value is only shown once when the client secret is first created, it may be necessary to create a new client secret to get this key. If the Azure application is mobile and desktop, a client secret should not be added to the Addigy policy's Identity settings.
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 caused by the user's email account having passwordless authentication configured. Currently Addigy Identity does not support passwordless authentication as it needs the user to type in their password to successfully sign into the device. If you would like the end user to use Addigy Identity convert their email to require the password to complete signing in.

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]

This issue can occur if your Addigy Identity configuration requires a client secret. If the client secret for your IdP's web application is input improperly, expires, or is deleted from the IdP while still in use in the Addigy policy, the error message in the screenshot above may appear during sign-in attempts. Below are some troubleshooting steps to resolve this issue:

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 and Google)

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.

Addigy Identity is asking for my previous local password but I do not remember it. 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:

If another Admin user exist on the device you can sign into that account and perform a password reset for the user that forgot their local password.
- This method will require the "Allow users to sign in using their macOS username and password" and / or "Allow users to leave Addigy Identity and continue to macOS login window" Addigy Identity settings to be enabled so someone can sign into the Admin user outside of Addigy Identity.
Follow Apple's article on what to do if you forgot your Mac login password.
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.

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, the script below can also be used to unsync a users email from a macOS local user. This script requires you to provide the username of the local macOS account that needs to be un-synced and enter it in line 7 where "YOUR_USERNAME" is. You can find the local macOS account name within a device's GoLive page under users.

synchronization_flag="addigy.synchronized.user"

# Set the specific user manually or via an argument

specific_user="YOUR_USERNAME" # Replace 'your_username' with the actual username

# Verify if the specific user exists

if dscl . list /Users | grep -q "^${specific_user}$"; then

record_names=$(dscl . read /Users/${specific_user} RecordName)

# Loop through the user's record names

for record in $record_names; do

if [[ $record == *$synchronization_flag* ]]; then

echo "$record"

dscl . delete /Users/${specific_user} RecordName ${record}

done

else

echo "User ${specific_user} not found."

exit 1

A successful un-sync will output the record name which is reported back from the OS user account name.

Error: 400 (Okta)

This error may appear when either the redirect URI does not match or when the request expected something that was not available (such as API Access Management). To resolve this error verify the redirect URI matches between what is in Okta and what is configured in Addigy. Additionally, very if API Access Management needs to be enabled or disabled within your Addigy Identity Okta configuration.

Error: 403 (Okta)

This error appears when the user signing in does not have the correct permissions within Okta. Verify the user is fully provisioned and in the right group within Okta and have the user try signing in again.