Interoperability

In this chapter, you will learn how Portnox Cloud connects to authentication repositories (also called identity stores, user directories, or credential databases) to use their data for authentication and authorization, and how its internal repository can be used when no central system exists.

If administrators had to recreate every company user and assign new passwords just to provide access to the network and applications, the solution would be impractical. That’s why it’s essential for any network and application security solution to rely on users that the company already manages elsewhere.

All but the smallest companies use some kind of user repository, which is primarily used for logging in to computers as well as any SSO-enabled cloud applications the company currently uses (as an identity provider). For Windows environments, this is most commonly Entra ID, which integrates seamlessly with the operating system. However, this is not always the case. Some companies may use separate systems – for example, computer login might use one directory, while a Google Workspace suite handles email and cloud apps, requiring a second login.

Portnox avoids adding yet another set of credentials. By integrating with your existing repository, Portnox Cloud allows users to authenticate to the network without needing a second or third password. Once integrated with a repository in Cloud, administrators can import all users or select groups, and assign them to relevant Cloud groups. This allows network access and application access to be managed independently from the repository’s internal group structure.

Portnox Cloud supports all major industry-standard authentication repositories, including:

• Entra ID (formerly Azure AD): Widely used in Windows-centric environments, providing seamless integration for devices and applications within Microsoft ecosystems.
• Google Workspace (GWS): Ideal for organizations that prefer Google services over Microsoft, enabling single sign-on and centralized user management across cloud-based applications.
• Okta Workforce Identity: Although less widespread, Okta has a strong niche in organizations that prioritize cloud-first identity management with flexible integration capabilities.
• Active Directory (AD): Supports traditional on-premises repositories, giving organizations that prefer not to rely entirely on cloud solutions the ability to manage users and groups locally.
• LDAP: For any other on-premises directories, Portnox supports LDAP connections.

Both AD and generic LDAP are supported via a custom agent that allows seamless integration with on-premises directories. Note that since AD and LDAP are not identity providers, they cannot be used for cloud application access control.

In this section, you will learn how Portnox Cloud sends alerts and activity logs to SIEM (Security Information and Event Management) systems.

Portnox Cloud integrates with major SIEM systems using universal standards, ensuring compatibility with both cloud-based and on-premises solutions:

• Offers direct HTTPS connections to well-known cloud providers, with Portnox continuously expanding integrations to additional third-party products.
• Supports the syslog standard, allowing alerts and logs to be sent to syslog collectors over UDP, TCP, or TLS. These collectors can then forward the data to SIEM systems. Syslog is supported by most cloud SIEM products.
• Delivers messages in JSON or CEF (Common Event Format), two widely recognized standards supported by most SIEM platforms.
• For on-premises systems, provides a Docker container or uses the existing AD/LDAP agent to integrate with the cloud. The agent periodically retrieves data from the cloud and supplies it to the on-premises SIEM, allowing for integration with any on-premises SIEM solutions.

Portnox has been tested with various SIEM systems, including Microsoft Sentinel, Rapid7 InsightIDR, Sumo Logic, Splunk, Datadog, Papertrail, Loggly, NXLog, and Kiwi Syslog Server. As long as a SIEM system supports industry standards, Portnox can integrate effectively.

Administrators can configure which alerts and events to forward to the SIEM, allowing them to filter out messages such as synchronization-completed alerts, ensuring that only required data is transmitted.

In this section, you will learn how Portnox works with UEM (Unified Endpoint Management) and MDM (Mobile Device Management) systems to deliver device certificates using the SCEP (Simple Certificate Enrollment Protocol) standard.

There are three ways to have Portnox Cloud issue certificates and deliver them to devices for passwordless authentication. One method requires distributing Portnox AgentP to devices, which some organizations may avoid due to concerns about adding extra agents. Another method requires the user to manually request a certificate through a web interface, which is not ideal for automatic enrollment. The third method leverages integration with existing UEM/MDM systems to automate certificate delivery without adding extra agents or requiring manual requests.

UEM/MDM system already have an agent – either built into the operating system (for example, Intune works with Windows natively) or a background agent installed on the device. These agents handle standard management tasks, such as delivering configurations and installing or removing software, and can also manage certificates. Portnox indirectly uses these agents to enable automatic certificate issuance and delivery to devices.

The flow of certificate issuance via UEM/MDM works as follows:

1. If a device requires a certificate for a user or the device itself, the UEM/MDM system agent sends a configuration to the device.
2. The device then formally sends a SCEP request to Portnox Cloud using its operating system’s SCEP client, directed by the UEM/MDM agent. The UEM/MDM agent acts as an initiator by instructing the device’s operating system where to send the request and what information to include, such as an ID from the UEM/MDM system, which helps Cloud identify the user and device through its integration with the UEM/MDM system.
3. Portnox Cloud receives the request, issues the certificate, and delivers it back to the device via SCEP.

Portnox has been tested with many UEM/MDM systems and platforms, including the following:

• Intune
• Google
• Jamf
• Kandji
• Addigy
• Workspace One
• SOTI
• MaaS360

As long as the operating system fully supports the SCEP standard, and the UEM/MDM solution has SCEP support for all operating systems, Portnox will work with them.

In this section, you will learn how Portnox ZTNA supports web applications using industry-standard single sign-on (SSO) methods.

Single sign-on (SSO) is a standard method for accessing web applications, and most organizations benefit from it. For example, users with company Entra ID credentials can access third-party cloud apps used by the organization without separate logins. Security can be further enhanced with certificate-based authentication, ensuring that only specific devices – or those that additionally meet risk assessment policies – can access these applications, without inconveniencing users.

The access flow with Portnox ZTNA works as follows:

1. The user accesses a web application that supports a custom SAML login. Typically, such applications provide a separate login button for custom SAML or recognize the domain secured by ZTNA from the supplied email address. After clicking the button or providing the email, the application redirects the user to ZTNA for preliminary checks.
2. ZTNA verifies the presence of a certificate stored in the operating system and accessible to the browser. If configured, it additionally retrieves device risk assessment information from the relevant agent to ensure compliance with security policies.
3. If the certificate and risk checks pass, control is forwarded to the organization’s identity provider – Entra ID, Google Workspace, or Okta. The user may then need to authenticate using the organization’s standard credentials, unless already authenticated in the browser.
4. Once authentication with the organization’s identity provider succeeds, access is granted to the application.

The ZTNA flow only introduces one additional step, which is minimally visible to the user. In the worst case, the user may need to click or confirm a certificate from a browser-displayed list, but in many cases, this step can be automated so that no interaction is required.

Portnox ZTNA supports the global standards used to connect to other SSO identity providers:

• SAML – the de facto SSO standard supported by most web applications. If an app supports Entra ID or Google Workspace, it likely supports custom SAML as well.
• OIDC – an emerging SSO standard increasingly adopted by applications, though not yet as widely supported as SAML.
• EAM for Entra ID – enables support for any application with Entra ID integration, even if that application does not support custom SAML. This ensures Portnox ZTNA can secure all applications with basic SSO support when the organization uses Entra ID.

Portnox ZTNA has been tested with over 55 popular business-oriented web applications, with Entra ID, Google Workspace, and Okta as backing identity providers for both SAML and OIDC.

In this section, you will learn how Portnox Cloud uses information from other risk assessment platforms for its own risk assessment policies, allowing you to rely on these platforms’ agents for risk assessment without requiring AgentP.

Portnox AgentP is a small, non-intrusive agent, but some organizations prefer to avoid deploying additional agents due to concerns about agent overload. Portnox Cloud addresses this need by providing the option to leverage existing risk assessment platforms.

Cloud policies can be defined in detail based on AgentP’s risk assessment categories, or administrators can simply trust another agent – meaning that if a device is managed by a specific product’s agent, Portnox considers it secure and relies on that agent to take any necessary action in case of risk. This approach allows security administrators to manage policies consistently in a single platform, avoiding duplication across multiple applications.

Supported platforms include:

• Intune
• Jamf
• Absolute Secure Endpoint
• CrowdStrike Falcon

For some platforms, Portnox Cloud allows policies to simply verify that a device is managed by another security platform, trusting its risk assessment and the actions specified by the administrator. In other cases, Portnox can retrieve the device’s risk score from the external system and adjust the Portnox risk score accordingly.

Portnox continuously monitors customer needs and adds support for new platforms as required. Initially, our focus was on integrating with the best-known industry-standard solutions, ensuring broad compatibility and reliable risk assessment coverage.