Ivanti Blog: Posts by

The Ultimate Guide to Intune Migrations to Ivanti UEM: Connect to your Enterprise Resources

Tue, 03 Sep 2024 10:00:01 Z

When migrating from Intune, Ivanti UEM can provide users secure access to enterprise services, either on-premises or via the cloud based. This is another key pillar of our ultimate guide to migrations from Intune to Ivanti UEM.

Ivanti provides Ivanti Access for cloud authentication infrastructure and Ivanti Sentry for on-premises resources. Both components leverage conditional access to ensure only secure, known devices are allowed to authenticate.

If you are using Entra Conditional Access as part of your Intune deployment and wish to continue using this, Ivanti UEM has an out-of-the-box integration to send compliance information from Ivanti-managed devices into Entra. This is configured in the Ivanti UEM admin console under the Admin-Microsoft-Device Compliance header.

Ivanti Sentry

Ivanti Sentry is a highly scalable appliance server that can be deployed in your environment as a virtual machine (VM) on-premises or in the cloud (AWS or Azure). With the right resources, up to 20,000 device connections can be supported on a single VM. This gives you the flexibility to place Sentry servers where needed. Customers can freely deploy as many Sentry instances as required – for example behind a load balancer for High Availability or regional instances for optimal connectivity.

Installation is mostly automated; admins only need to provide environment variables (network details). The final step registers Sentry to your Neurons UEM instance.

Once installed, Sentry can be configured to accept VPN connections from the Ivanti Tunnel VPN end user application, and/or behave as an ActiveSync proxy for both on-premises and Exchange Online implementations.

Sentry configuration post-installation is done entirely from within the Ivanti UEM console under the Admin-Infrastructure-Sentry tab. The only time you need to directly interact with the Sentry server is for upgrading or troubleshooting.

After configuring the services you wish to use on Sentry, the profile is assigned to the server(s) and automatically pushed/updated to make changes live.

As part of the device authentication process (certificate or Kerberos authentication is supported), Sentry checks the device posture with the UEM console to ensure the device is managed, in a compliant state and will block or revoke connections should a device fall out of compliance. This protects the services that sit behind Sentry from bad devices/actors.

Ivanti Access

Ivanti Access is an Ivanti-hosted cloud service that secures access to business cloud services such as Box, G Suite, Office 365, Salesforce, etc.

Ivanti Access can provide conditional access based on the following:

Device identity: Ensures only enrolled and compliant devices can authenticate. Ivanti Access is also able to distinguish between company- and employee-owned devices.
User identity: Ensures the user trying to authenticate is allowed to access the resource.
App identity: Ivanti Access can block authentication on any unknown or disallowed apps, ensuring only IT-approved applications are allowed to authenticate.

The technology Ivanti Access is based on utilizes federation and authentication with SAML or WS-Fed services and authentication with FIDO2 or certificate-based authentication. If your identity provider (Idp) and service provider (Sp) supports one or more of these, it should work with Ivanti Access.

Depending on the capabilities of your Idp, Ivanti Access can be configured in:

Full-federation mode, in which Ivanti Access sits in the middle of your authentication flow.
Delegated-Idp mode, in which your Idp controls which authentication requests are sent to Ivanti Access for conditional access and authentication.

Multiple Ivanti UEM instances can be linked to a single Ivanti Access instance (on-premises or cloud-based), as well as support out of the box for SCCM- and JAMF-managed devices.

Ivanti Access is configured on a per-service basis, so organizations can onboard services at their own pace; it doesn’t have to be a “big bang” approach. Flexibility is a big benefit of Ivanti Access; I have over 10 Sps configured across three Idps, as the screenshot below shows.

After adding services, the next step is to create or assign a conditional access policy. Each service can use the same policy, or you can create separate policies. The configuration possibilities can be very granular and utilize templated/default options, custom policies, set Allow/Warn/Block or policy-chaining actions.

The final step is to set the user experience for when users are blocked. Ivanti Access displays customizable remediation pages, allowing you to tell users not only that they have been blocked, but also what they need to do to gain access. This is a much more intuitive user experience than showing “Access Denied” with a long error code – or worse, no additional context. This can help reduce the number of help desk calls related to authentication issues.

User authentication attempts are visible in near real time under the reports tab. Admins can view granular-level records or use the dashboard available on the home page that will show your entire user estate at a high level.

User experience

Sentry and Ivanti Access are designed to be invisible services to your end users when using devices managed by Ivanti UEM.

A significant benefit for your users with Ivanti Access is our Zero Sign On technology. Ivanti can replace the password with certificate-based or FIDO2-based authentication for true password-less authentication. Depending on configuration, this can be an entirely invisible process when using a compliant device. Authorized apps are installed by admins or users and start working without the user entering any information.

For desktop users, administrators can allow any mix of QR code, security key (e.g., YubiKey), device biometrics (Windows Hello or TouchID), Ivanti Authenticate ZSO client or redirection to the original Idp for users to authenticate. The screenshot below shows the user desktop experience, which is what a user would see when logging in from portal.office.com, for example:

The QR code capability is part of the Ivanti UEM client on mobile – no additional MFA app required. Should users run into an issue with authentication, they will be able to get themselves up and running or be able to provide clear information should they need to contact the help desk.

In my next article, I will cover the last main pillar of infrastructure – Mobile Threat Defense – before we move on to devices.

The Ultimate Guide to Intune Migrations to Ivanti UEM

Wed, 10 Jul 2024 13:16:57 Z

If you have purchased Ivanti UEM and are migrating to it from Microsoft Intune, you as an IT administrator must understand and execute several critical steps to make that transition smoothly.

In this series of blogs, I will be looking from an Intune admin’s perspective at what it takes to migrate from Intune to Ivanti UEM. I will cover practical elements and best practices, translating terminology used across both products to pave the way for a seamless and successful transition.

Like Microsoft, Ivanti has a wide portfolio of products, solutions and licensing bundles. I will only reference capabilities available within our Ivanti Secure UEM Premium package and Mobile Threat Defense. This information will be invaluable in setting up Ivanti UEM to map to the functions you used in Intune.

In assessing your Intune vs. Ivanti setup, first consider where you would like to deploy. Ivanti can deploy a comprehensive UEM solution fully on-premises, fully cloud and hybrid cloud. Functionality among all deployment types is broadly the same, but I will focus on our cloud capabilities with UEM.

Ivanti has the following infrastructure elements to its UEM solution:

Neurons for UEM
Connector
Sentry
Access

For a detailed breakdown of everything within our UEM solution, from infrastructure to end-user applications, see our product guide here.

From a Microsoft Intune vs. Ivanti perspective, you are immediately able to consolidate and simplify existing infrastructure services you have been using. I will examine Ivanti Access and Sentry products in a future post.

Create a migration plan to onboard users and admins

For a successful Intune migration to Ivanti UEM, creating a thorough Intune migration project plan will minimize disruption for your end users. It will also ease the burden on your help desk. For more support, our Ivanti Support Portal and Ivanti Professional Services team, and our extensive partner network, can guide you.

Most customers can divide the project into four phases:

Plan
Design
Implement
Rollout

Considerations for steps two, three and four will be covered throughout the series. Every customer is different, and every platform and OS has nuances that I will explain.

The planning phase is the ideal time to examine how you are doing things with UEM today – the good, the bad and things to improve. Do this across the IT organization, looking from the help desk and engaging security teams for their perspective. It is equally important to engage your end users and speak to departments for their feedback. This gives stakeholders a voice on the Intune migration to Ivanti UEM and gets them engaged – and makes IT look like heroes when the project is delivered smoothly.

Ask your user base and stakeholders for feedback in these areas:

End users

What applications or services are critical to your day-to-day tasks?
Where are they struggling or getting frustrated using devices?
Are they happy with the choice of devices available to them?
Would they like to use their own devices?
If they could improve one thing about interacting with company devices or systems, what would it be?

Department/business leaders

What is working today?
What are some of the security challenges for end-user devices?
Does the security team have enough visibility and reporting of devices?
Where are your support tickets coming from?
What workflows in the business could be improved with changes in device management?

Incorporate information into your Intune migration project plan so your business can execute a seamless transition to Ivanti UEM – and you can show extra benefits from day one.

As well as introducing new functionality for end users, you can deprecate some policies and configurations no longer used, as the operating systems you support have evolved. For example, features that might have been controlled by GPO on a Windows device can now have a modern management API – a much more efficient way of working with Windows devices.

Identifying your use cases and business requirements based on business need and required outcome is critical, as trying to map features line by line between Intune and Ivanti, or any other platform, can quickly become difficult. Each platform might have different naming conventions or ways of working.

Other ways to shape your Intune migration project plan are to:

Establish and document deployment objectives.
Analyze existing functionality and use cases and translate them to Ivanti UEM.
Scope rollout phasing (geography, function).
Scope user and admin roles/permissions.
Scope device registration approach.
Scope policy requirements.
Review technical and security requirements

Populate your estate

Ivanti UEM has the following options for populating your user estate:

Local
LDAP (Active Directory)
Entra (SCIM)
Okta (SCIM)
Roster (Apple Education)

Intune supports either Entra-created users or users synced via Entra Connect from Active Directory. Ivanti Neurons for UEM lets organizations import users from multiple sources; for example, you can use a local account for a single-app kiosk device and a directory account for a knowledge worker.

SCIM

Where you will already have either full or hybrid (AD synced) Entra user accounts and groups, you can sync them straight into the platform – removing the requirement for the Connector service if you have no CAs to integrate. After setup, you can see the status of synced users and groups.

As SCIM is a protocol for managing exchange of user identity data and not user authentication, adding your IDP of choice is required when using SCIM. Ivanti supports a range of IDPs out of the box with step-by-step documentation on implementing the IDP, as well as support for “generic” or “other” IDPs.

If your IDP supports SAML, it will more than likely work with our solution. When enabled, SAML becomes the default authentication method for all users regardless of source; add exceptions for local users as required.

LDAP

To connect to an LDAP or Microsoft AD server you must install a Connector Server. This can be installed either in AWS or on a virtual machine on-premises, and the Connector service can be obtained from the portal. After deploying Connector, an LDAP server can be added. LDAPS is supported and preferred where possible to increase security.

After configuring your LDAP service, the status page will show status and sync information. IDP integration is not required when using LDAP; users will be authenticated against the directory without requiring passwords be synced to Ivanti UEM.

Local Users

Local users can be created on an ad-hoc basis or with bulk csv upload using the template downloaded from the portal. This is similar to creating users in Entra. Additionally, local accounts can be created for API functions when connecting to services outside Ivanti UEM. As you can see in the screenshot from my lab environment, I have three sources of users working side by side:

It might be wise to map your use cases across all platforms and identify what user type to use for the best security and user experience.

In addition to supporting users from multiple sources, our platform also supports user groups from multiple sources.

These user groups can be used for assigning policies, configurations, applications and enrollment policies – almost anything that must be assigned to users. When creating local user groups, use our advanced search and filtering capability to create a local user group based on any combination of user information, including custom attributes from LDAP/Entra or locally created entities.

Administrators

Ivanti UEM features granular administration roles and capabilities. Administrator roles can be bulk assigned against user groups or individually to unique administrators. There are over 20 preconfigured admin roles and the ability to create custom roles.

Broadly speaking, there are similar concepts with admin roles across Ivanti and Intune, with capabilities for View Only through to Full/Global Administrator level.

Ivanti helps organizations with large or complex user estates or geographical considerations with Spaces. Spaces separate an Ivanti Neurons for MDM system into independently managed entities for delegated administration.

Spaces can be created to reflect an organizational hierarchy. Ivanti Neurons for MDM supports single-level delegation with a central management entity called a Default Space, and subordinate management entities called Delegated Spaces. This is similar to the Scope Tags capability in Intune but isn’t limited to Security Groups synced within the platform.

Organizations might have local IT departments that manage a certain set of devices – for example, U.S.-based devices, or just Windows devices or Android – and don't need to see other devices. Spaces can have admins assigned to reflect your requirements.

Next time, we’ll look at securing your device connectivity to on-premises and cloud infrastructure, ensuring the security of your data from source to device.