No fingerprint data found for rule. Grace period has not expired. Putting back on queue

[KDalbjerg]

Hi

Iam trying to use a Device Profillin Rules, to match our doamin computers to a group.
We are using the base license.
So I have installed  persistent agent on all clients. 

And the look at if there are in the correct domain name.
But when doring a test on the host, connected with peristent agent i now get:
No fingerprint data found for rule. Grace period has not expired. Putting back on queue
What does this mean?

If i remove the Windows Profile, it works, but then i do not match if it our domain name. :)

[KDalbjerg]

If the FortiNac is not posible to connect to the clients with WinRM, this error is given. 
But i have tested the winrm, from the CLI, and it connected.
But still I got this error message ind the FortiNac GUI, when test the profile on the client 

[ebilcari]

Is Persistent Agent able to communicate with FNAC? There are some extra steps to be configured in order for the Agent to find and communicate with FNAC. You can refer to PA deployment guide or this article that shows the SRV records.
WinRM is considered an active method of profiling so an IP for the end host is needed for the profiling process to start (Needs to Be Read), you can read more about this here  

The error you are facing means that the device was not able to be profiled, be careful also with Rule ordering, always leave rules with DHCP at the bottom, otherwise it will catch the hosts and in case there is no DHCP fingerprinting available for that host, FNAC will stop the evaluation of other rules for that host.

[KDalbjerg]

Hi ebilcari

Thanks for you reply. the agent are able to communicate with the fortinac on port Port: TCP 4568
If i manuel register the host, i can afterwards perform a test of this profile just fine.
So you might be right that the FortiNac, for some reason can't see the mac address of the host.

But why does it not get the IP address?

[Sheikh]

Hi @KDalbjerg 

Are you also using 802.1x auto registration. Keep this in mind that in some scenarios 802.1x takes precedence in the hosts registration and process faster then DPR. Moreover, please also check that Isolation vlans are pointing towards FNAC Eth1 and the DHCP relay (IP Helper address) is configured in VLAN settings on a network switch.

To check why the client machines are not getting an IP from FNAC DHCP scopes, you can run following tcpdump commands and check the output. This will give you some insights that whether the DHCP requests are coming to FortiNAC

 tcpdump -nnvvi eth1 port 67 or port 68 -w /tmp/DHCP.pcap

grep -i "<mac address of host using colons>" /bsc/logs/dhcpd.log

regards,

Sheikh

[KDalbjerg]

No we are not using 802.1x yet.

And we also not have set computer to be in FNAC Isolation vlans, becuase we are just implementing FortiNac, and need the devices to be in the correct groups, before putting rogue computers into Isolation vlans

[ebilcari]

The MAC address is always learned (from L2 devices) since that is the information that triggers the actions in FNAC for every host status. The IP of the host need to be learned in the second phase from a L3 device where the gateway of this hosts resides (network device's ARP table). If that network device is not added in FNAC, you should add it. FNAC needs full visibility L2/L3 to verify the hosts.

[KDalbjerg]

We have added Fortigate to our FNac, and though that all our FortiSwitch are added.

So L3 gateway address is added.

[ebilcari]

Try to repeat a registration but after the rouge is connected do a manual L3 poll on FGT and run Device profiling again, if it bring any change.

In case you need better visibility than you have to enable the debugs:

Run this commands from FNAC CLI:

> nacdebug -name DpcRuleServer true

> nacdebug -name ActiveFingerprint true

> nacdebug -name DeviceTypeManager true

Open two SSH session to the FortiNAC and gather the output of the following commands:

> logs

> tf output.master | egrep -i "84-00-00 | 84:00:00"

> tf output.nessus | egrep -i "84-00-00 | 84:00:00"

Change this value "84:00:00" with the 3 last octets of the client mac address that you are trying to profile. Try to find any reason or complains

After that disable debugging:

> nacdebug -name DpcRuleServer

> nacdebug -name ActiveFingerprint

> nacdebug -name DeviceTypeManager

[KDalbjerg]

That might be a issue there. I have not configued L3 polling. DOH!.

Set this up now, and now one host is put into the group, but not other.

There do now have IPs address in the view, so its not the missing IP address.


I don't get any logs when remove the clients, and readd it again by restarting the service, with the commands you send me.