ºÚÁϺ£½Ç91Èë¿Ú

Get Started: Admin Implementation

ºÚÁϺ£½Ç91Èë¿Ú Admin Implementation Guide

Welcome to ºÚÁϺ£½Ç91Èë¿Ú! Thank you for entrusting us to manage your users and devices. This document gives you a proven, structured approach to implementing our directory services in your organization. 

Whether you’re migrating to ºÚÁϺ£½Ç91Èë¿Ú from another directory service, or beginning to organize and secure your environment, this guide will help you successfully design, test, and implement ºÚÁϺ£½Ç91Èë¿Ú.

Looking for a more tailored project plan  for your specific migration needs? Check out the Implementation Project Plans below based on your selected package.

Terminology

Get to know our product terminology:

  • Administrator: ºÚÁϺ£½Ç91Èë¿Ú administrators configure and manage ºÚÁϺ£½Ç91Èë¿Ú for their organization.
  • User: ºÚÁϺ£½Ç91Èë¿Ú users access their company resources through ºÚÁϺ£½Ç91Èë¿Ú.
  • Device: Computers or Servers that run Mac, Windows, and Linux devices can be managed through ºÚÁϺ£½Ç91Èë¿Ú. Admins can provision users to devices, deploy policies to devices, and execute commands on devices through ºÚÁϺ£½Ç91Èë¿Ú.
  • Groups: ºÚÁϺ£½Ç91Èë¿Ú connects company resources to groups of resources. For example, connect a group of users to Single Sign On (SSO) applications, RADIUS servers, and directories like Google Workspace and Microsoft 365. You can also connect groups of users to groups of devices.
  • Directory: A directory service organizes information about a network's users and resources. ºÚÁϺ£½Ç91Èë¿Ú integrates with a variety of popular directory services like Google Workspace and Microsoft 365 to sync user accounts. These integrations let ºÚÁϺ£½Ç91Èë¿Ú act as an authoritative directory with a single set of credentials that can be used across all directory services.
  • Applications: SSO SAML 2.0 applications that you can connect with ºÚÁϺ£½Ç91Èë¿Ú. Applications like Slack, Salesforce, AWS, CakeHR, and so many more.

Tip:

See our glossary for more terms.

Best Practices Before You Start

ºÚÁϺ£½Ç91Èë¿Ú University Admin Training and Certification

ºÚÁϺ£½Ç91Èë¿Ú University is a reflection of how much we value education as part of our solution. This learning platform is designed to give you the flexibility to take applicable courses and skip courses that you don’t need. We believe in freeform learning so you can take any course, watch any video, and practice any task without being locked into a certain series.

We believe learning is most effective when the learner gets to choose what they need, when they need it, and how they need it — and then move on with their day. Structure is there if you want it, but you can easily have freedom to get in, get the information you need, and get out.

Before starting your initial implementation of ºÚÁϺ£½Ç91Èë¿Ú, we recommend taking the initial courses within our catalogue. ºÚÁϺ£½Ç91Èë¿Ú is a large platform and is capable of managing a myriad of technical resources. ºÚÁϺ£½Ç91Èë¿Ú University’s courses train IT admins on best practices for utilizing ºÚÁϺ£½Ç91Èë¿Ú to the fullest extent.

It’s best practice for newer customers to have an IT team member become ºÚÁϺ£½Ç91Èë¿Ú Core Certified before rolling out the platform within the technical environment. By obtaining the ºÚÁϺ£½Ç91Èë¿Ú Core Certificate, this verifies the holder’s core knowledge, best practices, and implementation steps using ºÚÁϺ£½Ç91Èë¿Ú’s platform.

To get started with your training and certification today, check out ºÚÁϺ£½Ç91Èë¿Ú University.

Guided Simulations

Learn by doing! Explore ºÚÁϺ£½Ç91Èë¿Ú’s features from multiple perspectives without impacting your live environment or jumping through hoops for test accounts. ºÚÁϺ£½Ç91Èë¿Ú’s Guided Simulations page contains examples for both admins and users alike. These simulations cover some of our most popular modules such as agent installation, password reset, Conditional Access Policies, and configuring MDM.

These simulations are a great way to help train end users within the organization on how to leverage ºÚÁϺ£½Ç91Èë¿Ú to do important tasks like managing their passwords, activating their account, and installing the agent.

Support and Troubleshooting

  • Bookmark our Support page, where you can search our Help Center articles.
  • Familiarize yourself with our Support Policies.
  • Subscribe to the  for status updates, incident alerts, and maintenance windows.
  • If you do get stuck, reach out to ºÚÁϺ£½Ç91Èë¿Ú Support. Include the following information in your request:
    • A detailed description of your issue
    • Any troubleshooting steps or actions that you’ve taken
    • Relevant ºÚÁϺ£½Ç91Èë¿Ú Agent Logs (for device related issues)
  • Familiarize yourself with our Support Request Guidelines.

Tips for Set Up and Management

  • Avoid surprises - Avoid unexpected and unintended consequences; sign up for a free testing account.
  • Test and explore - Have a plan. Set up a staging environment, install the ºÚÁϺ£½Ç91Èë¿Ú Agent, and test any changes in a staging environment that mirrors your production devices as closely as possible. This will be helpful for initial implementation, ongoing maintenance, and updates.
  • Be consistent - The foundation for efficient, fast scaling is consistency. Successful scaling starts with a good understanding of ºÚÁϺ£½Ç91Èë¿Ú Groups.
  • Add Administrator Team Members - We always suggest adding your IT team members as ºÚÁϺ£½Ç91Èë¿Ú Administrators to your organization. You can set each admin with their own role with scoped permissions based on their job duties or needs. Learn more about how to Add Administrators to ºÚÁϺ£½Ç91Èë¿Ú and grant their Admin Account Role
  • Notify employees - To ensure a consistent line of communication between you and your employees and end-users, email them in preparation with upcoming steps, needs, and actions. ºÚÁϺ£½Ç91Èë¿Ú has supplied some generic email templates to assist with notifying your organization on the different steps throughout your implementation. Check out these ºÚÁϺ£½Ç91Èë¿Ú End-User Email Templates to use when notifying your employees.​

Set up your Admin Portal

Settings

Before you can really start to build out your ºÚÁϺ£½Ç91Èë¿Ú directory, we recommend creating and modifying various global settings like password aging, complexity, lockouts, and more. These configurations are enacted on all resources within the ºÚÁϺ£½Ç91Èë¿Ú platform.

End User Impact: None/Low

Building Users in ºÚÁϺ£½Ç91Èë¿Ú

This step involves building the user directory. You'll connect users with devices in the Going Live steps.

End User Impact: None/Low

User Import Types and Privileges required:

  • CSV Import: ºÚÁϺ£½Ç91Èë¿Ú Admin Portal privileges
  • Google Workspace Directory Import: Super Administrator credentials are required
  • Microsoft 365 Directory Import: Global Administrator credentials are required
  • Okta Real-Time User and Password Import: Administrator credentials are required
  • Active Directory Integration: Domain Administrator credentials are required
  • API Import: ºÚÁϺ£½Ç91Èë¿Ú Admin Portal privileges and an API key

Considerations:

  • CSV imported users without an initial password will not receive any welcome email. If you would like to send an activation email to these users, select them in bulk from the Users page. Click "more actions" and then "Resend Email"
  • Adding/Importing users into ºÚÁϺ£½Ç91Èë¿Ú will have no effect on existing accounts until the user is associated with a resource (Device, Google Workspace/Microsoft 365 Directory).
  • If you would like ºÚÁϺ£½Ç91Èë¿Ú to take-over existing user accounts, the ºÚÁϺ£½Ç91Èë¿Ú username must EXACTLY MATCH the local device username. If there is not an exact match, ºÚÁϺ£½Ç91Èë¿Ú will assume the username is new and create a new user profile when a user is bound to the device. See ºÚÁϺ£½Ç91Èë¿Ú User Naming Convention.
  • Usernames for users imported from Google Workspace or Microsoft 365 will be their email address prefix. Please consider whether this matches your local device usernames, or if you intend to create new local user accounts. Be aware that you can only rename usernames of user accounts that aren't yet bound to a resource.

​Step-by-step Implementation links:

CSV Import

Google Workspace Directory Import

Don't connect users to the Google Workspace Directory until you're ready to Go Live.

Microsoft 365 Directory Import

Don't connect users to the Microsoft 365 Directory until you're ready to Go Live.

Okta Real Time User Import

  • Configure Okta Real-time User and Password Import: This integration with Okta allows Okta to be the authority over ºÚÁϺ£½Ç91Èë¿Ú Users, their passwords, and User Attributes. In this configuration it is always recommended to have users change their passwords in Okta. Okta will then immediately send the new password to their ºÚÁϺ£½Ç91Èë¿Ú account and associated resources. Please note that if Users are on macOS devices, there are certain workflows that need to be followed. These macOS workflows are addressed within the KB above. 

Active Directory Integration

  • Integrating AD with ºÚÁϺ£½Ç91Èë¿Ú: This is used when you’re wanting to bridge a bisynchronous connection between your Active Directory domain and your ºÚÁϺ£½Ç91Èë¿Ú tenant. You can leverage this integration to ensure that password changes within either directory are synced to the other. Not generally recommended if you’re migrating away from or decommissioning Active Directory, as we recommend another solution such as the M365 or GWS Directory Sync to import your users. 
  • Migrating Users from Active Directory to ºÚÁϺ£½Ç91Èë¿Ú: This is used when you’re wanting to export the Active Directory users into ºÚÁϺ£½Ç91Èë¿Ú. The methods mentioned in this KB are via CSV, but you may also alternatively use the M365 or GWS import feature instead. If your users are using domain-bound devices, you will need to migrate these devices from AD-bound to a local workgroup and local user profile using the . This helps convert the devices and profiles to a local workgroup and profile while also installing the ºÚÁϺ£½Ç91Èë¿Ú Agent on your behalf. 

Deploying Agents to Devices

You should deploy the ºÚÁϺ£½Ç91Èë¿Ú agent on any devices that you want ºÚÁϺ£½Ç91Èë¿Ú to manage. You can install the ºÚÁϺ£½Ç91Èë¿Ú agent on devices that are connected to a domain, however the agent is limited to just Commands and System Insights.

End User ImpactLow

Required Privileges:

  • Manual and Remote Installs require remote root / administrator access to the device. To commit remote installs, you may need an RMM, MDM, or remote tooling to install the ºÚÁϺ£½Ç91Èë¿Ú Agent. Otherwise you may manually install by being physically present to install or via a remote screen share software with your users. 
  • End-User Installs require the User to have local root / administrator privileges to the device.

ºÚÁϺ£½Ç91Èë¿Ú Agent Requirements:

Considerations

  • Command line vs. manual install depending on current environment size and expected future growth and desired deployment practices.
  • Establish a consistent naming convention for your user accounts. Verify your ºÚÁϺ£½Ç91Èë¿Ú naming convention for usernames exactly matches the usernames on existing devices to ensure proper account take over.  
  • Consider establishing a consistent naming convention for device names. 
  • Ensure that the network is configured to allow communication with ºÚÁϺ£½Ç91Èë¿Ú's servers.

Installation Methods:

Windows

Linux

  • Manual Installation via ºÚÁϺ£½Ç91Èë¿Ú Admin Portal or manual distribution of command-line install.
  • End User Installs from User Portal
  • Command line: curl --silent --show-error --header 'x-connect-key: YOUR_CONNECT_KEY' https://kickstart.jumpcloud.com/Kickstart | sudo bash
  • Automation via Configuration Management Tools:

macOS

Before deploying agents to your macOS devices, ºÚÁϺ£½Ç91Èë¿Ú recommends configuring ºÚÁϺ£½Ç91Èë¿Ú MDM with your ABM account. Check out how you can ºÚÁϺ£½Ç91Èë¿Ú

If you’re using a third-party MDM (like JAMF, Kandji, Mosyle, etc), you may disregard the latter statement and continue installing the ºÚÁϺ£½Ç91Èë¿Ú Agent. 

Note: Users must approve Full Disk Access to the ºÚÁϺ£½Ç91Èë¿Ú Agent during install for macOS 12.0+ Monterey. See how to grant full disk access to the ºÚÁϺ£½Ç91Èë¿Ú Agent

Configuring ºÚÁϺ£½Ç91Èë¿Ú Groups

At ºÚÁϺ£½Ç91Èë¿Ú’s core, it's all about managing Users, their access, passwords, and identities across your environment. We recommend creating User Groups and Device Groups first as this will help you organize your user and device objects when you begin to import and add resources. As ºÚÁϺ£½Ç91Èë¿Ú is GBAC-based (group-based access control), before Users can be given access to resources such as SSO Apps, they must be bound to a User Group that’s been granted App access.

Creating User Groups

Groups are the best way to control users' access to resources. If the groups will be used to control access to a resource, connect the group to the resource.

End User Impact: Low

Considerations:

  • Create groups as needed for a given resource, and add user groups to the resources.
  • Establish a naming convention for user groups that aligns across your organization.
  • Determine a consistent, scalable structure for groups.
  • User groups should be used to control access to devices, SSO applications, RADIUS networks, and directories like Google Workspace, Microsoft 365, and LDAP.
  • Learn More: Getting Started: User Groups

Implementation Steps:

  1. Log in to the ºÚÁϺ£½Ç91Èë¿Ú Administrator Portal: .
  2. Go to USER MANAGEMENT > User Groups.
  3. Click the '+' button to create a new user group. 
  4. Create a name for the group and add any additional attributes. 
  5. Go to USER MANAGEMENT > Users to bind users to the new user group. 
  6. Click Save.

Creating Device Groups

Device groups can be used to control user or user group access to devices.

End User Impact: Low

Considerations

  • Policies and Policy Groups should be applied to Device Groups.
  • Device Groups can contain a mix of operating systems.
  • Create Device Groups as needed for your devices.
  • Connect devices to Device Groups.
  • Determine a scalable Device Group structure.

See Getting Started: Device Groups to learn how to create Device Groups.

Going Live

Educate Your Employees

When installing any new software or environment-wide application, it’s always best practice to educate and notify your end users before implementing. Send the following links to your organization employees so they can be aware of any changes, steps, and items during the implementation project. 

Note: See Email Templates and Recommendations for Educating Users for example user communications before implementing certain features throughout your project plan.

End User Impact: High

Ensure end users understand ºÚÁϺ£½Ç91Èë¿Ú will be managing their identity — their access to devices, applications, and other resources is managed by ºÚÁϺ£½Ç91Èë¿Ú.

  • You can connect the user to any of the resources connected to ºÚÁϺ£½Ç91Èë¿Ú from a device to applications, networks, etc. However, if the user is created in a Staged user state, they will not gain access to their assigned resources until they are activated. See Managing User States for specific information about when a user is provisioned.
  • Users update their passwords from the User Portal or from their ºÚÁϺ£½Ç91Èë¿Ú Tray App on their device. See
  • If Mac users update their passwords in the ºÚÁϺ£½Ç91Èë¿Ú User Portal instead of changing it in the ºÚÁϺ£½Ç91Èë¿Ú Mac Tray App, they'll have to log out and log back in to update their Keychain and FileVault password. 
  • Google Workspace and Microsoft 365 users change their passwords in the ºÚÁϺ£½Ç91Èë¿Ú User Portal. If users change their passwords within either of these directories instead of ºÚÁϺ£½Ç91Èë¿Ú, there may be a password discrepancy between the two.

Considerations:

  • User Activation - setting a temporary password vs. sending the user activation email.
  • Notify applicable users that they will be receiving a Welcome email from ºÚÁϺ£½Ç91Èë¿Ú.
  • Educate All Users — including Google Workspace and Microsoft 365 users — that they change their password in their ºÚÁϺ£½Ç91Èë¿Ú User Portal or in their ºÚÁϺ£½Ç91Èë¿Ú managed device’s ºÚÁϺ£½Ç91Èë¿Ú Tray App. 

Implementation Steps:

  1. Customize organization information in the ºÚÁϺ£½Ç91Èë¿Ú Admin Portal under Settings.
  2. Communicate workflow changes to users.

Google Workspace Directory Sync

To use ºÚÁϺ£½Ç91Èë¿Ú's Google Workspace Directory integration, one of the following Google licenses are required:

  • Google Workspace for Business
  • Google Workspace for Education
  • Google Workspace Basic (requires valid payment input for user additions)
  • You must have an active Google Workspace domain to proceed
  • A Google Workspace Domain Admin (Super Administrator)

End User Impact: Medium - User workflow impacted

Prerequisites:

Considerations:

  • Users should be notified that ºÚÁϺ£½Ç91Èë¿Ú will be managing their Google Workspace credentials, and informed on how they should update their passwords going forward.
  • Users that are removed from the Google Workspace Directory Sync will have their accounts suspended in Google Workspace.
  • FAQ - Google Workspace User Provisioning and Sync

Implementation Steps:

  1. Learn how, see Creating & Importing Users in ºÚÁϺ£½Ç91Èë¿Ú
  2. We recommend that User Groups be used to connect users to the Google Workspace Directory. See Google Workspace User Import, Provisioning, and Sync.
  3. Users will receive an email to set or reset their ºÚÁϺ£½Ç91Èë¿Ú password to complete synchronization.
  4. If a user’s current Google Apps password meets ºÚÁϺ£½Ç91Èë¿Ú password complexity requirements, and they opt to use that for ºÚÁϺ£½Ç91Èë¿Ú registration, from their perspective there is no password reset, although they may be logged out of their active Google sessions.
  5. Monitor adoption with the user status in the ºÚÁϺ£½Ç91Èë¿Ú Admin Portal. Resend emails as necessary.

Microsoft 365 Directory Sync

Prerequisites:

  • Microsoft 365 Directory Sync Authorized in ºÚÁϺ£½Ç91Èë¿Ú
  • Users exist in the ºÚÁϺ£½Ç91Èë¿Ú Directory
  • Users have been notified of the upcoming change

End User Impact: Medium - User workflow impacted

Considerations:

  • Users should be notified that ºÚÁϺ£½Ç91Èë¿Ú will be managing their Microsoft 365 credentials, and informed on how they should update their passwords going forward.
  • Users that are removed from the Microsoft 365 Directory Sync will have their accounts suspended in Microsoft 365.
  • The Microsoft 365 Directory Sync has to be reauthorized every 90 Days.
  • FAQ - Microsoft 365 User Provisioning and Sync

Implementation Steps:

  1. Learn how, see Creating & Importing Users in ºÚÁϺ£½Ç91Èë¿Ú.
  2. It is recommended that User Groups be used to bind users to the Microsoft 365 Director. See Microsoft 365 User Import, Provisioning, and Sync.
  3. Users will receive an email to set or reset their ºÚÁϺ£½Ç91Èë¿Ú password to complete synchronization.  
  4. If the user’s current Microsoft 365 password meets ºÚÁϺ£½Ç91Èë¿Ú password complexity requirements and they opt to use that for ºÚÁϺ£½Ç91Èë¿Ú registration, from their perspective there is no password reset, although they may be logged out of their active sessions.
  5. Monitor adoption with the user status in the ºÚÁϺ£½Ç91Èë¿Ú Console. Resend emails as necessary.

User and Device Takeover

Prerequisites

  • ºÚÁϺ£½Ç91Èë¿Ú agent is installed on devices and the device status is active/green in Admin Portal.
  • Users are active in ºÚÁϺ£½Ç91Èë¿Ú.
  • ºÚÁϺ£½Ç91Èë¿Ú usernames and device usernames match.
  • Users have been notified of the change and understand where to update their passwords.
  • Admins understand the expected behavior when users and devices are connected.
  • You've successfully tested devices in your environment.

Considerations:

  • Whether to use a phased roll-out approach or an all-at-once approach of going live with all users and devices at one time.
    • Phased roll-out: This is useful if the majority of users are able to migrate to ºÚÁϺ£½Ç91Èë¿Ú, however there is a group of users restricted by time. The phased roll-out is also useful for organizations with distributed teams. We recommend this approach for going live.
    • All-at-once: This approach is most typically used when all users are migrated at the same time. 
  • Ensure that the timing of implementing these tasks won't disrupt business operations, and that support staff are ready to assist if needed.
  • Windows Live accounts aren't supported and will need to be converted to local accounts. Learn how, see Unlinking a Windows Live Account.
  • Active Directory bound devices with AD managed profiles are not supported for account takeover by ºÚÁϺ£½Ç91Èë¿Ú. Please see the for more details.

End User Impact: High - Users will be using their ºÚÁϺ£½Ç91Èë¿Ú identities / accounts to authenticate to devices.

Existing Account Takeover (All OSes)

Implementation Steps:

  1. Ensure ºÚÁϺ£½Ç91Èë¿Ú usernames and local device usernames match. If there are discrepancies, learn how in Changing Existing Usernames in Devices.
  2. Connect the user to a device by going to USER MANAGEMENT > Users. Then click on a user and go to the Devices tab.
  3. Allow up to a few minutes for the synchronization to occur.
  4. Advise users to log out and log back in with their ºÚÁϺ£½Ç91Èë¿Ú account credentials.

Note: Be aware that changing usernames on Mac and Linux isn't generally recommended unless you have full understanding of the impacts of doing so. Changing the username on these platforms can have adverse effects on application and file access.

New Local Accounts (All OSes)

Implementation Steps:

  1. Connect the user to a device on the Devices tab of the user's Details panel.
  2. Allow up to a few minutes for the synchronization to occur.
  3. Advise users to log in with their ºÚÁϺ£½Ç91Èë¿Ú account credentials.

Policies and Policy Groups

ºÚÁϺ£½Ç91Èë¿Ú Policies let admins control the behavior of devices for various purposes, most commonly to enforce security standards. Policies are set through the ºÚÁϺ£½Ç91Èë¿Ú Admin Portal and require no coding skills. After they are configured, admins can deploy policies to groups of devices and monitor the status of each device to ensure the policy is enabled.

Considerations:

  • When configuring an individual policy, they should be applied to device groups. 
  • We recommend using Policy Groups. Policy Groups can contain multiple policies you configure and you may then apply the Policy Group to Device Groups. For example, if you have a security baseline you need to meet, a singular Policy Group could contain X number of policies, which you can then bind to a Device Group(s). 
  • Some policies can be applied to all users, or only ºÚÁϺ£½Ç91Èë¿Ú managed users on the device.
  • Some policies require additional action, such as user log out / log in or device restart to take effect. Refer to the Policy Activation Details on the ºÚÁϺ£½Ç91Èë¿Ú Policy’s Details pane for more information.
  • Some policies are only compatible with certain OS versions and license levels.

End User Impact: Low to High - depending on the policy

Implementation Steps:

  1. Create a new policy, configuring any required settings. 
  2. Create a new policy group. Add previously configured policies to this policy group.
  3. Connect the policy group to a device group.

Configuring Applications (SSO / SAML)

Considerations:

  • Enabling SSO for a Service Provider (SP) will typically disable username/password authentication for all users. Please test during a maintenance window, or in a sandbox environment if available.
  • Service Provider requirements.
  • Administrators should be able to generate an SSL Certificate/ Key pair. See Generating a Public Certificate / Private Key Pair Using OpenSSL.
  • Users should be educated on how they will authenticate into applications after SSO is enabled
  • SP initiated vs. IdP initiated SSO

End User Impact: Medium - User authentication workflow changes. Once configured, Users must authenticate through ºÚÁϺ£½Ç91Èë¿Ú before access is granted to the application.

Implementation Steps:

  1. Review SSO documentation for both ºÚÁϺ£½Ç91Èë¿Ú and the Service Provider.
  2. Create a User Group to manage which users access the application.
  3. Grant user access by assigning users to the appropriate user  groups.
  4. Configure the SSO application within ºÚÁϺ£½Ç91Èë¿Ú.
  5. Configure SSO in the Service Provider’s settings.
  6. Test to ensure authentication workflow routes through ºÚÁϺ£½Ç91Èë¿Ú.
  7. Enable either SCIM or JIT on the ºÚÁϺ£½Ç91Èë¿Ú SSO Connector, if the SP supports either protocol. If SCIM is supported by the SP, we recommend configuring SCIM and not configuring JIT as SCIM handles the full-lifecycle of users, where JIT only supports creation and updates. 

SSO Scenarios: SP initiated & IdP initiated

  • The SP initiated workflow is the scenario where SSO is enabled for an application, and a user attempts to login via the SP. The expected behavior is that the user will be redirected to the ºÚÁϺ£½Ç91Èë¿Ú login page. After they log in, the user is authenticated and logged in to the SP.
  • The IdP initiated workflow is the scenario where a user logs in to their ºÚÁϺ£½Ç91Èë¿Ú User Portal and logs in to an application via one of the application icons in their Portal dashboard. ​

Configuring LDAP 

Prerequisites:

  • Service Provider LDAP configuration documentation and/or support.
  • A working LDAP Binding User (This is the service account for ºÚÁϺ£½Ç91Èë¿Ú LDAP).
  • ºÚÁϺ£½Ç91Èë¿Ú Users have been bound to the LDAP Directory.

Considerations:

  • LDAP Binding Service account naming convention.
  • LDAP configurations vary depending on the Service Provider.
  • Naming conventions for LDAP Groups.
  • Familiarity with ldapsearch for testing and troubleshooting. See Using ldapsearch with ºÚÁϺ£½Ç91Èë¿Ú.

End User Impact: Medium - User authentication workflow impacted

Implementation Steps:

  1. Prepare an LDAP Binding User account. See Using ºÚÁϺ£½Ç91Èë¿Ú's LDAP-as-a-Service.
  2. Create a User Group to manage which users are given access to LDAP Authentication.
  3. Grant user access by assigning users to the appropriate user groups.
  4. Bind User Groups to LDAP.
  5. Complete LDAP configuration within the Service Provider.
  6. Test connectivity. This may not be available for all vendors.
  7. Go live by enabling LDAP authentication in the Service Provider configuration.

Configuring RADIUS

Prerequisites:

  • ºÚÁϺ£½Ç91Èë¿Ú Users connected to a user group.
  • Users have activated their ºÚÁϺ£½Ç91Èë¿Ú accounts.
  • Wireless Access Points (WAP’s) which support RADIUS Authentication.

Considerations:

End User Impact: Medium - User workflow impacted

Implementation Steps:

  1. Configurations vary by vendor. For links to RADIUS basics and limited specific setup docs.
  2. Create a User Group to manage which users are given access to the RADIUS network.
  3. Grant user access by assigning users to the appropriate user groups.
  4. Bind User Groups to the ºÚÁϺ£½Ç91Èë¿Ú RADIUS endpoint.
  5. Complete RADIUS configuration within the networking device. Check with your vendor’s documentation on how to configure RADIUS.
  6. Test connectivity. This may not be available for all vendors.
  7. Go live by enabling RADIUS authentication in the network configuration.

Configuring Conditional Access Policies (if applicable)

Use Conditional Access Policies to implement Zero Trust security in your organization. You can create conditional access policies that secure access to resources based on conditions like a user's identity and the network and device they’re on. For example, lock down your environment with policies that deny access when users are on unmanaged devices or unapproved networks. Alternatively, relax access and let users log in to the User Portal without Multi-factor Authentication (MFA) when they’re on a VPN or managed device.  

Prerequisites:

  • ºÚÁϺ£½Ç91Èë¿Ú Users are activated
  • You’ve created ºÚÁϺ£½Ç91Èë¿Ú User Groups
  • Devices are managed by ºÚÁϺ£½Ç91Èë¿Ú
  • SSO Applications have been configured in ºÚÁϺ£½Ç91Èë¿Ú

Considerations:

  • Conditional Access Policies are included within the ºÚÁϺ£½Ç91Èë¿Ú Platform Plus package
  • Conditional Access Policies focusing on Device Trust require the ºÚÁϺ£½Ç91Èë¿Ú Agent to be running on your managed devices.

End User Impact: Medium - User workflow impacted

Implementation Steps:

  1. Navigate to Conditional Policies in the left hand menu.
  2. Click the '+' button to create a policy. 
  3. Configure the policy for either device trust, network trust, geolocation, or MFA by group as you require for your security compliance. 
  4. Click Save.

To learn more about Conditional Access Policies and how to properly configure these types of policies, see, Getting Started: Conditional Access Policies.

Directory Insights

Directory Insights is ºÚÁϺ£½Ç91Èë¿Ú's event logging and compliance feature. Directory Insights shines a light on audit trails leading up to critical events so you know the what, where, when, how, and who of your directory activities. You can use our RESTful API, PowerShell Module, and Administrator Portal to access event logs, see activity happening in your directory, and monitor user authentications to the User Portal, SAML SSO applications, RADIUS, and LDAP. 

Prerequisites:

  • ºÚÁϺ£½Ç91Èë¿Ú Pricing Package that includes Directory Insights

Considerations:

End User Impact: None 

Implementation Steps:

  1. Go to INSIGHTS > Directory.
  2. Create views, filters, and select time ranges which you want to audit. 
  3. Export the data to JSON or CSV via the export drop down in the right hand side. 

Complete

After following the steps above alongside your Project Plan, you should be completed with your implementation of ºÚÁϺ£½Ç91Èë¿Ú’s platform. If you run into any break-fix issues along the way or after your implementation, please contact support by creating a support ticket within the Admin Portal. 

Back to Top

List IconIn this Article

Still Have Questions?

If you cannot find an answer to your question in our FAQ, you can always contact us.

Submit a Case