Logging of Authentication
CheeseGrater
Newbie ✭
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!
Best Answer
-
CORRECT ANSWERCheeseGrater
Newbie ✭
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.
1
Answers
Hi @CheeseGrater,
1) The login process is best secured by configuring AD over SSL.
In the 12.4 Admin Guide, starting on page 171, is the description for 'Microsoft Active Directory configuration options'
https://www.sonicwall.com/techdocs/pdf/sonicwall-secure-mobile-access-12-4-administration-guide.pdf
2) The SMA caches the cookie of the current authentication session. It does not cache the password. If the user logs out, or the current login expires, the user must provide their credentials again.
3) For Basic AD, the system will access the first listed DC in the Authentication Server configuration unless that DC fails to reply. Only when the SMA can not access the primary DC will it try a secondary one. From the Monitor Users information you can see what Realm the user was logging into and that Realm is associated to one AD Authentication Server. Only that primary DC will be accessed unless it is off line. The DC the user authenticated to can be determined thus.