Menu

Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Sign In Register

Logging of Authentication

CheeseGraterCheeseGrater Newbie ✭
in Secure Mobile Access Appliances

SMA successful and failed logon attempts are not appearing in our auditing system. Our domain administrator believes this problem to be associated with the SMA, itself. I am attempting to troubleshoot and rule out the SMA. My questions are:


1.) If an authentication server is defined as "Active Directory (Basic)" are those communications encrypted? Meaning: Should authentication attempts be visible in a packet capture?

2.) Does the SMA cache credentials in any way that the authentication would be occurring locally on the SMA and not against a Domain Controller at each authentication?

3.) In "Monitoring / User Sessions," when a login fails, is there an SMA log that shows which domain controller the authentication attempt occurred against (assuming credentials are not cached in some way)? The user.log shows a failure as "Session Start Failed" and the user's public IP but it does not appear to show which domain controller attempted to authenticate the user.


Thank you!

Category: Secure Mobile Access Appliances
Reply

Best Answer

  • CORRECT ANSWER
    CheeseGraterCheeseGrater Newbie ✭
    Answer ✓

    Thank you for the reply, SIMON!


    I am going to attempt to answer my questions based on troubleshooting and testing I have performed. Be aware that the SMA that I am administering was not something I setup, so my experience with the SMA is new and limited...


    1.) If an authentication server is defined as "Active Directory (Basic)" are those communications encrypted? Meaning: Should authentication attempts be visible in a packet capture?


    The answer to this question is... It depends. By default, it appears that LDAPS is not enabled when a new authentication server is configured. If LDAPS is not enabled, then the authentication traffic will be unencrypted using regular LDAP over TCP/UDP 389. If LDAPS is enabled, then the traffic will be encrypted using TLS and communication with the DC will be on TCP 636. (Note: Enabling LDAPS for an authentication server requires adding the root certificate to the device so it is trusted. Enabling or disabling LDAPS will result in a restart of services when the changes are applied. Any active user sessions will be terminated.)


    2.) Does the SMA cache credentials in any way that the authentication would be occurring locally on the SMA and not against a Domain Controller at each authentication?


    The SMA does not cache credentials. My original reason for this question was because I was searching for a particular user in a packet capture and not finding anything. Nothing associated with authentication will be visible in the pcap when LDAPS is enabled.


    3.) In "Monitoring / User Sessions," when a login fails, is there an SMA log that shows which domain controller the authentication attempt occurred against (assuming credentials are not cached in some way)? The user.log shows a failure as "Session Start Failed" and the user's public IP but it does not appear to show which domain controller attempted to authenticate the user.


    Authentication attempts appear to be stored in the following log on the SMA:

    /var/log/aventail/access_servers.log


    You can find the exact time of a logon attempt by searching this log for the user, although it will not tell you against which DC the authentication attempt was made. I made up a fictitious username (testme123) and attempted a logon. This appeared in the log as follows (some details intentionally omitted):


    [05/Aug/2020:14:46:25.834506 -nnnn] ... Session Authentication for user '(testme123)@(Realm)' FAILED in method AD, Auth::FAIL

    [05/Aug/2020:14:50:27.088844 -nnnn] ... System AUTH: UNPW-AD :User authentication for sAMAccountName = testme123 FAILED . UserDN = (<NULL>).


    I ran a packet capture on the appliance at the same time as the bogus logon attempt, capturing traffic against the configured domain controllers:

    tcpdump '(host 10.x.x.100 or host 10.x.x.101) and (port 389 or port 636)' -i 1 -n -p -w SmaCapture.pcap


    If I jump to the time in the packet capture that matches the time of the logon attempt, I am able to determine which domain controller the user authenticated against. (If you have a lot of users authenticating all the time, it could be a bit more complicated.) Having an authentication time and the IP of the domain controller should prove to any administrator of a domain controller that the authentication is occurring there. Although I did not try it, if you have access to the certificate from the domain controller, I am assuming you could also use Wireshark to decrypt the LDAPS/TLS traffic and view the authentication information as further evidence.

Answers

Sign In or Register to comment.