FortiAuthenticator Single Sign-On in Dubai, UAE
FortiAuthenticator Single Sign-On helps organisations make network access decisions with real user identity instead of relying only on IP addresses. In Fortinet environments, it can collect or receive authentication information, associate users with groups, and provide identity context to FortiGate so security policies can be applied more transparently.
Before requesting a quote
Share the identity source, approximate user count, FortiGate estate, desired authentication method, branch locations, remote-user needs and whether a new FortiAuthenticator appliance or VM is part of the project.
Licensing, concurrent-session capacity, SSO Mobility Agent requirements, high availability and implementation services should be confirmed as part of the design.
Direct answer for business buyers
FortiAuthenticator Single Sign-On is an identity service used to help FortiGate understand which authenticated user is associated with network activity. It is most useful for organisations that want user- or group-aware firewall policies without forcing employees to enter credentials repeatedly at the firewall. FortiAuthenticator can work with directory-based identity and several Fortinet SSO methods, with the exact method chosen according to endpoint type, directory design and network topology. Buyers should confirm the intended FortiAuthenticator platform, licensed user capacity, concurrent-session demand, FortiGate versions, identity source, high-availability design and whether FortiClient SSO Mobility Agent licensing is required before placing an order.
What the solution does
Traditional firewall rules can identify source and destination networks, applications and services, but many organisations also need policy based on the person using the connection. FortiAuthenticator Single Sign-On provides a bridge between an authentication event and network security enforcement. After a user is identified through a supported method, identity and group information can be made available to FortiGate so rules can distinguish, for example, finance users from guest users or administrators from general staff.
This does not mean every login becomes automatically trusted. The value comes from designing a reliable identity flow, mapping groups carefully and applying least-privilege policy on the FortiGate. The solution is therefore part of an identity-aware security architecture rather than a replacement for directory security, endpoint security, multifactor authentication or firewall policy design.
Who should consider it
The approach is relevant to businesses already using FortiGate and wanting more consistent user-aware access control. It can suit headquarters, distributed branches, campuses, professional offices, education environments, hospitality groups, healthcare organisations and other networks where staff identities exist in Active Directory or another supported directory and firewall rules need to follow users or groups.
It may be less suitable as a simple add-on when the identity source is poorly maintained, users frequently share accounts, endpoint addressing changes cannot be correlated reliably, or the organisation has not decided which user groups should receive which access. In those cases, directory cleanup, network segmentation and policy design may need to happen before the SSO rollout.
Business problems FortiAuthenticator SSO can help address
Repeated firewall authentication
Users may encounter captive-portal prompts or separate firewall authentication even after they have already signed into a corporate identity service. A well-designed FSSO flow can reuse an existing login signal so authorised users are recognised without unnecessary extra prompts.
Policies tied only to addresses
IP-based controls can be difficult to interpret in DHCP networks, shared VLANs and roaming environments. Identity-aware policy gives administrators another dimension for deciding who can reach applications, segments or internet categories.
Inconsistent group access
When business roles already exist in directory groups, recreating the same logic manually across firewalls adds operational work. A controlled group mapping strategy can help align firewall policy with centrally maintained identity groups.
Limited user context in logs
Network events are easier to investigate when administrators can associate an IP session with a known user. FSSO can improve identity context, although log interpretation still depends on session accuracy, endpoint behaviour and retention settings.
Core capabilities buyers should understand
Transparent identity collection
FortiAuthenticator can obtain user identity through supported SSO methods, including directory-oriented techniques and endpoint-assisted methods, so a network session can be associated with a user without a separate firewall login in suitable scenarios.
Group-aware policy context
Directory groups can be used as part of the identity mapping process, enabling FortiGate policies to distinguish users according to organisational role rather than only network location.
Multiple authentication paths
A deployment can combine methods. For example, domain users may be identified transparently while non-domain systems, guests or special cases use a portal or another authentication flow.
Integration with FortiGate
FortiAuthenticator can act as an FSSO source for FortiGate. The FortiGate then uses received user and group information in identity-based security policies according to the configuration.
FortiAuthenticator SSO fit matrix
| Requirement | Suitable when | Confirm before proceeding |
|---|---|---|
| User-aware FortiGate rules | The business wants firewall access based on authenticated users or directory groups. | Group design, policy mapping, FortiOS compatibility and session identification accuracy. |
| Active Directory environment | Corporate users authenticate against maintained domain services. | Directory reachability, polling method, service permissions, multiple domains and site topology. |
| Roaming endpoints | Identity needs to follow users as device addresses or network paths change. | Whether SSO Mobility Agent is appropriate, endpoint operating systems, FortiClient approach and add-on licensing. |
| Non-domain or guest systems | Some users cannot be identified by normal domain methods. | Portal design, user experience, guest workflow and how fallback authentication affects policy. |
| High availability | Authentication is important enough to justify resilient infrastructure. | FortiAuthenticator licensing per node, session behaviour, failover design and FortiGate connectivity. |
| Hybrid identity | The organisation combines on-premises and cloud identity or several user populations. | Identity authority, supported authentication method, group synchronisation and endpoint coverage. |
Buyer information and confirmed platform considerations
FortiAuthenticator Single Sign-On is a capability within the wider FortiAuthenticator identity and access management platform rather than a single fixed hardware SKU. The purchasing decision therefore depends on the chosen FortiAuthenticator appliance or virtual deployment, user scale and authentication method. The table below separates confirmed platform characteristics from items that must be defined for a specific project.
| Topic | FortiAuthenticator Single Sign-On / Fortinet Single Sign-On integration |
|---|---|
| Main purpose | Provide identity information that can be used for transparent, user-aware network security policy. |
| Primary Fortinet integration | FortiGate can receive FSSO user and group information from FortiAuthenticator and use it in identity-based policies. |
| Directory integration | FortiAuthenticator supports integration with third-party LDAP and Active Directory systems for identity and group information. |
| SSO methods | Method dependent. Fortinet documents approaches including AD polling, portal services and FortiClient SSO Mobility Agent in appropriate deployments. |
| FortiAuthenticator-VM licensing | Perpetual and subscription models are available. User capacity and support entitlement differ by license model and purchased package. |
| Concurrent FSSO sessions on VM | The VM user license limit also applies to concurrent FSSO sessions. Sizing should include realistic peak concurrency rather than only directory account count. |
| SSO Mobility Agent | Additional licensing is required beyond limited evaluation capacity, and the client limit is governed by the relevant FortiAuthenticator licensing constraints. |
| High availability | License and design dependent. Each FortiAuthenticator unit in an HA deployment requires suitable licensing. |
| Availability | Contact FourTeck for current UAE platform, license, subscription and lead-time options. |
SSO method, capacity and licensing must be designed together
FortiAuthenticator SSO is not one universal configuration that works identically for every user and endpoint. AD polling may be suitable for domain-centric office networks, while Mobility Agent may be selected where endpoint-based identity reporting is important. Portal authentication can act as a fallback or serve populations that are not represented by normal domain logons. Each approach has different dependencies involving endpoint operating systems, directory connectivity, credentials, network paths, ports, user experience and license capacity.
FortiAuthenticator-VM licenses are capacity based, and Fortinet documents that the licensed user limit applies to concurrent FSSO sessions. SSO Mobility Agent capacity is governed separately and may need an additional license. High-availability nodes also require appropriate licensing. A quotation should therefore identify the planned FortiAuthenticator model or VM license, expected user and session count, Mobility Agent use, support term, FortiGate integration and service scope rather than treating “SSO” as one line item.
A practical planning and deployment journey
Map the identity environment
Document domains, LDAP directories, cloud identity services, user groups, service accounts, guest populations and shared-device scenarios. Identify where the authoritative group memberships are maintained and whether users move between networks, VPNs and branch offices.
Choose the identification method
Decide which users can be recognised through directory events, which endpoints need Mobility Agent assistance, and where portal authentication is a better fallback. The design should favour accuracy and maintainability rather than simply enabling every available method.
Size platform and licenses
Estimate users, peak concurrent FSSO sessions, branch scale, FortiGate connections, high-availability requirements and any SSO Mobility Agent clients. Match these numbers to the proposed FortiAuthenticator appliance or VM license and support arrangement.
Build policy mappings
Translate directory groups into clear security-policy intent. Avoid broad groups that accidentally grant access. Define how contractors, guests, administrators and service accounts are handled and what happens when identity cannot be resolved.
Test representative users
Validate normal logon, logoff, password changes, roaming, VPN use, remote access, multi-user servers where applicable, guest access, IP changes and failover. Confirm both expected access and intentional denial for different groups.
Document and operate
Record service accounts, directory permissions, ports, FortiGate connectors, group filters, troubleshooting steps, backup procedures, license renewal dates and ownership. Identity systems need ongoing maintenance as domains and user roles change.
Transparent identification without unnecessary login prompts
A central reason businesses evaluate FortiAuthenticator Single Sign-On is to reduce the gap between “the user has already authenticated” and “the firewall still sees only an IP address.” In a domain environment, the user normally proves identity when signing in to a workstation. FSSO can use a supported mechanism to learn that event, map it to the user’s current IP address and make the information available to FortiGate. Security rules can then refer to user groups rather than requiring a separate browser prompt for every employee.
The operational benefit is strongest when authentication sources and network addressing are predictable. If a user obtains a new address, moves between interfaces, disconnects unexpectedly or works through a VPN, the identity information must still be accurate enough for policy decisions. That is why the collection method matters. Directory polling may be efficient in a conventional Windows environment, while endpoint-assisted reporting can be more appropriate when location changes are common. Fortinet’s Mobility Agent reports user, domain and interface information to FortiAuthenticator and can account for endpoint address changes, but its use introduces endpoint and license considerations.
Transparent authentication should also have a defined fallback. Non-domain laptops, guest users, kiosks and special systems may not generate the same directory events as managed workstations. FortiAuthenticator supports portal-based options that can be used where transparent identification is not available. The right design keeps the normal employee experience simple while making exceptions explicit and auditable.
Identity groups become useful only when policy design is disciplined
FSSO makes user and group information available to the network-security layer, but the business value depends on what administrators do with that information. A large directory may contain hundreds or thousands of groups created over many years. Some groups represent job roles, others application permissions, mailing lists or temporary projects. Importing broad or poorly understood groups into firewall policy can make access difficult to control and difficult to explain during an audit.
A stronger approach starts with a small number of security outcomes. The organisation might need finance staff to reach an accounting service, IT administrators to reach management networks, general employees to use normal internet access, and contractors to reach only selected systems. Those outcomes can then be mapped to carefully selected directory groups. Group membership should have an owner and a change process, because a firewall rule that trusts a directory group inherits the quality of that group’s administration.
FortiGate policy should also define what happens when a user is not identified. Some traffic may need to be denied until authentication is established, while other services such as software update infrastructure or pre-login access may need specific exceptions. The policy sequence, source networks, user groups and service objects must therefore be tested together. FourTeck can help buyers translate a high-level requirement such as “staff should not see a firewall login” into a more precise identity and policy design that can be reviewed before implementation.
This discipline is especially important in multi-branch environments. Repeating the same identity structure and group names across FortiGate devices can reduce configuration drift, but centralisation should not create one overly broad policy for all locations. Local application needs, network segmentation and regulatory requirements may justify different rules even when user identity is centralised.
Licensing and resilience affect the real SSO architecture
The FortiAuthenticator platform is available in hardware and virtual forms, and the virtual platform has licensing choices that influence procurement. Fortinet documents perpetual FortiAuthenticator-VM licensing, where base capacity can be expanded with stackable user licenses and support is purchased separately, as well as subscription licensing billed per user with support included as part of the subscription. Buyers should decide whether a capital-purchase or subscription approach fits their lifecycle and budgeting process before the bill of materials is finalised.
Capacity is not only about the number of employee accounts in a directory. For FortiAuthenticator-VM, the licensed user limit also applies to concurrent FSSO sessions. An organisation with many service accounts, test accounts or rarely used directory objects should therefore separate total directory size from the actual users that FortiAuthenticator must manage. Peak concurrency may be more important than headline employee count for an FSSO sizing exercise.
Mobility Agent introduces another dimension. Fortinet states that SSOMA licensing is purchased separately and that the maximum number of active Mobility Agent clients is constrained by the relevant licensed limits. A branch project may not need Mobility Agent at all if directory polling is reliable, while a mobile workforce may justify it. The design must identify which endpoints require this method instead of adding licenses to every user by default.
Resilience should also be considered. Authentication can become a dependency for identity-based firewall policy, so larger organisations often review high availability. Each FortiAuthenticator unit requires appropriate licensing. Failover, session synchronisation, FortiGate connection behaviour and operational testing should be part of the architecture rather than assumptions made after procurement.
Ideal business environments and use cases
Corporate office with Active Directory
Employees sign in to domain workstations and FortiGate protects internet and internal network boundaries. FSSO can help the firewall recognise staff and apply group-based rules without requiring a second sign-in. Directory health, logon-event visibility, group mapping and service permissions should be reviewed first.
Distributed branch network
A business with many FortiGate branches can use a consistent identity design so the same corporate roles are understood across locations. WAN reachability to FortiAuthenticator, resilience, latency, local fallback and central management procedures should be tested before broad rollout.
Roaming or hybrid endpoints
Users move between wired, wireless and VPN interfaces and the address associated with a workstation may change. An endpoint-assisted identity method may provide more precise updates, but buyers must confirm supported endpoint operating systems, FortiClient strategy and SSO Mobility Agent licensing.
Mixed managed and unmanaged users
Employees, contractors, guests and shared devices often need different authentication paths. Transparent methods can serve managed staff while portal authentication or another controlled workflow handles users that do not produce a normal domain logon event.
Segmented internal networks
Where FortiGate enforces access between user VLANs and application segments, identity can add context beyond source subnet. Policies can distinguish authorised business roles, but the design still needs network segmentation, least privilege and clear exception handling.
Regulated or audit-sensitive operations
User context can make policy and event review easier by showing which identity was associated with a session. It should not be treated as an audit guarantee; accurate directory records, time synchronisation, logging, retention and role administration remain essential.
Integration and operational considerations
FortiAuthenticator sits between identity sources and the network-security controls that consume identity information. That makes connectivity, naming, time synchronisation and permissions important. Directory servers must be reachable over the appropriate protocols, DNS resolution should be reliable, and service accounts used for polling or integration should have only the permissions required by the chosen method. Multi-domain or forest environments need explicit planning so group names and user identities are interpreted consistently.
On the FortiGate side, FSSO connectors, groups and policies should be designed with clear ownership. An identity record can be technically correct while the resulting policy is still too broad. Testing must therefore confirm both authentication visibility and the resulting access. Administrators should look for duplicate user mappings, stale sessions, unexpected source IP changes, group membership delays and policy order issues.
Endpoint-assisted deployments require another operational layer. FortiClient or standalone Mobility Agent software must be deployed, updated and configured to report to FortiAuthenticator. Endpoint security tooling, operating-system support and change-control procedures should be checked before deciding that Mobility Agent is the standard method for all users.
A production rollout should also define monitoring and troubleshooting responsibilities. Teams need to know whether a failed access request should first be checked in the directory, FortiAuthenticator, the endpoint agent or FortiGate policy. Clear runbooks reduce the risk of treating every identity issue as a firewall fault.
Questions buyers should resolve before ordering
List Active Directory domains, LDAP directories and any cloud identity services that must participate. Identify where group membership is managed and whether multiple domains must be resolved.
Use realistic peak numbers. FortiAuthenticator-VM licensing and FSSO session capacity are related to licensed user limits, so total directory size alone is not enough for sizing.
Separate domain workstations, roaming laptops, servers, contractors, guests and shared devices. One collection method does not need to serve every population.
Confirm the endpoint use case, supported operating systems, deployment method and additional license capacity before including SSOMA in the design.
Document sites, HA pairs, management approach and network paths to FortiAuthenticator. Branch design and failover can affect how FSSO is distributed.
Define whether traffic is denied, sent to a portal, matched by a limited fallback rule or handled through another method. This is a security-policy decision, not merely a technical default.
Procurement and evaluation checklist
✓ Confirm the exact FortiAuthenticator appliance or VM deployment.
✓ Record licensed-user and peak concurrent-session requirements.
✓ List FortiGate models, FortiOS releases and site count.
✓ Identify Active Directory, LDAP and other identity sources.
✓ Decide where AD polling, portal access or Mobility Agent is needed.
✓ Confirm SSOMA client quantity and add-on licensing where applicable.
✓ Define required directory groups and access-policy outcomes.
✓ Review high-availability and disaster-recovery requirements.
✓ Check network routes, DNS, time synchronisation and required ports.
✓ State whether installation and configuration are part of the quotation.
✓ Include testing, documentation and administrator handover needs.
✓ Confirm support term, renewal approach and regional license requirements.
How FourTeck can assist with FortiAuthenticator SSO planning
A useful SSO quotation starts with architecture, not just a part number. FourTeck can help a business document the existing FortiGate environment, directory sources, user populations, branch structure, endpoint types and required access outcomes. From there, the project can be narrowed to the FortiAuthenticator platform, user capacity, authentication methods, Mobility Agent needs, HA design and implementation scope that match the requirement.
For organisations replacing an existing FSSO Collector Agent deployment or moving from captive-portal authentication, the planning discussion can include migration sequencing and rollback. The objective is to avoid a cutover where firewall policy suddenly depends on identity information that has not been validated under normal user behaviour. A phased test with representative groups and locations is usually easier to troubleshoot than enabling user-aware policy everywhere at once.
FourTeck can also help define what belongs in the implementation scope. This may include FortiAuthenticator setup, directory integration, FortiGate connector configuration, group filters, policy assistance, endpoint-agent coordination, testing and documentation. The exact services should be agreed in the quotation, because infrastructure readiness, number of sites and customer change-control requirements can materially change the effort.
Buyers can review FourTeck security products, explore network security services and deployment assistance, or send the current identity and firewall requirement through the FourTeck project contact page.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability for the required FortiAuthenticator appliance, virtual license, SSO Mobility Agent license and associated support. Availability may vary by deployment type, user capacity, subscription or perpetual license choice, quantity, regional entitlement and vendor lead time. A complete request should include the FortiGate estate, approximate users, preferred license model and target implementation period so the proposed bill of materials can be checked before quotation.
FourTeck can coordinate requirements for Dubai, Abu Dhabi, Sharjah and Ajman within one UAE project discussion. Installation and configuration scope should be included in the quotation when required. Delivery timing, support entitlement, project scheduling and warranty handling should be confirmed in the formal commercial proposal rather than assumed from a general product page.
GCC Availability
Organisations planning FortiAuthenticator Single Sign-On across Gulf locations can use FourTeck to structure a regional requirement before procurement. The discussion can cover the identity architecture, FortiGate estate, expected users, chosen FortiAuthenticator platform, licensing model, Mobility Agent needs, high availability, configuration scope and branch rollout sequence. Projects may involve the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain or Oman, but the technical and commercial requirements should be confirmed for each destination rather than assuming one license or implementation package applies everywhere. Product availability, licensing rules, delivery schedules, service visits, project scope and vendor lead times can vary by country, model, quantity and requirement. Share the destination country, required product or virtual license, quantity, user capacity, deployment locations and expected timeline with FourTeck. For Kuwait-specific coordination, buyers can also review FourTeck technology support in Kuwait when planning the regional project.
Africa Availability
For African deployments, FourTeck can help organisations evaluate FortiAuthenticator platforms, virtual licenses, SSO Mobility Agent requirements, FortiGate integration, endpoint considerations and implementation services before a quotation is prepared. Regional planning matters because fulfilment can depend on the destination, license region, appliance or virtual model, quantity, power or infrastructure conditions, shipping arrangements, vendor lead time and local project scope. Buyers should share the destination country, identity environment, expected user count, number of FortiGate sites, preferred deployment schedule and any onsite or remote support expectations. East African projects, including Kenya and Uganda, may also need attention to connectivity between sites, remote administration, local directory design and replacement logistics. FourTeck regional information is available through FourTeck Africa technology coordination and FourTeck Kenya project guidance. Availability and service coverage should always be confirmed for the exact destination and scope.
Related options and services to consider
FortiGate identity-based policy
FSSO provides identity context, but the FortiGate policy decides what that identity can access. Policy design, group mapping and logging should be included in the same planning exercise.
FortiAuthenticator MFA
Single Sign-On improves user identification and convenience, while multifactor authentication addresses a different need: requiring stronger proof of identity. Many projects need both, but they should be designed as separate control layers.
FortiClient SSO Mobility Agent
Mobility Agent may improve identity reporting for endpoints that change addresses or move between interfaces. Compatibility, client deployment and additional licensing must be confirmed before it is selected.
Directory and group review
Poorly structured identity groups can undermine firewall policy. Reviewing directory groups, service permissions and role ownership can be valuable before enabling user-aware access at scale.
Implementation and migration support
Projects can include configuration, testing, documentation and migration from an older FSSO or captive-portal design. Scope depends on the number of sites and current architecture.
Why businesses contact FourTeck for identity-aware firewall projects
Identity integration crosses several technical areas at once: directory services, endpoint behaviour, network topology, firewall policy, licensing and operations. Buyers often know the desired outcome—such as removing repeated firewall login prompts or applying internet controls by department—but do not yet know which FortiAuthenticator size, SSO method or license structure is appropriate. FourTeck can help turn that outcome into specific questions that can be priced and implemented.
Requirement clarification can include validating the number of users and FortiGate sites, checking whether the existing directory design is suitable for polling, deciding if roaming endpoints justify Mobility Agent, identifying high-availability needs and defining how guest or non-domain users will authenticate. Bill-of-material guidance can then distinguish the FortiAuthenticator platform, support, user capacity and optional SSOMA licenses from the professional services needed for deployment.
The same process helps prevent two common procurement errors: buying too little capacity for peak sessions and buying optional components without a clear use case. A structured quotation can also identify customer responsibilities such as creating service accounts, approving directory permissions, opening required network paths, providing change windows and naming the user groups that should be mapped into firewall policy.
What buyers usually need to understand before choosing an SSO design
A common starting question is whether FortiAuthenticator Single Sign-On replaces Active Directory. It does not. Active Directory or another supported directory can remain the identity source, while FortiAuthenticator uses that information as part of the authentication and user-identification process. The practical role of FortiAuthenticator is to centralise identity services and make user context available to Fortinet security controls. That distinction matters because password policy, user lifecycle and group ownership still belong to the directory or identity platform that the organisation manages.
Another frequent decision is whether FortiAuthenticator is needed when FortiGate can use an FSSO Collector Agent. The answer depends on the broader identity architecture. A standalone Collector Agent can be suitable in some Windows-oriented designs, while FortiAuthenticator becomes attractive when the organisation wants a dedicated identity platform that can combine SSO with other authentication services and provide a central point for multiple FortiGate devices. Existing hardware, support standards, high availability and future MFA or certificate requirements can influence that choice. Buyers should compare operational ownership, not only the immediate configuration steps.
Directory polling or Mobility Agent?
Directory polling can work well when user logons are visible through domain infrastructure and workstation addresses are stable enough to correlate. Mobility Agent is more relevant when identity needs to follow a managed endpoint across changing interfaces or network locations. It reports user, domain and interface information to FortiAuthenticator, but it adds endpoint software and licensing requirements. The right choice depends on the actual user journey rather than a preference for one technology.
What about users outside the domain?
Not every user population produces a useful domain logon event. Contractors, guests, kiosks, unmanaged devices and some shared systems may need another flow. FortiAuthenticator portal services can provide a controlled login path for these cases. A mixed design is often more practical than forcing one method onto every user because the security team can keep transparent SSO for managed staff and explicit authentication for exceptions.
Buyers also ask whether FSSO improves security or merely convenience. It can contribute to stronger policy by letting FortiGate use identity and group context, but it should not be treated as a security guarantee. If a directory account is compromised, a shared account is used by several people or a stale identity-to-address mapping persists, the firewall may still apply policy to the wrong person. Strong passwords, MFA where appropriate, endpoint controls, accurate directory administration and log monitoring remain important. SSO is most effective when it is one part of a layered identity and network design.
Licensing is another area where generic answers can be misleading. FortiAuthenticator-VM supports perpetual and subscription approaches. Perpetual licensing starts with licensed capacity that can be expanded, while support services are handled separately. Subscription licensing is term based and includes support as part of the subscription. For FSSO, the VM user limit also relates to concurrent sessions. If Mobility Agent is used, its license capacity is separate. That is why a buyer should provide both user counts and endpoint-method requirements when requesting a quotation.
High availability deserves early attention when identity-based policy affects business-critical access. If users cannot be identified, the firewall may fall back to different rules or block services depending on policy design. A resilient FortiAuthenticator architecture can reduce this risk, but both licensing and session behaviour need to be engineered. Testing should include FortiAuthenticator failover, FortiGate reconnection and endpoint behaviour, not only normal authentication. The same logic applies to distributed organisations: WAN failure between a branch and the central identity service should have a documented outcome.
For quotation preparation, the most useful information is practical rather than theoretical. State how many users need SSO, how many FortiGate devices will consume identity, which directory or cloud identity services exist, whether endpoints are domain joined, whether users roam across wired, wireless and VPN connections, and whether guest users require a fallback portal. Add the desired license term, high-availability requirement and any installation, migration or documentation scope. With those inputs, FourTeck can help narrow the architecture and identify which items genuinely belong in the bill of materials.
UAE buyers should also separate product availability from project readiness. A FortiAuthenticator appliance or VM license can be quoted, but successful SSO deployment still depends on directory access, network connectivity, FortiGate configuration and change-control windows. Confirm the technical prerequisites at the same time as commercial availability so the implementation plan is based on a complete requirement rather than only a product code.
Questions that change the final design
Can FortiAuthenticator recognise users without asking them to log in again?
Yes, in supported transparent-authentication scenarios. FortiAuthenticator can learn identity through methods such as directory polling or Mobility Agent and make that information available to FortiGate. The user experience depends on the chosen method, endpoint type and whether the login event can be associated reliably with the current network address.
Does every user need the SSO Mobility Agent?
No. Mobility Agent is one method, not a mandatory component of every FSSO deployment. A conventional domain environment may use another supported method. Mobility Agent should be selected where endpoint-based reporting solves a specific problem, and its additional licensing and supported operating systems should be checked before rollout.
How should concurrent sessions be estimated?
Count the users who may have active FSSO sessions during peak business periods, then include growth and unusual patterns such as shift overlap or remote work. For FortiAuthenticator-VM, the licensed user limit also applies to concurrent FSSO sessions, so a sizing exercise should not rely only on HR headcount.
What if the business has several Active Directory domains?
The design should map each domain, trust relationship, group namespace and directory path that must be used. Multi-domain projects can work, but naming, permissions and group filtering need to be explicit so FortiGate receives consistent identity information rather than ambiguous user records.
Can SSO be used together with MFA?
Yes, but they solve different problems. SSO reduces repeated authentication and supplies identity context, while MFA strengthens the proof of identity for selected services. The architecture should identify where MFA is required and where transparent FSSO is sufficient for policy context.
What information should be included in a quotation request?
Provide the FortiGate models and locations, user count, identity source, expected SSO method, Mobility Agent quantity if applicable, FortiAuthenticator platform preference, license term, HA requirement and desired implementation services. This gives FourTeck enough context to avoid a generic quote that misses key dependencies.
Frequently asked questions
What is Fortinet Single Sign-On in FortiAuthenticator?
Fortinet Single Sign-On is a set of methods used to identify users transparently and provide that identity information to FortiGate. FortiAuthenticator can act as the SSO source and can combine directory, endpoint-assisted or portal methods depending on the environment.
Does FortiAuthenticator work with Active Directory?
Yes. Fortinet documents integration with Active Directory and LDAP for identity and group information. The exact permissions, connection method and group filters should be planned for the customer’s domain structure.
Is FortiClient SSO Mobility Agent included automatically?
No assumption should be made that Mobility Agent capacity is included for all required endpoints. Fortinet documents separate SSOMA licensing and capacity limits. Confirm the required client count and license before ordering.
Do I need a FortiAuthenticator appliance, or can I use a VM?
FortiAuthenticator is available in hardware and virtual deployments. The right option depends on user capacity, infrastructure standards, resilience, support preferences and whether the organisation wants a physical appliance or virtualised identity service.
How is FortiAuthenticator-VM licensed?
Fortinet currently documents both perpetual and subscription licensing for FortiAuthenticator-VM. Perpetual licensing uses purchased user capacity with support handled separately, while subscription licensing is term based and includes support as part of the subscription.
Can FSSO be highly available?
FortiAuthenticator supports HA scenarios, but each unit requires appropriate licensing and the deployment should be tested for session and FortiGate behaviour during failover. HA design is configuration and license dependent.
What happens to users who cannot be identified transparently?
They can be handled through a deliberately designed fallback, such as portal authentication or a separate policy, depending on the environment. Guest and non-domain users should be planned rather than left to an accidental default.
Can FourTeck configure FortiAuthenticator and FortiGate for SSO?
Configuration assistance can be included when requested. The exact scope may cover directory integration, SSO methods, FortiGate connectors, group mapping, policy support, testing and documentation. Scope should be confirmed in the quotation.
Is FortiAuthenticator Single Sign-On available in Dubai?
Contact FourTeck to confirm current UAE availability for the required FortiAuthenticator platform and licenses. Lead time and entitlement may depend on deployment type, user capacity, quantity, license term and regional conditions.
What should I send FourTeck for an accurate quote?
Send the user count, FortiGate models and sites, identity source, expected SSO method, Mobility Agent requirement, platform preference, license term, HA needs and desired implementation scope. Existing network diagrams are helpful for multi-site projects.
Plan the FortiAuthenticator SSO requirement before choosing licenses
Share your directory environment, FortiGate estate, user count, preferred authentication flow, Mobility Agent needs and project scope. FourTeck can help review the architecture, identify platform and licensing dependencies, and prepare a UAE quotation aligned with the actual deployment.