Skip to main content
rtlucht1978
rtlucht1978
New Member
July 19, 2021
Solved

Poll Active Directory server

  • July 19, 2021
  • 1 reply
  • 14882 views

Our AD is hardened and our service accounts are limited in what they can do.  I have a service account that I am attempting to poll active directory groups for usernames.  Currently my service account can query ldap and view event logs.  What other permissions would I need the service account to have.  Currently I have a red arrow on my active domain controller.

 

Our domain controllers are up to date and our Fortimanager is version 6.4.3 build 2201.

 

The connector does get a green arrow if we use domain admin credentials.

 

thank you

Best answer by xsilver_FTNT

Hi Bilel,

unfortunately the pictures were not attached well.

 

However, for example my lab FortiOS 6.4.5 shows two possibilities in Security Fabric / External Connectors / New External Connector / "Endpoint/Identity" section.

1. FSSO Agent on Windows AD

2. Poll Active Directory Server

 

Those two are directly related to FSSO.

First "FSSO Agent on Windows AD" will point FGT to external, standalone, Collector Agent. Which can be installed on DC, or on any domain member Windows server class machine. And which, besides other modes, can poll Windows Security log, or query WMI for Windows Security events and specifically for those user logon related ones. That second method referred in Collector Agent as WinSec-WMI is what I would recommend to use. As it will gather just logon events directly via WMI, and relief Collector from extra burden when pure WinSec log is sequentially read and then parsed for just few suitable logon events while majority of collected data are "garbage" for FSSO purpose.

Second, "Poll Active Directory Server" will make FGT to do similar job as Collector does. Polling DCs for logon events. But it is less favorite method for me as it lacks versatility of standalone Collector Agent and brings extra load on FGT side.

 

If you can not keep WinSec logs, and WMI will not be enough to keep up speed in which your system destroys the evidence, then there is supposed to be MSFT way to duplicate logs to external WinSec log collector. But I never configured it, just hit that as some customers has standalone Collector Agent set to read WinSec logs not from all the DCs but from that single MSFT collector only. But I have little details on how it's made on MSFT side.

 

Alternatively, in standalone Collector Agent, or directly on FGT side in External Connectors, there is "RADIUS Single Sign-On Agent" .. sometimes referred simply as RSSO. Which is method where collector (no matter if standalone Collector or FGT in that role) learns logons events from provided RADIUS Accounting Start/Stop/Update messages. So for example if your users are authenticated via NPS, for example to WiFi, then NPS or wireless controller (WLC), should be able to send Accounting Requests to collector (again, standalone Collector Agent, or FGT in that role, or even FortiAuthenticator, which is probably not your case and I noted FortiAuthenticator just to complete listing of possible recipients).

 

1 reply

xsilver_FTNT
Staff
xsilver_FTNT
Staff
August 2, 2021

From your comment I'm not sure if you do poll directly from FGT or you are using standalone Collector Agent. And more precisely how do you gather logon events (DCAgents, Polling and which one, Advanced/Standard mode on Collector) ... 

However I would suggest to check this KB on 'Restricting FSSO service account'

https://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD36039

 

For more than few users my favorite setup is standalone Collector Agent polling WinSec+WMI. Two of those Collectors run on DCs for independent and resilient setup, used in a single SSO Connector on FGT side. If more than single FGT is used and same user groups are supposed to be used, then Group Filter defined as Global/Default directly on Collector and so read from FGT. Instead of  filter pushed from every single FGT to Colelctor as that setup is then prone to errors on FGT admin side. FMG might eliminate that.

Bilel
Bilel
New Member
August 4, 2021

Dear,

 

@ xsilver_FTNT. I read your posts and I appreciate your participation 

I have the same issue with a Fortigate101E running FortiOS 6.4.6.

I'm working on a POC to deploy FSSO in order to explore NG functionality 

As you said, our system department didn't agree to install agent on DCs so we've Installed a windows machine for the collector agent 5.0.0297 with Advanced access information with polling mode.

As I documented, i can conclude that my problem is that the collector couldn't read Event logs on ADs because of the extra number of auth (Company with more than 1500 users) and the small time configured to keep the logs (Logs are redirected to an RSA and deleted within 2 minutes regarding to the size of the Event log file) 

 

#First, I have the External Connectors 'Active Directory Connector' Down. and why we can see user and groups when using FSSO agent on windows AD! 

 Should we use ''FSSO agent on windows AD'' or AD Connector is enough on polling mode

[image][/image]

 

 

 

Please advice.

Regards

xsilver_FTNT
Staff
xsilver_FTNTAnswer
Staff
August 9, 2021

Hi Bilel,

unfortunately the pictures were not attached well.

 

However, for example my lab FortiOS 6.4.5 shows two possibilities in Security Fabric / External Connectors / New External Connector / "Endpoint/Identity" section.

1. FSSO Agent on Windows AD

2. Poll Active Directory Server

 

Those two are directly related to FSSO.

First "FSSO Agent on Windows AD" will point FGT to external, standalone, Collector Agent. Which can be installed on DC, or on any domain member Windows server class machine. And which, besides other modes, can poll Windows Security log, or query WMI for Windows Security events and specifically for those user logon related ones. That second method referred in Collector Agent as WinSec-WMI is what I would recommend to use. As it will gather just logon events directly via WMI, and relief Collector from extra burden when pure WinSec log is sequentially read and then parsed for just few suitable logon events while majority of collected data are "garbage" for FSSO purpose.

Second, "Poll Active Directory Server" will make FGT to do similar job as Collector does. Polling DCs for logon events. But it is less favorite method for me as it lacks versatility of standalone Collector Agent and brings extra load on FGT side.

 

If you can not keep WinSec logs, and WMI will not be enough to keep up speed in which your system destroys the evidence, then there is supposed to be MSFT way to duplicate logs to external WinSec log collector. But I never configured it, just hit that as some customers has standalone Collector Agent set to read WinSec logs not from all the DCs but from that single MSFT collector only. But I have little details on how it's made on MSFT side.

 

Alternatively, in standalone Collector Agent, or directly on FGT side in External Connectors, there is "RADIUS Single Sign-On Agent" .. sometimes referred simply as RSSO. Which is method where collector (no matter if standalone Collector or FGT in that role) learns logons events from provided RADIUS Accounting Start/Stop/Update messages. So for example if your users are authenticated via NPS, for example to WiFi, then NPS or wireless controller (WLC), should be able to send Accounting Requests to collector (again, standalone Collector Agent, or FGT in that role, or even FortiAuthenticator, which is probably not your case and I noted FortiAuthenticator just to complete listing of possible recipients).

 

Terms & ConditionsAccessibility statement