I ran through the process of creating a solution to get userID consistently for MacOS machines via the syslog feature in the User Agent. The goal was to authenticate to a domain webserver using cert-based auth, and to have the web server provide the IP and user information via syslog to the user agent.
I set up a general webserver site “exch” (AD-joined server, requiring SSL, enabled “Active Directory Client Certificate Authentication and disabled other authentication methods)
Tested cert auth from client machine using “PRAKTIKL\user2”
Checking the event security logs, you see the user logon event (4624), but the IP is not recorded. I found that when the provider is “schannel” (this seems to always be the case with cert-based auth to webservers in an AD domain), the IP is never logged.
Best info I could find on this is: “This is because the service handles authentication on behalf of the client”. If I use username/password, I get the IP, although via a different service. Unfortunately, this affects OWA too, where logging in via the app uses logon process “kerberos” and provides the IP, but logging in via OWA with cert-based authentication uses “schannel” and does not provide the IP. This is also reflected in the user agent where app login logs userID, and OWA login does not.
IP and user information is stored in the IIS logs. You just need to verify logging is enabled for the site. I chose the IIS format: csv.
If you browse to the log file location you can verify the logs contain the right information by opening the latest log and searching for a user, in my case “user2”. Looking at the example, the source IP is logged first, followed by the user in down-level logon format.
To parse these log files and get any sort of useful format, I found that LogParser 2.2 from Microsoft https://www.microsoft.com/en-us/download/details.aspx?id=24659 was the best SIMPLE/FREE option. Also, if you make sure that “IIS 6 Metabase Compatibility” is installed, this will simplify using LogParser where you can reference the IIS logs for a site using only <SITENAME>.
LogParser opens in command prompt, and you can query the IIS logs to test extracting the IP and username, in my case “user2”. Selecting on “UserIP” and “UserName” provides only the output needed (IP and username).
NOTE: If you run command (logparser “SELECT * FROM <SITENAME>”), it will show the heading and all fields you can use to select on.
You can test sending this output to the user agent using the output switch for syslog and “INTO” redirection to @IP:port. “-o syslog” and “INTO @192.168.2.5:514”
Log messages received on user agent machine
Then you can configure the user agent to accept logs from web server and configure regex to match on log information to extract the IP and user.
The string to match on is “EXCH LogParser:192.168.2.5 PRAKTIKL\user2” per the pcap above.
For the user agent syslog regex configuration, you can have a specific match, or you can lead with some data and surround the relevant portions in “()”. For example, there are three fields:
Event Regex: “EXCH LogParser” – nothing special here
Username Regex:
Beginning Delimiter User Matching Data
[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3} (PRAKTIKL\\[a-zA-Z0-9]*\.?[a-zA-Z0-9]*)
Address Regex:
Delimiter IP Matching Data
LogParser: ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})
If you log into the webserver again from the client: in my case “user2”, and run the LogParser command again, you’ll have the user ID info logged in the user agent.
LogParser ran again after site logon
Syslog received on user agent
User ID logged in agent
The full LogParser string is:
Logparser.exe -i:IIS “SELECT UserIP, UserName INTO @192.168.2.5:514 FROM <exch>” -o syslog -icheckpoint:C:\userid\mycheckpoint.lpc
Adding the -icheckpoint switch allows LogParser to track the parsing location in the log file using a special file ".lpc" (in my case, C\userid\mycheckpoing.lpc), so it will not resend entries that were previously received and sent.
For example, if I clear the user agent cache and wireshark, and I run the command again, nothing will be sent.
If I authenticate to the site again and run the LogParser command, there will be a new entry.
Once the command and user agent are ironed out, you can automate using “schtasks.exe” (Task Scheduler) and a batch file. See below: I just added the same command to a txt file and saved as a .bat
Then, I ran “schtasks.exe /create /tn userIDsyslog /sc minute /tr C:\userid\userid.bat” to get the task going.
I also found that it will be set to “Run only when user is logged on” under “Security options”, and it will fail initially. I changed it to “Run whether user is logged on or not” and “Do not store password. The task will only have access to local computer resources.”. Once I did that, it started working.
New logs received by user agent
At this point, you can just set up this logging option on frequently used web servers and/or set up a special-purpose web server, use Desktop shortcuts on Mac clients, and tell users if they’re not able to get to stuff, to open the link, authenticate, and they’ll be good to go in 1-3 mins.
If you want to automate it so that machines are always authenticating without user interaction, that is possible too.
If you take a user cert, break it up into cert and key, and call it in a curl action, you can add this to a cron job and have it checking in continuously.
Below, I took the user cert for “PRAKTIKL\domain.admin” and broke it up using openssl
Next, I made a .bash file identifying the location of the CA cert, the private key, and the cert, with a curl to https://exch.praktikl.com
Then, I used Crontab to run this file every minute. (NOTE: IP 192.168.3.16)
Checking back on the user agent, I verified that “PRAKTIKL\domain.admin” was logged to IP 192.168.3.16.
That’s it, hope it helps.
