IIS Authentication
Wenn Sie einen IIS betreiben, dann würde mich schon interessieren, welche Authentifizierungsmethode ein Client verwendet hat. Der IIS selbst bietet ja gleich mehrere Verfahren an und der Client kann sich dann eines aussuchen. Dabei unterscheiden sich die Verfahren durchaus bezüglich Sicherheit, Skalierung und Performance. Diese Seite beschreibt, wie Sie hier Licht ins Dunkel bringen.
Beachten Sie bei der Anmeldung per NTLM auch die Seite IIS Extended Protection
Protokollierung aktivieren
Auf der Seite HTTP Authentication habe ich die technischen Hintergründe beschrieben. Dort lesen Sie aber auch, dass das Feld "Authorization" im HTTP-Request das verwendete Verfahren enthält. Dieses Feld wird per Default nicht in den IISLogs mit protokolliert aber dies können Sie sehr einfach ändern. Hier einmal an einem Beispiel eines Exchange 2016 Servers. Die Clients verbinden sich mit der "Default Web Site" der Frontend-Rolle und hier aktiviere ich unter Logging das Feld "Request Header".
Danach müssen die denn IIS entweder neu starten oder Sie warten, bis der IIS ein neues Logfile anfängt.
Hinweis: Wie Sie im folgenden Bild sehen, hat der IIS den Dateinamen verändert. Beachten Sie die bei einer eventuell vorhandenen automatischen Auswertung
Hier wurde die Änderung also am 23. 9 .2019 durchgeführt
Die LogFiles
Ich habe ihnen hier mal einen verkürzen Auszug aus einem Logfile geliefert. Maßgeblich ist hier die letzte Spalte:
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken Request-Authorization
2019-09-23 14:28:48 192.168.100.33 POST /mapi/emsmdb/ MailboxId=xxx-xx-xx-xx-xxxxx@uclabor.de&CorrelationID=<empty>;&ClientRequestInfo=R:{x-x-x-x-x}:162;RT:Execute;CI:{xx-x-x-x-xx}:x;CID:{xxx.x-x-x-xxx}&cafeReqId=xxx.x-x-x-xxx; 443 UCLABOR\user1 192.168.100.5 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.11901;+Pro) - 200 0 0 1530 1944 12828 Negotiate
2019-09-23 14:28:48 192.168.100.33 POST /mapi/emsmdb/ MailboxId=xxx-xx-xx-xx-xxxxx@uclabor.de&CorrelationID=<empty>;&ClientRequestInfo=R:{x-x-x-x-x}:848;RT:Execute;CI:{xx-x-x-x-xx}:x;CID:{xxx.x-x-x-xxx}&cafeReqId=xxx.x-x-x-xxx; 443 UCLABOR\user2 192.168.102.126 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.11929;+Pro) - 200 0 0 1498 1095 10359 - Negotiate
2019-09-23 14:28:48 192.168.100.33 POST /mapi/emsmdb/ MailboxId=xxx-xx-xx-xx-xxxxx@uclabor.de&CorrelationID=<empty>;&ClientRequestInfo=R:{x-x-x-x-x}:852;RT:Execute;CI:{xx-x-x-x-xx}:x;CID:{xxx.x-x-x-xxx}&cafeReqId=xxx.x-x-x-xxx; 443 UCLABOR\user2 192.168.102.126 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.11929;+Pro) - 200 0 0 1514 1107 15 - Basic
2019-09-23 23:58:25 192.168.100.33 POST /Powershell PSVersion=5.1.14409.1018&sessionID=Version_15.1_(Build_1712.0)=rJqNiZqNgbG+qLqnzsnRkZqLnouIkI2U0Zuagc7Gy83Pyc3IycaBzc/OxtLPxtLNy6vPz8XPx8XNyg==&CorrelationID=<empty>;&cafeReqId=45604da9-245c-4702-b2a0-fe751a5a0f35; 80 - 192.168.100.59 Microsoft+WinRM+Client - 0 0 64 0 2627 403 - -
2019-09-23 23:58:25 192.168.100.33 POST /Powershell PSVersion=5.1.14409.1018&sessionID=Version_15.1_(Build_1712.0)=rJqNiZqNgbG+qLqnzsnRkZqLnouIkI2U0Zuagc7Gy83Pyc3IycaBzc/OxtLPxtLNy6vPz8XPx8XNyg==&CorrelationID=<empty>;&cafeReqId=45604da9-245c-4702-b2a0-fe751a5a0f35; 80 UCLABOR\admin1 192.168.100.59 Microsoft+WinRM+Client - 0 0 64 0 2627 484 - Kerberos
2019-09-23 23:58:25 192.168.100.33 POST /Powershell PSVersion=5.1.14409.1018&sessionID=Version_15.1_(Build_1712.0)=rJqNiZqNgbG+qLqnzsnRkZqLnouIkI2U0Zuagc7Gy83Pyc3IycaBzc/OxtLPxtLNy6vPz8XPx8XNyg==&CorrelationID=<empty>;&cafeReqId=5057ed10-4790-487f-a0e8-63ed74cdb8bd; 80 UCLABOR\admin1 192.168.100.59 Microsoft+WinRM+Client - 200 0 0 1620 5503 31 - Kerberos
Dort sehen sie schon mal das Authentifizierungsverfahren und dass IIS z.B. zwischen Basic, Negotiate und Kerberos unterscheiden. Wobei Negotiate noch nichts darüber aussagt, was drinnen verwendet wurde. Das kann neben NTLM eben auch Kerberos sein. Aber es ist ein erster Ansatz. Alarmieren sollten Sie in einem internen Netzwerk natürlich Zugriffe per "Basic Auth", die nicht per HTTPS verschlüsselt wurden.
Auswertung
Ein solches IISLog lässt sich natürlich mit unterschiedlichsten Tools auswerten. Schon eine einfache PowerShell reicht, um die Datei zu lesen. Wobei Sie hier den Header mitgeben müssen, damit Import-CSV die Spalten zuordnen kann. Oder sie editieren die ersten Zeile, indem Sie das "#Fields: " entfernen. Über "Group-Object" könnten Sie dann nach dem Feld "Request-Authorization" die Zeilen zusammenfassen und so schnell einen Überblick bekommen, welche Authentifizierungsverfahren genutzt werden.
Natürlich sind weitere Filter und Gruppierungen nach Benutzernamen, Client-Subnetz etc. möglich. DAS hängt stark von ihren Anforderungen ab.
