STAS ongoing Authentication issues

Hey guys,

My love  / hate with STAS continues.

I have had STAS set up for quite sometime and it works for the most part. I have around 250 PC's / Users connected and around 95% of them Authenticate Ok.

Then I have a bunch of random PC's that just will not Authenticate - rebooting the PC makes little difference and no matter what they just wont happen. These Users / PC's were fine last week.

I checked WMI and from the STAS screen they work fine, the users dont appear in Live users and the XG Authentication logs dont show them.

 

Its like the Logon Event just isn't being read. I have 3 DCs and STAS on each in one collector group.

I have been through the STAS Install / Set up guide a few times to ensure nothing was missed and I am confident all is as it should be including FW Ports, Services, Auditing etc. This must be ok as many PC's work fine.

The Windows DCs are 2016 and 2019 - Firewalls off for testing. Connectivity from each DC to the XG is fine and no errors.

 

I am at a loss as to where to look next on these PC's that just wont authenticate.

Any suggestions where to next?

 

I started loading the CAA onto these to get them up and running again.

 

Cheers

  • Hi  

    Do these machines/users ever authenticate?

    When the authentication issue happens, what is the logon server set to? Is it 1 of the servers with STAS installed?

    Can you post the configuration of your STAS configuration on the servers as well as the XG?

    Looking at the logon server that authenticated the user, do you see a logon event created for that user at time of login?

    Is this a flat network or are there VLANs and/or L3 switches involved?

     

    Thanks!

  • In reply to KingChris:

    Thanks for the comment,

     

    Yes they have been authenticating fine for some time but randomly decided not to anymore.

     

    There are 3 DCs that they can Authenticate to - all have STAS installed and all are in the STAS Group.

     

    I can post many images but keep in mind 200+ users authenticate just fine each day with STAS - so not sure thats where the issue is.

    The network does have a L3 switch between the LANs and the XG

  • In reply to M8ey:

    If they did authenticate at one stage but now no longer and all other users are working fine, then there must be an issue local on the PC.

    If there is no event log for that user, STAS will not send the event to the XG.

    If the XG tries to query the PC for user information via STAS and WMI, there should be information that gets populated with that request if the client PC WMI is functioning correctly.

    If all else fails, try a new machine with the same user account and IP address and see if it populates the logon.  If that works then you know the issue is local and that you would need to reinstall the system or investigate.

    Thanks.

  • In reply to KingChris:

    Yep that's about where I am up to.

    No clue why just a hand full of these PC's are doing it now for no reason - maybe a Windows 10 1909 update issue....

     

    I will try logging in with another user account and see if its the local PC - although I do see Logon Event logs but get a Logoff right after (even though they are logged on)

  • In reply to M8ey:

    Interestingly enough I am not seeing Event ID 4768 but rather Event ID 4624

    No clue why this would be though.

  • In reply to M8ey:

    Even more digging.

    If I open STAS on one of my DCs and go to Advanced and test connectivity the Sophos XG is fine but the two VM DCs cannot communicate with the main DC when testing STAS Agent or Collector 

     

    But I can from the two VM DCs to each other.

    I am able to telnet between DCs on Port 5566 and again Windows FW is turned off.

    Main DC is on 192.168.1.2

    VM 192.168.1.27

    Remote 172.16.100.9

    VM / Remote talk fine but neither can reach 192.168.1.2 via STAS Testing

    I have uninstalled STAS on 192.168.1.2 and reinstalled but no change.

     

    Why would STAS on 192.168.1.2 be upset.

    I can test back to the VMs ok from 192.168.1.2 though - both Agent and Collector

  • In reply to M8ey:

    You can try reboot that DC.

    I have seen it happen before whereby the ephemeral port range used by 1 of the services on Windows takes the port STAS wants to listen on.  

    You can check to see if STAS is listening on that port by looking at netstat or using another tool.

    Also check to see if there are any other interfaces not connected on the DC.  Sometimes STAS does not bind to the correct interface.

    However I believe you not seeing that specific event ID is more than likely your cause.

    Have you enabled audit logon/logoff events on the DCs?

  • In reply to KingChris:

    KingChris
    You can try reboot that DC.

    Yep on the list for tonight - it also does DHCP so will do after hours.

     

    Will dig a bit more with netstat etc

     

    Yes Logon / Logoff Audit is enabled on all DCs

     

  • In reply to M8ey:

    The first step is, do you see the Users popping up in the STAS Log on STAS Collector? 

    There should be entries of "Found User" etc. If not, something is blocking the eventlogs. 

  • In reply to LuCar Toni:

    I think the issue is that there are no more Event: 4768 in my DC Security Logs.

     

    Logging is on but no 4768

     

    C:\Users\administrator.ESSFIELDS>auditpol.exe /get /category:*
    System audit policy
    Category/Subcategory Setting
    System
    Security System Extension No Auditing
    System Integrity No Auditing
    IPsec Driver No Auditing
    Other System Events No Auditing
    Security State Change No Auditing
    Logon/Logoff
    Logon Success and Failure
    Logoff Success and Failure
    Account Lockout No Auditing
    IPsec Main Mode No Auditing
    IPsec Quick Mode No Auditing
    IPsec Extended Mode No Auditing
    Special Logon No Auditing
    Other Logon/Logoff Events Success and Failure
    Network Policy Server No Auditing
    User / Device Claims No Auditing
    Group Membership No Auditing
    Object Access
    File System No Auditing
    Registry No Auditing
    Kernel Object No Auditing
    SAM No Auditing
    Certification Services No Auditing
    Application Generated No Auditing
    Handle Manipulation No Auditing
    File Share No Auditing
    Filtering Platform Packet Drop No Auditing
    Filtering Platform Connection No Auditing
    Other Object Access Events No Auditing
    Detailed File Share No Auditing
    Removable Storage No Auditing
    Central Policy Staging No Auditing
    Privilege Use
    Non Sensitive Privilege Use No Auditing
    Other Privilege Use Events No Auditing
    Sensitive Privilege Use No Auditing
    Detailed Tracking
    Process Creation No Auditing
    Process Termination No Auditing
    DPAPI Activity No Auditing
    RPC Events No Auditing
    Plug and Play Events No Auditing
    Token Right Adjusted Events No Auditing
    Policy Change
    Audit Policy Change No Auditing
    Authentication Policy Change No Auditing
    Authorization Policy Change No Auditing
    MPSSVC Rule-Level Policy Change No Auditing
    Filtering Platform Policy Change No Auditing
    Other Policy Change Events No Auditing
    Account Management
    Computer Account Management No Auditing
    Security Group Management No Auditing
    Distribution Group Management No Auditing
    Application Group Management No Auditing
    Other Account Management Events No Auditing
    User Account Management No Auditing
    DS Access
    Directory Service Access No Auditing
    Directory Service Changes No Auditing
    Directory Service Replication No Auditing
    Detailed Directory Service Replication No Auditing
    Account Logon
    Kerberos Service Ticket Operations Success and Failure
    Other Account Logon Events Success and Failure
    Kerberos Authentication Service No Auditing
    Credential Validation No Auditing

  • In reply to LuCar Toni:

    We have had issues with STAS, mainly the wrong account being logged by a computer that never uses that account.

    Is STAS the best option for a windows domain, or should we be using NTLM, or something else?