Skip to main content
austinmas1987
austinmas1987
Visitor III
March 10, 2026
Question

FortiAuthenticator SmartConnect with LDAP users for BOTH domain-joined + BYOD – architecture questio

  • March 10, 2026
  • 4 replies
  • 215 views

I’m designing a FortiAuthenticator EAP TLS setup where the user base is LDAP (Active Directory), supporting two types of endpoints:

 

Domain-joined laptops (already managed) , certificates already present on the user device.

BYOD devices (user-owned)

 

Both need to authenticate via EAP-TLS for Wi-Fi (802.1X) using FortiGate + FortiAuthenticator.

 

Current setup:

Domain-joined devices:

Certificates pushed via GPO from internal PKI

EAP-TLS with certificate binding is already working

Username is derived from the certificate CN and mapped to LDAP

EAP -TLS for domain joined devices is working. And I am also able to assign dynamic vlans via radius attributes configured in the FAC user group.

 

BYOD devices:

Will be onboarded via SmartConnect

Authentication to LDAP is required first

Certificates will be issued to the device so it can use EAP-TLS

 

Questions:

For BYOD onboarding, is it better to use a local CA on FortiAuthenticator, or should I issue certificates from the LDAP/AD CA via SCEP for BYOD devices as well?

 

Regarding realm design: should I use a single realm for both domain-joined and BYOD users, or create separate realms for BYOD (e.g., byod.domain.lab) while keeping the same LDAP backend?

 

In the RADIUS policy: can a single policy handle both domain-joined and BYOD devices, or is it necessary to configure two separate policies to differentiate the flows?

 

Any best-practice architecture examples for supporting LDAP users on both domain-joined and BYOD devices with EAP-TLS, using FortiGate + FortiAuthenticator?

 

Looking for guidance from anyone who has implemented a clean BYOD + domain-joined EAP-TLS workflow in production.

4 replies

Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
March 12, 2026

Hello austinmas1987, 

 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Jean-Philippe - Fortinet Community Team
Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
March 16, 2026

Hello,

 

We are still looking for an answer to your question.

 

We will come back to you ASAP.

Jean-Philippe - Fortinet Community Team
Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
March 17, 2026

Hello again austinmas1987,

 

I found this solution, can you tell us if it helps, please?

 

BYOD Onboarding: Local CA vs. LDAP/AD CA

For BYOD devices, you have two options for issuing certificates:

  1. Local CA on FortiAuthenticator:

    • Pros: Simplifies the certificate management process as FortiAuthenticator can directly issue and manage certificates. This is particularly useful if you want to keep the BYOD certificate management separate from your domain-joined devices.
    • Cons: Requires managing a separate CA infrastructure, which might add complexity if not properly integrated with existing systems.

  2. LDAP/AD CA via SCEP:

    • Pros: Maintains a unified certificate management system across both domain-joined and BYOD devices, leveraging existing AD CA infrastructure.
    • Cons: May require additional configuration to ensure SCEP is properly set up and accessible for BYOD devices.

Realm Design

  • Single Realm:

    • Pros: Simplifies management by having a unified configuration for both domain-joined and BYOD users.
    • Cons: May complicate policy differentiation if specific settings are needed for each user type.

  • Separate Realms:

    • Pros: Allows for more granular control and customization of policies and settings for each user type.
    • Cons: Increases complexity in configuration and management.

RADIUS Policy Configuration

  • Single Policy:

    • Pros: Simplifies management by having a unified policy for both device types.
    • Cons: May require complex attribute matching to differentiate between domain-joined and BYOD devices.

  • Separate Policies:

    • Pros: Allows for clear differentiation and customization of authentication flows for each device type.
    • Cons: Increases the number of policies to manage.

Best-Practice Architecture Examples

While specific architecture examples are not provided in the context, here are some general best practices:

  1. Certificate Management: Ensure that your certificate issuance and renewal processes are automated and integrated with your existing infrastructure to minimize manual intervention.

  2. Policy Differentiation: Use RADIUS attributes and realms to clearly differentiate between domain-joined and BYOD devices, allowing for tailored authentication and authorization policies.

  3. Security: Implement strong security measures, such as certificate revocation and regular audits, to ensure the integrity of your EAP-TLS setup.

  4. User Experience: Ensure that the onboarding process for BYOD devices is user-friendly and provides clear instructions to minimize user errors and support requests.

Follow-ups and Clarification Questions

  • Would you like more detailed guidance on setting up a Local CA on FortiAuthenticator?
  • Are there specific challenges you are facing with your current setup that need addressing?
  • Do you need assistance with configuring RADIUS policies for dynamic VLAN assignment?
Jean-Philippe - Fortinet Community Team
austinmas1987
austinmas1987Author
Visitor III
May 20, 2026

Hi,

Thanks for your previous response and guidance on the BYOD + domain-joined EAP-TLS architecture options.

I wanted to share a more detailed view of the issue we are currently facing in production testing, and also clarify why we are attempting to use the MAC-based SmartConnect option.

Current Requirement / Design Intent

We are implementing a FortiAuthenticator-based 802.1X EAP-TLS deployment supporting two device types:

  • Domain-joined Windows devices
    • Certificates issued via AD CS (GPO-based auto-enrollment)
    • Already working successfully with EAP-TLS and dynamic VLAN assignment
  • BYOD devices (Windows / Android / iOS)
    • Onboarded via FortiAuthenticator SmartConnect portal
    • Certificates issued from FortiAuthenticator local CA

The requirement is that:

  • A single LDAP user (Active Directory account) must be able to register and use multiple BYOD devices simultaneously
  • Each device must have its own unique certificate for EAP-TLS authentication

Issue with Current Username-Based SmartConnect Design

Initially, SmartConnect was configured with:

  • Client Certificate Common Name (CN) = Username (sAMAccountName)

This works for single-device scenarios, but in our environment it causes a critical limitation:

  • When the same user attempts to enroll a second BYOD device, SmartConnect attempts to issue another certificate with the same CN
  • This leads to certificate binding conflicts within FortiAuthenticator
  • The SmartConnect workflow fails or behaves inconsistently
  • In some cases, previously issued certificates must be manually deleted for re-enrollment to succeed (not viable for production)

This effectively enforces a “one certificate per user” limitation, which does not scale for BYOD use cases.

Attempted Fix: MAC-Based CN Option

To resolve the above limitation, we tested the SmartConnect option:

  • Client Certificate Common Name (CN) = MAC Device

The intent is to shift from:

  • User-based identity (CN=username)
    to:
  • Device-based identity (CN=MAC address)

This should theoretically allow:

  • Multiple devices per user
  • Unique certificate per device
  • No CN collision

Problem Encountered (Critical)

When enabling MAC Device in SmartConnect, the enrollment process fails.

Observed behaviour:

  • User successfully authenticates to SmartConnect portal
  • Certificate issuance begins
  • FortiAuthenticator returns HTTP 500 Internal Server Error
  • Certificate is not generated

From analysis of logs and behaviour, the issue appears to be:

  • The MAC address is not consistently available in the SmartConnect enrollment session context
  • As a result, the CN field cannot be populated
  • This leads to backend failure during certificate generation

We suspect this is because:

  • The MAC address is expected from RADIUS/NAS session context (Calling-Station-ID)
  • But SmartConnect portal authentication does not always have access to this attribute depending on the authentication flow (especially in BYOD web-based onboarding scenarios)

Key Concern

We are unable to find a clear end-to-end implementation guide that explains:

  • Required conditions for MAC-based SmartConnect CN to function correctly
  • Whether MAC must be explicitly supplied via captive portal session vs automatically retrieved via RADIUS
  • Required NAS/AP configuration (we are using non-FortiGate AP infrastructure)
  • Exact dependency chain for MAC availability during certificate issuance

Most documentation only describes feature configuration, but not the full working architecture or prerequisites.

Question / Request for Guidance

Could you please confirm:

  1. Is there a known working reference architecture for SmartConnect using:
    • CN = MAC Device
    • EAP-TLS authentication with FortiAuthenticator
    • BYOD onboarding via captive portal / SmartConnect
  2. In your experience, should the MAC address be:
    • Passed from NAS (RADIUS Calling-Station-ID), OR
    • Explicitly captured during portal authentication, OR
    • Derived from another mechanism?
  3. Are there known limitations where SmartConnect MAC-based CN will fail depending on the NAS vendor (e.g. non-FortiAP environments)?
  4. Do you have a validated working example or implementation guide that covers this scenario end-to-end?

We are trying to avoid the workaround of manually deleting certificates per user/device, as this is not scalable for production BYOD environments.

Any guidance or a reference working design would be highly appreciated.

Thanks again for your support.

Best regards,
Austin

Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
May 20, 2026

Hello again Austin!

 

I found these answers to your questions, tell me if it helps:

 

Current Requirement and Design Intent

You are implementing a FortiAuthenticator-based 802.1X EAP-TLS deployment for two types of devices:

  1. Domain-Joined Windows Devices:

    • Certificates issued via AD CS (GPO-based auto-enrollment).
    • Successfully working with EAP-TLS and dynamic VLAN assignment.

  2. BYOD Devices (Windows/Android/iOS):

    • Onboarded via FortiAuthenticator SmartConnect portal.
    • Certificates issued from FortiAuthenticator local CA.
    • Requirement for a single LDAP user to register and use multiple BYOD devices simultaneously, with each device having its own unique certificate for EAP-TLS authentication.

Issue with Current Username-Based SmartConnect Design

  • Problem: Using the username (sAMAccountName) as the CN causes conflicts when a user enrolls multiple devices, leading to certificate binding conflicts.
  • Attempted Fix: Switching to a MAC-based CN to allow multiple devices per user with unique certificates per device.

Problem Encountered with MAC-Based CN Option

  • Observed Behavior: Enrollment fails with an HTTP 500 Internal Server Error during certificate issuance.
  • Suspected Cause: The MAC address is not consistently available in the SmartConnect enrollment session context, leading to backend failure during certificate generation.

Key Concerns

  • Lack of clear implementation guidance for MAC-based SmartConnect CN.
  • Uncertainty about the conditions required for MAC-based CN to function correctly.
  • Need for clarification on NAS/AP configuration and MAC address availability during certificate issuance.

Questions and Guidance Request

  1. Reference Architecture for SmartConnect Using CN = MAC Device:

    • Unfortunately, there is no specific reference architecture provided in the available documentation for using CN = MAC Device with SmartConnect and EAP-TLS authentication.

  2. MAC Address Handling:

    • The MAC address should ideally be passed from the NAS (RADIUS Calling-Station-ID). However, if the NAS does not provide this, it may need to be explicitly captured during portal authentication.

  3. Limitations with Non-FortiAP Environments:

    • There may be limitations depending on the NAS vendor, especially if the NAS does not provide the MAC address in the expected format or context.

  4. Validated Working Example or Implementation Guide:

    • Sorry, I do not know of a validated working example or implementation guide that covers this scenario end-to-end.

Follow-Ups and Clarification Questions

  • Have you verified the NAS/AP configuration to ensure it is correctly passing the MAC address in the RADIUS Calling-Station-ID?
  • Is there a possibility to test with a FortiAP to see if the issue persists, which could help isolate whether the problem is vendor-specific?
  • Would it be possible to engage with Fortinet support for a deeper dive into the logs and configuration to identify any overlooked settings or requirements?

These steps might help in identifying the root cause and finding a viable solution for your deployment scenario.

Jean-Philippe - Fortinet Community Team
Terms & ConditionsAccessibility statement