Skip to content
Docs

LDAP, AD & Entra ID Integration with Mideye

Mideye Server integrates with your existing user directories to look up users, validate credentials, and apply group-based authentication policies. It supports LDAP, Active Directory, Microsoft Entra ID (formerly Azure AD), and its own local user database — and you can use them simultaneously.

Why directory integration matters for MFA

Section titled “Why directory integration matters for MFA”

An MFA server needs to know who your users are, how to reach them, and what authentication method to use. Without directory integration, you’d need to maintain a separate user database — duplicating data, creating sync issues, and adding administrative overhead.

AuthenticationRequest (username)Mideye Server1. Active Directory(LDAP/LDAPS)2. Entra ID(Graph API)3. OpenLDAP(LDAP/LDAPS)4. Local DatabaseUser Found→ phone, groups,auth type, attributesUser Lookup(priority order) Search Not foundNot foundNot found Match ✓Match ✓Match ✓Match ✓

Mideye Server reads user information directly from your existing directory. When a user authenticates, Mideye looks up their profile to determine:

  • Is this a valid user?
  • What phone number should receive the OTP or push notification?
  • Which authentication type is assigned (push, SMS, TOTP, hardware token)?
  • Which RADIUS attributes should be included in the response (VLAN, group, session parameters)?
  • Is the account locked or disabled?

All of this happens at authentication time — no bulk data imports, no scheduled syncs, no stale data.

Supported directories

Section titled “Supported directories”

LDAP and Active Directory

Section titled “LDAP and Active Directory”

LDAP (Lightweight Directory Access Protocol) is the standard protocol for accessing directory services. Active Directory, the most widely deployed enterprise directory, speaks LDAP. Mideye Server connects to any LDAP-compliant directory, including:

  • Microsoft Active Directory (AD)
  • OpenLDAP
  • 389 Directory Server (Red Hat)
  • Oracle Internet Directory
  • Any LDAPv3-compatible directory

How it works:

  1. You configure one or more LDAP profiles in Mideye Server, specifying the directory server address, base DN, bind credentials, and search filters.
  2. When a user authenticates, Mideye Server queries the LDAP directory to find the user record.
  3. Mideye validates the user’s password by performing an LDAP bind or by comparing the password hash.
  4. User attributes (phone number, group memberships, email, optional per-user authentication type) are read from the directory and used to configure the authentication method and RADIUS response attributes.

Connections use LDAP (port 389) or LDAPS (LDAP over TLS, port 636) depending on your configuration. TLS is strongly recommended for production.

Microsoft Entra ID (Azure AD)

Section titled “Microsoft Entra ID (Azure AD)”

For organizations using Microsoft Entra ID as their identity provider, Mideye Server connects via the Microsoft Graph API. This enables MFA for Entra ID users without requiring an on-premises Active Directory.

Entra ID profiles work similarly to LDAP profiles: you configure the tenant ID, client credentials, and user attribute mappings. Mideye queries Entra ID at authentication time to look up user details and group memberships.

Local Mideye database

Section titled “Local Mideye database”

Mideye Server also has its own local user database. Local users authenticate directly against Mideye Server without any external directory lookup.

The local database is useful for:

  • Organizations without a directory service. Smaller organizations that don’t run LDAP or Entra ID can manage users directly in Mideye.
  • Service accounts and test users. Accounts that shouldn’t exist in the corporate directory.
  • Break-glass accounts. Emergency access accounts that work even if the directory is unreachable.

Authentication type assignment

Section titled “Authentication type assignment”

Mideye Server determines which MFA method a user should use through a priority-based system:

Priority order

Section titled “Priority order”
  1. Local override — Set in Mideye’s admin interface for specific users (highest priority)
  2. Per-user directory attribute — Read from an LDAP attribute like pager or custom field
  3. Default authentication type — Configured on the LDAP/Entra ID profile (fallback)

How it works

Section titled “How it works”

When configuring an LDAP profile, you specify:

  • Default Authentication Type — Applied to all users from this directory (e.g., TOUCH_MOBILE)
  • Read Optional Attributes — Enable to read per-user settings from the directory
  • Auth Type Attribute — Which LDAP attribute contains the auth type (default: pager)

The attribute value can be numeric (6 for Touch) or text (touch, mobile, token, totp, etc.).

Supported authentication type values:

All values are case-insensitive. You can use either the numeric value or any of the text values.

NumericText values (case-insensitive)Authentication Type
1password, lösenord, passord, salasanaPASSWORD — Password only
2mobile, mobil, puhelinMOBILE — SMS OTP
3token, dosa, brikke, korttiTOKEN — Hardware token
4concatCONCAT — Password + OTP concatenated
5plusPLUS — Mideye Plus app signing
6touchTOUCH — Push notification
7touch-plus, touch_plusTOUCH_PLUS — Touch with Plus fallback
8touch-mobile, touch-mobil, touch-puhelin, touch_mobile, touch_mobil, touch_puhelinTOUCH_MOBILE — Touch with SMS fallback
9(numeric only)ASSISTED_LOGIN — Approver-based authentication
10(numeric only)SHARED_ACCOUNT — Shared account authentication
11totpON_PREM — TOTP (authenticator app)

Example: Per-user authentication types

Section titled “Example: Per-user authentication types”
# User 1: Touch authentication
dn: CN=Alice Smith,OU=Users,DC=corp,DC=local
sAMAccountName: alice
mobile: +1-555-0101
pager: touch


# User 2: SMS OTP
dn: CN=Bob Johnson,OU=Users,DC=corp,DC=local
sAMAccountName: bob
mobile: +1-555-0102
pager: mobile


# User 3: No attribute — uses default from LDAP profile
dn: CN=Carol White,OU=Users,DC=corp,DC=local
sAMAccountName: carol
mobile: +1-555-0103

Implementing group-based policies

Section titled “Implementing group-based policies”

Mideye doesn’t have a native group-to-authentication-type mapping feature. However, you can achieve group-based MFA policies by managing directory attributes based on group membership:

Option 1: PowerShell script (Active Directory)

Terminal window
# Set Touch auth for VPN-Touch group members
Get-ADGroupMember -Identity "VPN-Touch" | ForEach-Object {
    Set-ADUser $_.SamAccountName -Replace @{pager="touch"}
}


# Set SMS OTP for VPN-Mobile group members
Get-ADGroupMember -Identity "VPN-Mobile" | ForEach-Object {
    Set-ADUser $_.SamAccountName -Replace @{pager="mobile"}
}

Option 2: Active Directory Group Policy

Use GPO to set user attributes based on security group membership.

Option 3: Identity management automation

Most IDM systems (Azure AD Connect, Okta, etc.) can set user attributes based on group membership during synchronization.

Result: When you add a user to a group in AD and update their attribute, their MFA method changes on the next authentication — no Mideye configuration needed.

Group-based access control

Section titled “Group-based access control”

Directory groups serve a different purpose in Mideye: they control who can authenticate via a specific LDAP profile, not how they authenticate.

When you configure groups on an LDAP profile:

  • No groups configured — All users in the directory can authenticate
  • Groups configured — Only members of those groups can authenticate

This is useful for:

  • Restricting VPN access to specific departments
  • Separating production and test user populations
  • Phased MFA rollouts (start with a pilot group)

Example:

LDAP Profile: "Corporate AD"
  Groups:
    - CN=VPN-Users,OU=Security,DC=corp,DC=local
    - CN=Remote-Workers,OU=Security,DC=corp,DC=local

Only members of VPN-Users or Remote-Workers can authenticate via this profile. Non-members are rejected immediately after the directory lookup.

Local overrides for directory users

Section titled “Local overrides for directory users”

Sometimes you need a user from the directory to have different settings in Mideye than what the directory provides. Local overrides let you change specific attributes for directory-imported users without modifying the directory source:

  • Assign a different phone number (e.g., a temporary number during travel)
  • Override the authentication type for a specific user
  • Set a different RADIUS response attribute
  • Temporarily disable MFA for troubleshooting

Local overrides are stored in Mideye’s local database. The directory remains the source of truth for the base attributes; Mideye applies overrides on top.

RADIUS attribute translation

Section titled “RADIUS attribute translation”

When Mideye Server sends a RADIUS Access-Accept to your VPN or firewall, it can include RADIUS attributes based on values from the user’s directory record. This is called RADIUS attribute translation.

Common use cases:

Directory attributeRADIUS attributePurpose
Department or groupFilter-Id or VSAVLAN assignment based on user’s department
Custom LDAP attributeVendor-Specific AttributeRole-based access level passed to the VPN
Group membershipClass attributeAccess policy selection on the firewall

Attribute translation is configured per LDAP profile. You define which LDAP attributes map to which RADIUS attributes, and Mideye includes them in every Access-Accept for users from that profile.

This eliminates the need to duplicate VLAN or access-group assignments in Mideye. The directory is the single source of truth; Mideye translates it into RADIUS responses.

User lockout synchronization

Section titled “User lockout synchronization”

When a user is locked out in Active Directory (too many failed password attempts), Mideye Server respects that lockout. The LDAP bind fails, and Mideye returns a RADIUS Access-Reject — it won’t try to deliver a second factor for a locked-out account.

Similarly, disabled accounts in LDAP or Entra ID are rejected at the directory lookup stage. Mideye doesn’t need a separate lockout mechanism when the directory already enforces it.

For local users, Mideye has its own lockout policy with configurable thresholds.

Multiple directories simultaneously

Section titled “Multiple directories simultaneously”

Mideye Server supports multiple directory profiles simultaneously. This is useful for:

  • Multiple Active Directory forests. Connect to each forest with a separate LDAP profile. Users from any forest can authenticate.
  • LDAP + Entra ID hybrid. On-premises users authenticate against AD, cloud users against Entra ID.
  • Acquired organizations. During mergers and acquisitions, connect to both directories while consolidation is in progress.
  • LDAP + local database. Most users come from the directory; break-glass and service accounts are local.

When a user authenticates, Mideye Server searches the configured profiles in order until it finds a match. If the user is found in multiple profiles, the first match wins. Priority order is configurable.

Security considerations

Section titled “Security considerations”

Connection security

Section titled “Connection security”
  • Use LDAPS (LDAP over TLS) for all production LDAP connections. Unencrypted LDAP transmits credentials in cleartext on your network.
  • For Entra ID, all connections use HTTPS (Graph API).
  • LDAP bind credentials (the service account Mideye uses to search the directory) are stored encrypted on the Mideye Server.

Minimal permissions

Section titled “Minimal permissions”

Mideye’s LDAP service account needs read-only access to user attributes: name, phone number, email, group memberships. It does not need write access unless you use the Assisted Password Reset feature (which changes passwords in AD).

Directory data stays local

Section titled “Directory data stays local”

LDAP queries travel between your Mideye Server and your directory server — both on your network. Directory data is never sent to Mideye Switch or Mideye Cloud. See Data Residency for a complete data flow analysis.

Next steps

Section titled “Next steps”