FSSO - Wireless <--> LAN

[Robert_White]

I have a policy set to allow the marketing AD group to access social networking sites, the next entry is set to block. Everything works as expected, until the user un-docks the laptop and moves to the wireless network. Under the wireless network it is blocked for the user under the marketing AD group. I look under "Show Logon Users" it shows the username and workstation associated to the LAN IP address and not the updated IP address, can we set to ignore the IP? If i do a "ipconfig /registerdns" and wait 60 seconds the list is updated and it woks as expected. This will be an issue if we have to do this every time they move between subnets (LAN/Wireless). Also this will cause an issue when we run a report based on a username. 

More Info: 

[ul]

200D running 5.2.3

AD/DNS Server = 2008r2 

DC Agent Mode (Each AD server is set and working)[/ul]

Thanks! 

[Robert_White]

Anyone? 

[Sylvia]

Hey Robert,

no, I don't think that you can ignore the IP. That's how User Authentication works: IP <->User.

You should make sure that the DNS server is automatically updated with the new IP, once the user has changed from wired to wireless network.

Alternatively you can make use of the FSSO guest users for those users who has received a new IP. So that this group will get limited internet access at least.

Sylvia

[Robert_White]

They already have 2 DNS entries for the same host. One for the wireless and one for the LAN. I understand how it works it just causes an issue and was looking for a work around. Has anyone else have the same issue. Another issue I came across is if a user logs into a workstation at the desk and then sign onto a thin client in the exam room it doesn't pick up the correct user information. 

[xsilver_FTNT]

Hello,

from mentioned DCAgent mode I assume you have Collector somewhere and so we are talking about FSSO.

- Collector by default does use DNS from underlying MS OS, so check that mentioned 2 IP for WKS are resolvable from WKS name ON that underlying server where Collector is installed.

- if needed/suitable, you can specify alternative DNS servers in Collector GUI Advanced settings

- also check that Collector does have "IP address change verify interval" set >0 so it WILL check for additional IP or IP changes made in DNS, in registry it's "DNSlookupinterval"=dword:00000002 in [HKEY_LOCAL_MACHINE\software\fortinet\fsae\collectoragent]

Those should help. Collector is able to handle multiple IP addresses as source IP for a single user.

Kind regards, Tomas

[Iratxe]

Hi,

I'm facing the same issue.

Our FSSO Collector (we don't have DCAgent) doesn't update the ip changes. I think that the problem is that he doesn't know all workstation names. Some entries have IP in IP address column and device name in workstation name. Others have ip address in both, address column and Workstation name.

How does the FSSO know the workstation name?

I have seen the AD Event 4624 and the field workstation name is blank. But, there are some entries in the FSSO Collector that have workstation name and in the corresponding AD Event the filed is blank.

Kind Regards,

Iratxe

[hklb]

Hi,

it is recommended to use MSSO (mobility agent sso, aka Forticlient SSO). A FAC a required to use that, but it is the best way to have an up to date information.

Lucas

[xsilver_FTNT]

Collector knows IP and name from multiple sources.

Primary source is event. Especially in polling modes. However some events like 4624 do not contain workstation name anymore, while older events like 680 672 contained workstation name only and no IP.

Secondary source is DNS. And FSSO depends on accurate and working DNS heavily. So IP can be derived from workstation name and verified from IP. Additional events spotted can contribute to precision of the records.

IP updates are by default NOT performed, so Collector learns new IPs from new events.

But it could be changed via registry key "verifyIP". So new DNS lookup will be done periodically and IPs updated.

Single workstation can have multiple IPs, but make sure that your DNS is updating A/AAA records accordingly and not just overwriting a single A record. That could be avoided by proper DNS setup or by workstations being allowed to update all their NICs IP addresses into DNS (by default MSFT workstations are trying to do so and DNS prevents that).

Alternative way is mentioned agent on workstation. Called SSOMA (Single Sign-On Mobility Agent) but it requires FortiAuthenticator as Collector and peer to work with.

Windows EventIDs used in WinSec Poling

https://kb.fortinet.com/k...amp;externalId=FD36424

[xsilver_FTNT]

More on Dual NIC issue summarized and posted into KB here: https://kb.fortinet.com/k...amp;externalId=FD50329