Skip to main content
Grasmuis
Grasmuis
New Member
August 18, 2017
Question

FSSO Advanced with DC Agents - Is there a way to track IP changes

  • August 18, 2017
  • 3 replies
  • 41706 views

Hi All

 

I have a customer with Advanced FSSO and DC Agents, all seem to be working fine. Some of their users switch between LAN and WiFi without logging out of their system - picking their laptop up and walking to a different building and into a different subnet. Subsequently the FSSO loses the AD Account and IP pairing and naturally their traffic is marked as 'Guest' (valid internal IP, no authentication as source).

 

They are not using the FortiAPs.

 

What are my options in getting their browsing to work seamlessly when moving between LAN and WiFi subnets?

 

Edit: Just as an added note here, I've read other threads from years ago that refer to enabling NTLM, DNS or DHCP tweaks, etc. Are these solutions still valid? Would the FSSO software not been updated since then? Is there a more recent thread that discusses this issue?

 

Any pointers-in-the-right-directions are appreciated!

    3 replies

    Allan_Lago
    Allan_Lago
    New Member
    September 5, 2017

    Hello Grasmuis!

     

    Is your DHCP service running on a Windows Server integrated withe your local domain? If yes, the FSSo should be receiving the ip change information trought the updates your DHCP do on your AD DNS.

     

    If you need to enable NTLM you must do so trought the CLI editing the firewall rules withe the FSSO groups.

     

    config firewall policy edit policy_id set ntlm enable end

     

    Enable the debug level in the FSSO Collector in order to find out more information that can help us come to a better conclusion.

     

     

    Grasmuis
    GrasmuisAuthor
    New Member
    September 5, 2017

    Hi Alago

     

    I've done some more research on the matter since my post, but I'm still getting the same issue.

     

    I did enable NTLM on all the policies containing the FSSO groups.

     

    According to the customer, whether they switch between wireless or wired connection, they are always able to ping the DNS entry (unsure whether this refers to the PC name or the AD Account). So it seem that, on their end at least, the DNS is updated when the workstation switches between wired and wireless IPs.

     

    I should also mention that, with the workstation only using either wired or wireless, with the other disabled completely, everything is working fine. It's only on those workstations where users switch between the two mediums.

     

    I might be asking this question incorrectly, but : What do people mean when they talk about the DNS entry that DHCP generates, is it the PC name, or the AD Account name that gets a DNS entry? And, is this the only thing that the FSSO needs to update the "logon user" list if a change happens?

    Agent_1994
    Agent_1994
    New Member
    September 5, 2017

    JacquesSA wrote:

     

    I might be asking this question incorrectly, but : What do people mean when they talk about the DNS entry that DHCP generates, is it the PC name, or the AD Account name that gets a DNS entry? And, is this the only thing that the FSSO needs to update the "logon user" list if a change happens?

    FSSO knows the workstation name and every 60 seconds (default) will look it up to see if the IP changed.

    In theory, the switch from wifi to wired -and viceversa- should be seen within 60 seconds.

     

    The thing about Windows DHCP + DNS is that the workstation should register itself on the DNS server vía a dynamic update. If it does that, the owner of the DNS record is the workstation (just like when you create a file and you're it's owner). Windows DHCP server has the option of registering DNS records on behalf of the workstation when it doesn't support dynamic updates... or it can always do that if you configure it to do so.

     

     Then... let's say that the DHCP on "segment A" registered the record on behalf of the workstation, then you switch to "segment B" where the workstation register themselves on DNS... they wont be able because the DNS record is owned by the DHCP server.

     

     If you can see the IP change when do yo nslookup from the collector, it should be working.

    romanr
    romanr
    New Member
    September 12, 2017

    JacquesSA wrote:

     Some of their users switch between LAN and WiFi without logging out of their system - picking their laptop up and walking to a different building and into a different subnet.

    Hey,

     

    my 2 cents: the only way to really reliable handle this is to use the SSO Agents on the clients and the FAC which will reult in additional licensing costs...

     

     

    Br,

    Roman

    dmcquade
    dmcquade
    New Member
    January 10, 2018

    We've had the same issue. In our case we use FortiAuthenticator and have FortiClient installed on the workstations and laptops. We changed our configuration to add the Forticlient SSO Mobility Agent in addition to the DC Agents. Machines using FortiClient can roam freely and have their IP address update in real time thereby giving them access to all of their group specific access rules.

    romanr
    romanr
    New Member
    January 10, 2018

    Hey,

     

    as long as the PC does not trigger any new login event in the windows world, after the IP address change -> Then any active directory method will not know about the changed ip address. This is due to Active Directory design and the only thing Fortinet can do about it -> Is provide a client based solution, which is there via FortiAuthenticator and SSO agents...

     

    If it is only for clients and web-access. Another smart solution can be using Explicit Proxy and Kerberos (or NTLM) Authentication. But this isn't an easy solution and will bring up other issues.

     

    Br,

    Roman

    neonbit
    neonbit
    New Member
    January 10, 2018

    Does your wireless vendor allow you to send RADIUS attributes? Ifso you could get it to send the user info each time a user logs into the wifi.

    Terms & ConditionsAccessibility statement