[MSP] SPLA/RDS: berechtigte Nutzer über SeRemoteInteractiveLogonRight ermitteln (nicht über Remote Desktop Users, nicht über Logins) #225

New issue

Open

opened 2026-07-20 23:15:03 +00:00 by chinux · 2 comments

chinux commented 2026-07-20 23:15:03 +00:00

Owner

Copy link

Erfassung der RDS-Berechtigungen je Mandant als Grundlage für die monatliche SPLA-Meldung.

Überarbeitet. Die erste Fassung wollte Login-Ereignisse und die Gruppe Remote Desktop Users zählen. Beides ist falsch bzw. unvollständig — Begründung unten. Maßgeblich ist das Benutzerrecht, nicht die Gruppe, und die Berechtigung, nicht die Nutzung.

Was gezählt werden muss

User SALs werden pro eindeutigem, namentlich berechtigtem Nutzer fällig — nicht pro gleichzeitigem und nicht pro tatsächlich eingeloggtem. Gemeldet wird der Monatshöchststand.

Beispiel: Zwölf Mitarbeiter haben RDS-Zugriff, nie mehr als vier arbeiten gleichzeitig, im Monat loggen sich acht ein. Fällig sind zwölf SALs.

Eine Zählung über Login-Ereignisse unterzählt damit systematisch. Unterlizenzierung ist bei einem SPLA-Audit das teure Ergebnis.

Kein Rechtsrat. Die Auslegung gehört mit dem SPLA-Reseller abgeglichen, inhaltlich zu #188.

Warum nicht Remote Desktop Users

Die autoritative Instanz ist das Benutzerrecht SeRemoteInteractiveLogonRight („Anmelden über Remotedesktopdienste zulassen"). Remote Desktop Users steht dort nur drin, weil Windows sie bei der Installation einträgt. Ein Admin kann jede beliebige Gruppe direkt eintragen — dann ist die Standardgruppe leer und trotzdem sind 40 Personen berechtigt. Wer nur die Standardgruppe abfragt, meldet in dem Fall null.

Ebenso zwingend: SeDenyRemoteInteractiveLogonRight. Verweigern gewinnt. In gehärteten Umgebungen wird darüber gezielt ausgeschlossen; ohne diese Liste zählt man Konten mit, die gar nicht hineinkommen.

Ermittlungskette

1. SeRemoteInteractiveLogonRight auslesen → Liste von SIDs (meist Gruppen)
2. SeDenyRemoteInteractiveLogonRight auslesen → Ausschlussliste
3. Gruppen zu Konten auflösen, inklusive Verschachtelung
4. Deny abziehen, deduplizieren
5. Bei RDS-Farm mit Broker: Collection-Berechtigung als engere Grenze darüberlegen

Beispielergebnis

Server TRE-RDS01
Erlaubt:  "Büro Trendsetzer" (14) · "Domänen-Admins" (3)
Verweigert: svc-backup
→ 16 berechtigte Konten

Diese 16 sind die Meldegröße — auch wenn im Monat nur 9 gearbeitet haben.

Datenschutz

Die Anzahl kommt nicht ohne Kennungen aus — zum Deduplizieren müssen sie verarbeitet werden. Die Frage ist, wo und was übertragen wird.

Stufe	Verhalten	Einsatz
count (Default)	Auflösung und Deduplizierung im Agent; übertragen wird nur die Zahl plus Gruppenherkunft. Kein Kontoname verlässt die VM.	Regelfall
pseudonym	HMAC-SHA256 mit mandantenspezifischem Salt. Stabil zählbar, kein Klartext.	Wenn pro Kopf weiterberechnet wird
plain	Klartext	Nicht implementieren.

Rechtsgrundlage wäre Art. 6 Abs. 1 lit. b bzw. f DSGVO; für Beschäftigtendaten der Kunden ist der MSP Auftragsverarbeiter (AVV nach Art. 28). Datenminimierung (Art. 5 Abs. 1 lit. c) spricht klar für count.

Praktisch entscheidend ist § 87 Abs. 1 Nr. 6 BetrVG. Erfassung von Login-Zeiten pro namentlichem Mitarbeiter ist zur Leistungs- und Verhaltenskontrolle geeignet und damit mitbestimmungspflichtig. Reine Berechtigungszählung ohne Zeitbezug ist deutlich unkritischer — ein weiteres Argument, Login-Ereignisse allenfalls als Aggregat zu nutzen.

---

Prompt für Claude Code

Baue die RDS-Berechtigungserfassung für die SPLA-Meldung.
SETZT #214 (run_ps-Timeout) UND #215 (Dienste-/Rollen-Inventar) VORAUS.
Das Feature ist pro Mandant abschaltbar, Default AUS.

=== TEIL 1: WINDOWS-AGENT ===
Neuer Collector collect_rds_entitlements() in
Windows-VM-Guest-Agent/src/collect.rs. Läuft NUR, wenn der Server das
Feature für diese VM aktiviert hat — nicht bei jedem Scan blind mitlaufen.

--- 1a. BENUTZERRECHTE AUSLESEN ---
Es gibt kein Cmdlet dafür. Zwei Wege, in dieser Reihenfolge versuchen:

  A) LSA-API LsaEnumerateAccountsWithUserRight über windows-rs.
     Sauber, kein Datei-I/O, kein Parsing. Bevorzugt.
  B) Fallback:
       secedit /export /areas USER_RIGHTS /cfg <tempfile>
     Zeilen SeRemoteInteractiveLogonRight = *S-1-... und
     SeDenyRemoteInteractiveLogonRight = ... parsen.
     Tempdatei danach LÖSCHEN (enthält Sicherheitskonfiguration).

BEIDE Rechte auslesen. Deny ist nicht optional.

--- 1b. SIDs AUFLÖSEN ---
Pro SID Typ bestimmen (Benutzer / lokale Gruppe / Domänengruppe / unbekannt).

  - Lokale Gruppen: Get-LocalGroupMember
  - Domänengruppen: ADSI / System.DirectoryServices.
    NICHT Get-ADGroupMember — das braucht RSAT und ist auf einem
    RDS-Mitgliedsserver praktisch nie installiert.
    Verschachtelung in EINER Abfrage über LDAP_MATCHING_RULE_IN_CHAIN:
        (member:1.2.840.113556.1.4.1941:=<Gruppen-DN>)
    Das löst die gesamte Kette serverseitig auf.

  - Deaktivierte Konten (userAccountControl Bit 2) NICHT mitzählen, aber
    getrennt ausweisen — ein gesperrtes Konto ist nicht zugriffsberechtigt.

--- 1c. OBERGRENZE FÜR BREITE BERECHTIGUNGEN ---
Ist eine der Gruppen Domain Users, Authenticated Users, Everyone oder
löst sie auf mehr als MAX_EXPAND (Default 500) Konten auf:
  - NICHT weiter auflösen
  - melden: {"group": "...", "sid": "...", "approx_size": n,
             "blanket": true}
  - das Gesamtergebnis als "blanket_permission": true markieren
Lizenzrechtlich ist das ein Gespräch mit dem Kunden, keine automatische
Zahl. Das Feature darf hier keine Scheingenauigkeit erzeugen.

--- 1d. RDS-COLLECTIONS ---
Wenn das PowerShell-Modul RemoteDesktop vorhanden ist (echte Farm mit
Broker), zusätzlich:
    Get-RDSessionCollectionConfiguration -CollectionName <x> |
      Select -ExpandProperty UserGroup
Die Collection-Berechtigung ist ENGER als das Benutzerrecht und ist dann
die tatsächliche Grenze. Modul fehlt -> keine Farm, Benutzerrecht genügt,
kein Fehler.

--- 1e. UNVOLLSTÄNDIGKEIT ---
Kann eine Domänengruppe nicht aufgelöst werden (kein DC erreichbar,
Arbeitsgruppenserver, Berechtigung fehlt), dann NIEMALS eine kleinere Zahl
melden. Stattdessen:
    "complete": false,
    "unresolved": [{"sid": "...", "reason": "no_dc"}]
Eine stillschweigend zu kleine Zahl ist genau das
Unterlizenzierungsrisiko, das dieses Feature vermeiden soll. Der Server
muss unvollständige Ergebnisse als solche behandeln und darf sie nicht in
eine Meldesumme einrechnen.

--- 1f. DATENSPARSAMKEIT ---
Der Modus (count|pseudonym) kommt vom Server. Bei "count":
Auflösung und Deduplizierung passieren VOLLSTÄNDIG im Agent; übertragen
werden nur Zahlen plus Gruppennamen/SIDs. Bei "pseudonym": HMAC-SHA256 der
Kennung mit dem vom Server übergebenen Salt-Derivat. Klartext-Kennungen
werden NIE übertragen und NIE persistiert.

Payload:
    {"type": "rds_entitlements", "vmid": n, "ts": "...",
     "mode": "count"|"pseudonym",
     "allowed_total": n, "denied_total": n, "effective_total": n,
     "disabled_excluded": n,
     "sources": [{"kind":"user_right"|"collection",
                  "group":"...", "sid":"...", "members": n,
                  "blanket": bool}],
     "members": [...],        // nur bei pseudonym: Hashes
     "complete": bool, "unresolved": [...], "blanket_permission": bool}

--- 1g. SICHERHEIT ---
Ausschliesslich lesend. Kein secedit /configure, keine Gruppenänderung,
keine Rechtevergabe. Im Modulkopf festhalten. Timeout-Budget
PS_TIMEOUT_INVENTORY aus #214; Domänenabfragen können bei langsamem DC
dauern — eigenes, grosszügigeres Budget erwägen.

=== TEIL 2: SERVER ===
--- 2a. MIGRATION ---
Tabelle rds_entitlement_daily:
    id, tenant_id, node_name, vmid, day (Date),
    effective_total, allowed_total, denied_total,
    complete (bool), blanket_permission (bool),
    sources JSONB, members JSONB NULL
    UNIQUE (node_name, vmid, day)

Aufbewahrung: Tagesaggregat lange (Audit-Nachweis, Vorschlag 26 Monate),
Rohereignisse gar nicht persistieren.

Settings-Key "spla" je Mandant:
    {"enabled": false, "mode": "count", "salt_version": 1,
     "interval_hours": 24}

--- 2b. AUSWERTUNG ---
    async def spla_report(tenant_id, year, month) -> dict

Liefert je Guest und je Mandant den MONATSHÖCHSTSTAND von
effective_total, plus:
    - Tage ohne Daten
    - Tage mit complete=false (NICHT in den Höchststand einrechnen,
      sondern separat ausweisen)
    - Guests mit blanket_permission (gesondert, nie automatisch summiert)
    - Gegenprobe aus Login-Ereignissen, falls aktiviert: aktive Nutzer im
      Monat, als Vergleichszahl ("16 berechtigt / 9 genutzt")

Nur Guests mit Vertragsstatus managed/monitored (#223) einrechnen.

--- 2c. API + UI ---
    GET /api/spla/{tenant_id}?year=&month=
    GET /api/spla/{tenant_id}/export?format=csv
Settings-Abschnitt je Mandant: Toggle, Modus, Intervall, Salt-Rotation.
Aktivierung und Modusänderung ins AuditLog.

Die Ansicht MUSS die Herkunft zeigen — Gruppe, Quelle (Benutzerrecht oder
Collection), Anzahl. Eine nackte Zahl ist nicht überprüfbar und damit
wertlos, wenn ein Auditor nachfragt.

--- 2d. TRANSPARENZ ---
Aktive Erfassung in der Doku (#209) und im Kundenblick (#224) sichtbar
machen. Verdeckte Erfassung von Nutzungsdaten wäre der Vertrauensbruch,
den man sich als MSP nicht leisten kann.

=== TEIL 3: TESTS ===
  - Benutzerrecht enthält eine NICHT-Standardgruppe -> wird erkannt,
    Remote Desktop Users leer -> trotzdem korrekte Zahl
  - Deny-Recht zieht ab; Konto in beiden Listen -> zählt nicht
  - Verschachtelte Domänengruppe -> alle Ebenen aufgelöst, dedupliziert
  - Deaktiviertes Konto -> nicht gezählt, aber ausgewiesen
  - Domain Users eingetragen -> blanket_permission, keine Expansion
  - DC nicht erreichbar -> complete=false, Zahl NICHT kleiner gemeldet,
    Tag fliesst nicht in den Höchststand
  - Modus count -> keine Kennung im Payload (Payload-Inhalt prüfen)
  - Salt-Rotation -> alte und neue Pseudonyme nicht verknüpfbar,
    Bruch im Report ausgewiesen
  - RemoteDesktop-Modul fehlt -> kein Fehler, Benutzerrecht gilt

Definition of Done

• Benutzerrecht statt Gruppe, Deny-Recht wird berücksichtigt
• Verschachtelte Domänengruppen ohne RSAT auflösbar
• Breite Berechtigungen erzeugen keine Scheingenauigkeit
• Unvollständige Ermittlung meldet nie eine kleinere Zahl
• Modus count überträgt keine Kennungen
• Ergebnis zeigt Herkunft je Berechtigung, nicht nur eine Summe
• Ausschließlich lesende Zugriffe
• Pro Mandant abschaltbar, Default aus, Aktivierung auditiert

Offene Entscheidungen

• Auch andere SPLA-Produkte (SQL Server, Exchange)? #215 liefert die Erkennung.
• Login-Gegenprobe aktivieren — und wenn ja, nur als Monatsaggregat?
• Umgang mit Administratoren und Dienstkonten: die Einstufung als SAL-pflichtig ist eine Vertragsfrage, die der Agent nicht entscheiden kann. Vorschlag: Ausschlussliste je Mandant, angewandt beim Report, nicht beim Erfassen.

Erfassung der RDS-Berechtigungen je Mandant als Grundlage für die monatliche SPLA-Meldung. > **Überarbeitet.** Die erste Fassung wollte Login-Ereignisse und die Gruppe `Remote Desktop Users` zählen. Beides ist falsch bzw. unvollständig — Begründung unten. Maßgeblich ist das Benutzerrecht, nicht die Gruppe, und die Berechtigung, nicht die Nutzung. ## Was gezählt werden muss **User SALs werden pro eindeutigem, namentlich berechtigtem Nutzer fällig** — nicht pro gleichzeitigem und nicht pro tatsächlich eingeloggtem. Gemeldet wird der Monatshöchststand. Beispiel: Zwölf Mitarbeiter haben RDS-Zugriff, nie mehr als vier arbeiten gleichzeitig, im Monat loggen sich acht ein. Fällig sind **zwölf** SALs. Eine Zählung über Login-Ereignisse unterzählt damit systematisch. Unterlizenzierung ist bei einem SPLA-Audit das teure Ergebnis. **Kein Rechtsrat.** Die Auslegung gehört mit dem SPLA-Reseller abgeglichen, inhaltlich zu #188. ## Warum nicht `Remote Desktop Users` Die autoritative Instanz ist das Benutzerrecht **`SeRemoteInteractiveLogonRight`** („Anmelden über Remotedesktopdienste zulassen"). `Remote Desktop Users` steht dort nur drin, weil Windows sie bei der Installation einträgt. Ein Admin kann jede beliebige Gruppe direkt eintragen — dann ist die Standardgruppe leer und trotzdem sind 40 Personen berechtigt. Wer nur die Standardgruppe abfragt, meldet in dem Fall null. Ebenso zwingend: **`SeDenyRemoteInteractiveLogonRight`**. Verweigern gewinnt. In gehärteten Umgebungen wird darüber gezielt ausgeschlossen; ohne diese Liste zählt man Konten mit, die gar nicht hineinkommen. ## Ermittlungskette 1. `SeRemoteInteractiveLogonRight` auslesen → Liste von SIDs (meist Gruppen) 2. `SeDenyRemoteInteractiveLogonRight` auslesen → Ausschlussliste 3. Gruppen zu Konten auflösen, inklusive Verschachtelung 4. Deny abziehen, deduplizieren 5. Bei RDS-Farm mit Broker: Collection-Berechtigung als engere Grenze darüberlegen ## Beispielergebnis Server TRE-RDS01 Erlaubt: "Büro Trendsetzer" (14) · "Domänen-Admins" (3) Verweigert: svc-backup → 16 berechtigte Konten Diese 16 sind die Meldegröße — auch wenn im Monat nur 9 gearbeitet haben. ## Datenschutz Die Anzahl kommt nicht ohne Kennungen aus — zum Deduplizieren müssen sie verarbeitet werden. Die Frage ist, **wo** und **was übertragen wird**. | Stufe | Verhalten | Einsatz | |---|---|---| | `count` (Default) | Auflösung und Deduplizierung im Agent; übertragen wird nur die Zahl plus Gruppenherkunft. Kein Kontoname verlässt die VM. | Regelfall | | `pseudonym` | HMAC-SHA256 mit mandantenspezifischem Salt. Stabil zählbar, kein Klartext. | Wenn pro Kopf weiterberechnet wird | | `plain` | Klartext | **Nicht implementieren.** | Rechtsgrundlage wäre Art. 6 Abs. 1 lit. b bzw. f DSGVO; für Beschäftigtendaten der Kunden ist der MSP Auftragsverarbeiter (AVV nach Art. 28). Datenminimierung (Art. 5 Abs. 1 lit. c) spricht klar für `count`. **Praktisch entscheidend ist § 87 Abs. 1 Nr. 6 BetrVG.** Erfassung von Login-Zeiten pro namentlichem Mitarbeiter ist zur Leistungs- und Verhaltenskontrolle geeignet und damit mitbestimmungspflichtig. Reine Berechtigungszählung ohne Zeitbezug ist deutlich unkritischer — ein weiteres Argument, Login-Ereignisse allenfalls als Aggregat zu nutzen. --- ## Prompt für Claude Code ``` Baue die RDS-Berechtigungserfassung für die SPLA-Meldung. SETZT #214 (run_ps-Timeout) UND #215 (Dienste-/Rollen-Inventar) VORAUS. Das Feature ist pro Mandant abschaltbar, Default AUS. === TEIL 1: WINDOWS-AGENT === Neuer Collector collect_rds_entitlements() in Windows-VM-Guest-Agent/src/collect.rs. Läuft NUR, wenn der Server das Feature für diese VM aktiviert hat — nicht bei jedem Scan blind mitlaufen. --- 1a. BENUTZERRECHTE AUSLESEN --- Es gibt kein Cmdlet dafür. Zwei Wege, in dieser Reihenfolge versuchen: A) LSA-API LsaEnumerateAccountsWithUserRight über windows-rs. Sauber, kein Datei-I/O, kein Parsing. Bevorzugt. B) Fallback: secedit /export /areas USER_RIGHTS /cfg <tempfile> Zeilen SeRemoteInteractiveLogonRight = *S-1-... und SeDenyRemoteInteractiveLogonRight = ... parsen. Tempdatei danach LÖSCHEN (enthält Sicherheitskonfiguration). BEIDE Rechte auslesen. Deny ist nicht optional. --- 1b. SIDs AUFLÖSEN --- Pro SID Typ bestimmen (Benutzer / lokale Gruppe / Domänengruppe / unbekannt). - Lokale Gruppen: Get-LocalGroupMember - Domänengruppen: ADSI / System.DirectoryServices. NICHT Get-ADGroupMember — das braucht RSAT und ist auf einem RDS-Mitgliedsserver praktisch nie installiert. Verschachtelung in EINER Abfrage über LDAP_MATCHING_RULE_IN_CHAIN: (member:1.2.840.113556.1.4.1941:=<Gruppen-DN>) Das löst die gesamte Kette serverseitig auf. - Deaktivierte Konten (userAccountControl Bit 2) NICHT mitzählen, aber getrennt ausweisen — ein gesperrtes Konto ist nicht zugriffsberechtigt. --- 1c. OBERGRENZE FÜR BREITE BERECHTIGUNGEN --- Ist eine der Gruppen Domain Users, Authenticated Users, Everyone oder löst sie auf mehr als MAX_EXPAND (Default 500) Konten auf: - NICHT weiter auflösen - melden: {"group": "...", "sid": "...", "approx_size": n, "blanket": true} - das Gesamtergebnis als "blanket_permission": true markieren Lizenzrechtlich ist das ein Gespräch mit dem Kunden, keine automatische Zahl. Das Feature darf hier keine Scheingenauigkeit erzeugen. --- 1d. RDS-COLLECTIONS --- Wenn das PowerShell-Modul RemoteDesktop vorhanden ist (echte Farm mit Broker), zusätzlich: Get-RDSessionCollectionConfiguration -CollectionName <x> | Select -ExpandProperty UserGroup Die Collection-Berechtigung ist ENGER als das Benutzerrecht und ist dann die tatsächliche Grenze. Modul fehlt -> keine Farm, Benutzerrecht genügt, kein Fehler. --- 1e. UNVOLLSTÄNDIGKEIT --- Kann eine Domänengruppe nicht aufgelöst werden (kein DC erreichbar, Arbeitsgruppenserver, Berechtigung fehlt), dann NIEMALS eine kleinere Zahl melden. Stattdessen: "complete": false, "unresolved": [{"sid": "...", "reason": "no_dc"}] Eine stillschweigend zu kleine Zahl ist genau das Unterlizenzierungsrisiko, das dieses Feature vermeiden soll. Der Server muss unvollständige Ergebnisse als solche behandeln und darf sie nicht in eine Meldesumme einrechnen. --- 1f. DATENSPARSAMKEIT --- Der Modus (count|pseudonym) kommt vom Server. Bei "count": Auflösung und Deduplizierung passieren VOLLSTÄNDIG im Agent; übertragen werden nur Zahlen plus Gruppennamen/SIDs. Bei "pseudonym": HMAC-SHA256 der Kennung mit dem vom Server übergebenen Salt-Derivat. Klartext-Kennungen werden NIE übertragen und NIE persistiert. Payload: {"type": "rds_entitlements", "vmid": n, "ts": "...", "mode": "count"|"pseudonym", "allowed_total": n, "denied_total": n, "effective_total": n, "disabled_excluded": n, "sources": [{"kind":"user_right"|"collection", "group":"...", "sid":"...", "members": n, "blanket": bool}], "members": [...], // nur bei pseudonym: Hashes "complete": bool, "unresolved": [...], "blanket_permission": bool} --- 1g. SICHERHEIT --- Ausschliesslich lesend. Kein secedit /configure, keine Gruppenänderung, keine Rechtevergabe. Im Modulkopf festhalten. Timeout-Budget PS_TIMEOUT_INVENTORY aus #214; Domänenabfragen können bei langsamem DC dauern — eigenes, grosszügigeres Budget erwägen. === TEIL 2: SERVER === --- 2a. MIGRATION --- Tabelle rds_entitlement_daily: id, tenant_id, node_name, vmid, day (Date), effective_total, allowed_total, denied_total, complete (bool), blanket_permission (bool), sources JSONB, members JSONB NULL UNIQUE (node_name, vmid, day) Aufbewahrung: Tagesaggregat lange (Audit-Nachweis, Vorschlag 26 Monate), Rohereignisse gar nicht persistieren. Settings-Key "spla" je Mandant: {"enabled": false, "mode": "count", "salt_version": 1, "interval_hours": 24} --- 2b. AUSWERTUNG --- async def spla_report(tenant_id, year, month) -> dict Liefert je Guest und je Mandant den MONATSHÖCHSTSTAND von effective_total, plus: - Tage ohne Daten - Tage mit complete=false (NICHT in den Höchststand einrechnen, sondern separat ausweisen) - Guests mit blanket_permission (gesondert, nie automatisch summiert) - Gegenprobe aus Login-Ereignissen, falls aktiviert: aktive Nutzer im Monat, als Vergleichszahl ("16 berechtigt / 9 genutzt") Nur Guests mit Vertragsstatus managed/monitored (#223) einrechnen. --- 2c. API + UI --- GET /api/spla/{tenant_id}?year=&month= GET /api/spla/{tenant_id}/export?format=csv Settings-Abschnitt je Mandant: Toggle, Modus, Intervall, Salt-Rotation. Aktivierung und Modusänderung ins AuditLog. Die Ansicht MUSS die Herkunft zeigen — Gruppe, Quelle (Benutzerrecht oder Collection), Anzahl. Eine nackte Zahl ist nicht überprüfbar und damit wertlos, wenn ein Auditor nachfragt. --- 2d. TRANSPARENZ --- Aktive Erfassung in der Doku (#209) und im Kundenblick (#224) sichtbar machen. Verdeckte Erfassung von Nutzungsdaten wäre der Vertrauensbruch, den man sich als MSP nicht leisten kann. === TEIL 3: TESTS === - Benutzerrecht enthält eine NICHT-Standardgruppe -> wird erkannt, Remote Desktop Users leer -> trotzdem korrekte Zahl - Deny-Recht zieht ab; Konto in beiden Listen -> zählt nicht - Verschachtelte Domänengruppe -> alle Ebenen aufgelöst, dedupliziert - Deaktiviertes Konto -> nicht gezählt, aber ausgewiesen - Domain Users eingetragen -> blanket_permission, keine Expansion - DC nicht erreichbar -> complete=false, Zahl NICHT kleiner gemeldet, Tag fliesst nicht in den Höchststand - Modus count -> keine Kennung im Payload (Payload-Inhalt prüfen) - Salt-Rotation -> alte und neue Pseudonyme nicht verknüpfbar, Bruch im Report ausgewiesen - RemoteDesktop-Modul fehlt -> kein Fehler, Benutzerrecht gilt ``` ## Definition of Done - [ ] Benutzerrecht statt Gruppe, Deny-Recht wird berücksichtigt - [ ] Verschachtelte Domänengruppen ohne RSAT auflösbar - [ ] Breite Berechtigungen erzeugen keine Scheingenauigkeit - [ ] Unvollständige Ermittlung meldet nie eine kleinere Zahl - [ ] Modus `count` überträgt keine Kennungen - [ ] Ergebnis zeigt Herkunft je Berechtigung, nicht nur eine Summe - [ ] Ausschließlich lesende Zugriffe - [ ] Pro Mandant abschaltbar, Default aus, Aktivierung auditiert ## Offene Entscheidungen - Auch andere SPLA-Produkte (SQL Server, Exchange)? #215 liefert die Erkennung. - Login-Gegenprobe aktivieren — und wenn ja, nur als Monatsaggregat? - Umgang mit Administratoren und Dienstkonten: die Einstufung als SAL-pflichtig ist eine Vertragsfrage, die der Agent nicht entscheiden kann. Vorschlag: Ausschlussliste je Mandant, angewandt beim Report, nicht beim Erfassen.

chinux referenced this issue 2026-07-20 23:15:03 +00:00

[MSP] Verbrauchsreport je Mandant + Metrik-Rollup und Retention (Abrechnungsgrundlage) #218

chinux referenced this issue 2026-07-20 23:15:03 +00:00

[MSP] Kundenbericht: Verfügbarkeit und Backup-Erfolg je Mandant und Monat #219

chinux referenced this issue 2026-07-20 23:15:03 +00:00

[MSP] Wartungsfenster und Change-Freeze je Mandant — Voraussetzung für scharfes Auto-Update #220

chinux referenced this issue 2026-07-20 23:15:04 +00:00

[MSP] Alarme als Objekt: Quittierung, Deduplizierung, Eskalation, Bereitschaft, Stummschaltung #221

chinux referenced this issue 2026-07-20 23:15:04 +00:00

[MSP] Restore-Nachweis je Guest — Backups laufen ist nicht Backups funktionieren #222

chinux referenced this issue 2026-07-20 23:15:04 +00:00

[MSP] Vertragliche Zuordnung je Guest (managed / monitored / unmanaged / decommissioning) #223

chinux referenced this issue 2026-07-20 23:15:04 +00:00

[MSP] Kundenblick: reduzierte Mandanten-Ansicht (Positivliste, nach #207) #224

chinux commented 2026-07-20 23:15:04 +00:00

Author

Owner

Copy link

Teil des MSP-Themenblocks: #218, #219, #220, #221, #222, #223, #224, #225. Reihenfolge-Vorschlag: #218 (Datengrundlage) → #223 (Vertragsstatus) → #220 (Wartungsfenster) → #219 (Kundenbericht) → Rest.

Teil des MSP-Themenblocks: #218, #219, #220, #221, #222, #223, #224, #225. Reihenfolge-Vorschlag: #218 (Datengrundlage) → #223 (Vertragsstatus) → #220 (Wartungsfenster) → #219 (Kundenbericht) → Rest.

chinux changed title from [MSP] SPLA/RDS-Nutzungserfassung — Berechtigung statt Logins, Aggregat statt Namen to [MSP] SPLA/RDS: berechtigte Nutzer über SeRemoteInteractiveLogonRight ermitteln (nicht über Remote Desktop Users, nicht über Logins) 2026-07-20 23:28:45 +00:00

chinux commented 2026-07-20 23:28:45 +00:00

Author

Owner

Copy link

Erfassungsansatz überarbeitet. Die erste Fassung wollte die Gruppe Remote Desktop Users zählen — das ist nur der Auslieferungszustand, nicht die Wahrheit.

Maßgeblich ist das Benutzerrecht SeRemoteInteractiveLogonRight. Trägt ein Admin dort eine eigene Gruppe ein, ist die Standardgruppe leer und trotzdem sind alle berechtigt: die alte Fassung hätte in dem Fall null gemeldet.

Neu im Issue:

• SeDenyRemoteInteractiveLogonRight wird mitgelesen (Verweigern gewinnt)
• Verschachtelte Domänengruppen über ADSI + LDAP_MATCHING_RULE_IN_CHAIN statt Get-ADGroupMember — RSAT ist auf RDS-Mitgliedsservern praktisch nie da
• Obergrenze gegen pauschale Berechtigungen (Domain Users o. ä.): melden statt expandieren, blanket_permission setzen
• RDS-Collection-Berechtigung als engere Grenze, wenn eine Farm vorliegt
• Unvollständige Ermittlung meldet nie eine kleinere Zahl — complete: false, Tag fließt nicht in den Monatshöchststand
• Ergebnis zeigt Herkunft je Berechtigung, keine nackte Summe

Login-Ereignisse bleiben nur als Gegenprobe („16 berechtigt / 9 genutzt") — das entschärft nebenbei die BetrVG-Frage, weil ohne Zeitbezug pro Person keine Leistungskontrolle vorliegt.

**Erfassungsansatz überarbeitet.** Die erste Fassung wollte die Gruppe `Remote Desktop Users` zählen — das ist nur der Auslieferungszustand, nicht die Wahrheit. Maßgeblich ist das Benutzerrecht `SeRemoteInteractiveLogonRight`. Trägt ein Admin dort eine eigene Gruppe ein, ist die Standardgruppe leer und trotzdem sind alle berechtigt: die alte Fassung hätte in dem Fall **null** gemeldet. Neu im Issue: - `SeDenyRemoteInteractiveLogonRight` wird mitgelesen (Verweigern gewinnt) - Verschachtelte Domänengruppen über ADSI + `LDAP_MATCHING_RULE_IN_CHAIN` statt `Get-ADGroupMember` — RSAT ist auf RDS-Mitgliedsservern praktisch nie da - Obergrenze gegen pauschale Berechtigungen (`Domain Users` o. ä.): melden statt expandieren, `blanket_permission` setzen - RDS-Collection-Berechtigung als engere Grenze, wenn eine Farm vorliegt - **Unvollständige Ermittlung meldet nie eine kleinere Zahl** — `complete: false`, Tag fließt nicht in den Monatshöchststand - Ergebnis zeigt Herkunft je Berechtigung, keine nackte Summe Login-Ereignisse bleiben nur als Gegenprobe („16 berechtigt / 9 genutzt") — das entschärft nebenbei die BetrVG-Frage, weil ohne Zeitbezug pro Person keine Leistungskontrolle vorliegt.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

fix/vm-agent-update-error

fix/bulk-update-autoclose

security/tenant-scope-108

refactor/dashboard-page-split

fix/rust-agent-parity-features

feat/rust-agent-parity

archive/python-node-agent

Labels

Clear labels   

agent

Node-/VM-Agent

  

bug

Funktionaler Defekt

  

frontend

Svelte/TS Frontend

  

refactor

Umbau ohne Verhaltensaenderung

  

tech-debt

Altlast / Aufraeumen

No labels

agent

bug

frontend

refactor

tech-debt

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

chinux/theProx#225

No description provided.