I've got a strange problem that crops up. I think the issue is that people get a new ip address without re-logging on and the FSSO/fortigate gets confused.
Situation:
multiple sites, different subnet on each site. Windows laptops, Aruba wireless, Fortigate with FSSO authenticated AD groups, Fortigate policies based on AD groups.
Person logs into their windows laptop at site A, successfully connects to internet through Fortigate. Closes the lid, drives to site B, opens the lid (gets a new IP address from DHCP.) After coming out of sleep, the laptop has internal network access (i.e. to local file servers) but nothing through the Fortigate. The Fortigate logs show an unauthenticated person at the new IP address trying to get through. I always have to tell them to reboot the laptop and then all is ok.
I have the "IP address change verify interval (seconds)" set to 60 in the Single Sign On Agent config screen even though I doubt it is needed because the documentation states "FSAE periodically checks the IP addresses of logged-in users and updates the FortiGate unit when user IP addresses change. This does not apply to users authenticated through NTLM. "
Is this a FSSO limitation or some kind of configuration error on my part? difficult to diagnose I know with such limited info but I would appreciate any pointers I could get.
Mark
Hi,
I'm facing the same issue. Have you solve this?
Regards,
Iratxe
Did you every find a solution to this? We have installed FortiGates at all our location and we are experience the same issue.
any one managed to solve this issue ?
There was nothing that we could do on our FortiGates to fix it. The work around for us was to create a custom script that runs gpupdate every time the laptop detects a network change.
The only way we were able to get around it was purchase FortiAuthenticator and use the FortiClient SSO mobility agent.
can you post configuration sample from fortiauthenticator if it solved your problem ?
FSSO uses several methods to determine if a users IP address has changed or is still in use. All rely on your AD playing well.
The likely suspect here is that your local DNS is not being updated correctly, and the server where the collector agent is installed is running a reverse DNS query for the hostname of the users computer. This is usually the IP that will be used in the collector agent. As long as that entry is valid and has not been overwritten it will continue to report this IP.
Other methods used are with the remote registry server, however this is primarily used to verify if the user is still actively logged on to the system.
Essentially, you would want the user to at least re-login while connected to the network of the other site. This will cause an event log to be generated or in Agent mode, a Kerberos event which will be captured by the collector agent.
Assuming from your question that you have a single domain spreading multiple sites, we would need to ensure that all log and event replication is working efficiently between your DCs, and that all collector agents, if running multiple, all show the same data.
Can you please tell which mode you are using, Is it polling mode or colector agent.?
Check the dead entry timeout interval on the dc agent and see if the if the workstation is creating an event when the Ip is changed
ref doc:
The reboot of the PC will trigger another logon even and user is able to access the resources for another 8 hours
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1740 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.