Add WMI and SQL permission diagnostics

README.md

@@ -19,6 +19,7 @@ Checkmk 2.4 kann Windows-Agent-Plugins und Local Checks direkt ausfuehren. Fuer
 Standardmaessig entstehen diese stabilen Services:
 
 - `BizTalk Platform`
+- `BizTalk SQL Access`
 - `BizTalk Suspended Instances`
 - `BizTalk Host Instances`
 - `BizTalk Runtime Artifacts`
@@ -112,6 +113,8 @@ Wichtige Werte:
 | `ServicePrefix` | `BizTalk` | Prefix fuer alle Checkmk-Services. |
 | `EnvironmentName` | leer | Optional `ACC`, `DEV`, `TST` oder `PRD`. |
 | `QueryTimeoutSeconds` | `25` | WMI-Timeout pro Query. |
+| `ProbeSqlConnectivity` | `true` | Prueft die integrierte Windows-Anmeldung an den per WMI ermittelten Management- und MessageBox-Datenbanken. |
+| `SqlConnectionTimeoutSeconds` | `5` | Timeout je SQL-Ziel fuer Verbindungsaufbau und harmlose Testabfrage. |
 | `WarnResumableThreshold` | `1` | WARN ab n resumable suspended instances. |
 | `CritNonResumableThreshold` | `1` | CRIT ab n non-resumable suspended instances. |
 | `AlertOnArtifactRuntimeIssues` | `false` | Wenn `true`, werden deaktivierte Receive Locations und inaktive Ports/Orchestrations als WARN gewertet. |
@@ -194,7 +197,31 @@ Der verbindliche Test erfolgt ueber den Agent Controller:
     Select-String -Pattern "BizTalk|Access denied|Unauthorized|UNKNOWN" -Context 0,1
 ```
 
-Erwartet werden die fuenf `BizTalk ...` Services mit plausiblen Daten. Insbesondere `BizTalk Platform` darf nicht wegen eines WMI- oder Berechtigungsfehlers `UNKNOWN` sein.
+Erwartet werden die sechs stabilen `BizTalk ...` Services mit plausiblen Daten. Insbesondere `BizTalk Platform` und `BizTalk SQL Access` duerfen nicht wegen eines WMI-, SQL- oder Berechtigungsfehlers `UNKNOWN` sein.
+
+Das Programm prueft Berechtigungen aktiv:
+
+- Der WMI-Namespace-Verbindungsaufbau und jede erforderliche WMI-Klasse werden getrennt bewertet.
+- Fehler werden als `Permission`, `Connectivity`, `Timeout`, `Configuration` oder `Provider` klassifiziert.
+- `BizTalk SQL Access` oeffnet mit integrierter Windows-Authentifizierung eine Verbindung zur ermittelten Management- und MessageBox-Datenbank und fuehrt `SELECT 1` aus.
+- Die Service-Ausgabe nennt Ausfuehrungsidentitaet, erwartete Netzwerkidentitaet, betroffene Komponente, technische Ursache und konkrete Massnahme.
+- Fehlgeschlagene Pflichtabfragen werden nie als leerer, erfolgreicher Datenbestand gewertet. Der betroffene Service wird `UNKNOWN`.
+
+`Sql/Configuration` weist je nach Detailtext entweder auf eine unvollstaendige WMI-Zielermittlung oder auf TLS-, Zertifikats-, SPN-/SSPI-Probleme hin. Die Diagnose empfiehlt bewusst nicht, SQL-Verschluesselung pauschal abzuschalten.
+
+Der SQL-Zugriffstest ersetzt nicht das Checkmk-MSSQL-Plugin auf dem SQL-Server. Er prueft ausschliesslich, ob genau die Identitaet des BizTalk Local Checks die fuer seine Diagnose benoetigten BizTalk-Datenbankziele erreichen kann.
+
+Da bei fehlenden Rechten jeder Lauf einen abgewiesenen SQL-Login erzeugen kann, wird fuer den produktiven Betrieb eine asynchrone Ausfuehrung mit 300 Sekunden Cache empfohlen. Das begrenzt SQL-Logeintraege und Last, verzoegert einen Zustandswechsel aber um maximal fuenf Minuten. Beispiel in `%ProgramData%\checkmk\agent\check_mk.user.yml`:
+
+```yaml
+local:
+  enabled: yes
+  execution:
+    - pattern: $CUSTOM_LOCAL_PATH$\biztalk_checkmk_pulse.cmd
+      async: yes
+      run: yes
+      cache_age: 300
+```
 
 ### Vorgehen bei Berechtigungsfehlern
 
@@ -213,6 +240,8 @@ Entscheidungsmatrix:
 | --- | --- |
 | Alle BizTalk-Services liefern plausible Daten | Keine Berechtigungsaenderung erforderlich. |
 | Verbindung zu `root\MicrosoftBizTalkServer` scheitert | Namespace, BizTalk-WMI-Provider, WMI-Dienst und Namespace-ACL gezielt pruefen. Keine pauschalen WMI-Rechte vergeben. |
+| `BizTalk SQL Access` meldet `Sql/Permission` | Computerkonto `DOMAIN\BIZTALKSERVER$` in die konfigurierte BizTalk-Operator-Gruppe aufnehmen, Kerberos erneuern und erneut testen. Keine direkten BizTalk-DB-Rollen vergeben. |
+| `BizTalk SQL Access` meldet `Sql/Connectivity` oder `Sql/Timeout` | Server-/Instanzname, DNS, SQL-Dienst, TCP-Protokoll, Port und Firewall aus Sicht des BizTalk-Servers pruefen. |
 | Nur SQL-gestuetzte BizTalk-Klassen liefern `Access denied` oder `UNKNOWN` | Computerkonto `DOMAIN\BIZTALKSERVER$` zunaechst in `BizTalk Server Operators` aufnehmen. |
 | `BizTalk Event Log` ist `UNKNOWN` | Zugriff auf das lokale Application Log pruefen; `LocalSystem` kann es normalerweise lesen. |
 | Fehler bleibt trotz Operator-Rolle bestehen | Betroffene WMI-Klasse und BizTalk-/SQL-Rollenzuordnung mit den Fachadministratoren untersuchen. |
@@ -226,6 +255,7 @@ Falls diese Freigabe nicht zulaessig ist, ist die sauberere Alternative ein sepa
 Empfohlene Alarmierung:
 
 - `BizTalk Platform`: `UNKNOWN` immer untersuchen, da dann WMI, Rechte oder Deployment betroffen sind.
+- `BizTalk SQL Access`: `UNKNOWN` als Integrations-, Berechtigungs- oder Verbindungsproblem behandeln und die eingebettete Massnahme abarbeiten.
 - `BizTalk Suspended Instances`: in `PRD` direkt alarmieren; in Nicht-PRD nach Betriebsbedarf.
 - `BizTalk Host Instances`: `CRIT` alarmieren, weil gestoppte Host Instances Laufzeitverarbeitung verhindern koennen.
 - `BizTalk Runtime Artifacts`: zunaechst beobachten; strengere Alarmierung erst aktivieren, wenn deaktivierte Artefakte nicht fachlich gewollt sind.