Addigy Identity Settings Explained
Let's take a deeper dive into the Addigy Identity Settings available on the Policy Integration Panel.
This option allows you as an Admin to pick the desired Identity Provider that end users on these machines will authenticate against. This also determines which Addigy Identity Settings become available to you.
Block Setup Assistant while service is getting configured
This setting makes sure that when we are deploying Addigy Identity via Automated Device Enrollment that the deployment complies with the Await Device Configured option. This will hold the end-user on the enrollment screen until Addigy Identity has been fully deployed. This prevents the end-user from reaching the login window before Addigy Identity is deployed and ready to handle their authentication.
Create Users as Administrators
This setting determines if the users created via the Just In Time user account creation are admins or standard users. In some cases, the user on the machine will be allowed to be an admin on his own machine and this flag lets you manage that case. In other cases, we want every user who logs into have limited permission and we can achieve that by leaving this option off. If we have a mixed batch where some users should be admin and other standard users, we recommend leaving this option off and elevating privileges via other Addigy functionality such as Scripts, Alerts with auto recommendation and Maintenance.
Allow local credentials at the Addigy Identity login window
This setting allows users and administrators to be able to login to the machine without having to authenticate against the IdP. In scenarios where there is no internet connection on the machine, the user will not be able to authenticate against the IdP which may render him locked out if he is not able to log into his already created local account. It is important to note that bypass the IdP means bypassing password syncing and password policies. For strictly management machines it may be required to leave this option off.
Allow users to sync identity accounts with local user accounts
This setting allows for the ability to sync an Identity Provider (IdP) email from your Okta and Azure environments to an already existing local account on the device. This will help when deploying Addigy Identity to devices that are already provisioned and have existing users. When the user logins in with their IdP email for the first time, they will be prompted to select an already existing local account to sync too or to create a new local account. When choosing an already existing local account, the user will be asked to validate the local account credentials.
Allow users to leave Addigy Identity and revert to local macOS login
This setting allows the end-user to do a one time revert back to the native macOS Login window from the Addigy Identity login window. In the case, where the user may run into issues authenticating with their credentials and need access to the native macOS functionality.
Identity Provider-specific settings
By passing us the Domain of the IdP organization we can begin to authenticate users against this domain using HTTPs. The response to this authentication gives us the required user information to generate the local user account. Addigy never stores any passwords. You can find the Okta Domain on your Okta account URL. Do not include the https://
The tenant ID is used to link Addigy Identity the Azure Active Directory associated with your Organization. You find this information after creating an App under your Azure Active Directory.
The client ID references the Application within your Azure Active Directory we should access for Authentication purposes.
The client secret is a secret string that the application uses to prove its identity when requesting a token. It also can be referred to as an application password. This can be found on the Certificate & Secrets section of App Registrations.
For more information on how to configure your Azure Active Directory App, check out this knowledge base: