FortiNAC Group ync

FortiNAC is most likely reporting correctly here, and the fault is upstream. Two separate things are stacked, and the poster is staring at the wrong one.

The probable root cause is the Entra-to-LDAP plumbing, not FortiNAC. FortiNAC speaks LDAP, and cloud Entra ID has no native LDAP endpoint. So whatever FortiNAC binds to is either Entra Domain Services or, more commonly, on-prem AD that Entra writes down into. If it's the on-prem AD path via group writeback / cloud sync, Microsoft's own documented behavior bites you: cloud-only Entra users are not synced into on-prem AD as group members, because provisioning does not do user writeback, and a nested security group is written back as the group object only, not its members. Those users would need an onPremisesObjectIdentifier matching an objectGUID in the target AD to appear. So if user1 was created cloud-only in Entra, the IT group in AD may simply have no member entry for them, and FortiNAC then reads an empty membership and shows exactly what you see.

Check the source of truth before touching FortiNAC: query the actual LDAP endpoint FortiNAC points at (ldapsearch, or AD Users and Computers) and look at the IT group's member attribute. If user1 isn't listed there, FortiNAC is right and the fix lives in the Entra sync, not in FortiNAC.

Second, even with membership correct at the source, FortiNAC won't reflect it in real time, and won't show users it hasn't learned. Two documented behaviors:

• Sync is scheduled, not live. After group changes you run System > Scheduler > Synchronize Users with Directory and select Run Now to import the group. Adding a user in Entra and immediately checking Remote Groups shows stale data until a resync runs.
• LDAP sync does not automatically create a record for every user in the directory; a user who has never attempted to log in will not show up in FortiNAC. The record materializes on first authentication/registration. So the Remote Group member list reflects users FortiNAC already knows, not a live enumeration of the directory group.

Diagnostic order:

1. Confirm user1 is actually a member of IT at the LDAP source FortiNAC reads. This is where it usually breaks, and it points back at Entra writeback.
2. If they are, run a manual sync (Scheduler > Run Now), and confirm the group is in Selected Groups and user1 falls within the configured user search branch.
3. Don't expect a brand-new, never-authenticated user to populate the group until they authenticate or a user sync pulls them in.

One more to rule out: the domain/primary users group can't be used for this, because FortiNAC does not populate user details for that group during a directory synchronization. If IT membership is only inherited via the primary group, it won't sync. Use an explicit security group.

Bottom line: an empty Remote Group is almost always an upstream problem. Verify the LDAP source first. If user1 isn't there, it's an Entra cloud-only / writeback issue, and no amount of FortiNAC resyncing will fix it.

I didn’t test it on Entra ID, but in case it is like AD then probably it is synchronization related. 

To make it sync immediately, go to System > Schedule, and run the synchronization of AD / Entra ID.

You should be able to change the sync period as well. I think default is 24h if I’m not wrong, you can reduce it for example to 1 or 2h.

Does the group remain empty even after a Sync or Poll is triggered in the Service connector as shown here: https://docs.fortinet.com/document/fortinac-f/7.6.5/microsoft-entra-id-authentication-cookbook/591614/configuration-on-fortinac-through-service-connector

If we add some user to the entra group IT then on fortinac the user will have same group right?

I was try add 23 users to the group IT then when random users conenct to the network the result is some of 23 user have successfull connect to the network and some users pass thru the captive portal.

Seem user which redirected to the captive portal, the nac not see this user is member of group IT