SMS: Thinclients und Scout erreichen¶
Stand 27.09.2026. Beleg: docs/thinclient-access-2026-09-27.json.
Verifizierter Verwaltungsserver¶
SALZMANN1, 192.168.111.1, Domäne salzmann.lan, Proxmox VM112,
Ninja-Gerät116. Scout Enterprise Server 15.3.1.1595 und Scout-TFTP laufen.
Scout lauscht auf TCP22123/22125; RDP3389 und WinRM5985 sind erreichbar.
Direkter WinRM-Zugriff mit NTLM-Nachrichtenverschlüsselung und PowerShell7.4.14
ist erfolgreich. Kein Jumphost erforderlich.
Vault-Bindung: Kunde sms, System sms-ninja-device-116, CredentialRef
sms-active-directory-schuladmin, Item SMS / ActiveDirectory / Schuladmin.
Nur lanstyle-vault run injiziert SMS_SCHOOL_USER und SMS_SCHOOL_PASS.
Vor Remote-Abfragen Rechnername und Domäne prüfen.
Installation: C:\Program Files\Unicon\Scout. Dort liegen ScoutConsole.exe,
scmd.exe und vncviewer.exe. Für eine interaktive Sitzung ist Scout Console
auf SALZMANN1 der vorhandene Einstieg; dessen Anmeldung wurde nicht getestet.
Verifizierte Vault-Zugänge¶
Die ausdrücklich freigegebene Übernahme aus der historischen SMS-ACP- Passwortdokumentation wurde über die offizielle Bitwarden-CLI durchgeführt. Sechs eindeutige Einträge wurden neu angelegt und per Rücklesen geprüft. Keine bestehenden Einträge überschrieben, keine Zielpasswörter geändert.
SMS / Scout / Manager,sms-scout-manager: von Scout in der Administratorliste akzeptiert. Windows-Transport bleibt der Schuladmin; Scout-Anmeldung erfolgt getrennt. SCP/SSH ist dafür nicht erforderlich.SMS / Futro / VNC,sms-futro-vnc: Anmeldung und geteilte VNC-Sitzung auf vier Geräten verifiziert. TCP5900, Passwort aus diesem Vault-Eintrag.SMS / Futro / Device,sms-futro-device: Gerätepasswort importiert, lokale Konfigurationsentsperrung noch nicht getestet.SMS / Scout / Console,sms-scout-console: Altzugang importiert; der Test mit Windows-Domäne SMS über SCMD war nicht erfolgreich (-16). Nicht als Ersatz für den verifizierten Manager-Zugang verwenden.SMS / Scout Appliance / SSHundSMS / Scout Appliance / Web: importiert, Endpoint unbekannt, nicht gegen andere Systeme getestet.
Die exakten Item-IDs stehen im redigierten Nachweis. Scout nimmt die
Manager-Anmeldung an; Type12-Abfragen bestätigen inzwischen 59 der 60 MACs aus der historischen Unterrichtsliste (Exit0).
Ein Gesamtinventar wurde damit noch nicht nachgewiesen; eine Type12-Abfrage
ohne Attributwert wird von dieser Version mit -1 abgewiesen. Ein Export mit leerer
Root-OU oder / liefert OU not found; dies ist kein Credentialfehler.
Praktischer Einstieg¶
- RDP auf
192.168.111.1(SALZMANN1), Windows-Zugang ausSMS / ActiveDirectory / Schuladmin. Die RDP-Porterreichbarkeit ist geprüft; eine interaktive RDP-Anmeldung wurde in diesem Lauf nicht durchgeführt. C:\Program Files\Unicon\Scout\ScoutConsole.exestarten und den getrennten EintragSMS / Scout / Managerverwenden. Dessen Scout-Rechteprüfung wurde per SCMD erfolgreich getestet.- Gewünschten Client anhand MAC/Name wählen und die Scout-Spiegelung aufrufen.
Spiegelpasswort aus
SMS / Futro / VNC, falls angefordert. - Alternativ direkt mit einem VNC-Viewer an die aktuelle Client-IP, Port5900.
Auf SALZMANN1 ist
C:\Program Files\Unicon\Scout\vncviewer.exevorhanden. Vier direkte Anmeldungen einschließlich ServerInit sind nachgewiesen.
Das separat importierte Gerätepasswort gehört zur lokalen Konfigurationsentsperrung; dessen Gültigkeit ist noch nicht belegt. Vor Wartungsänderungen den konkreten Client und den Konfigurations-Prestate prüfen.
Direkt erreichbare VNC-Kandidaten¶
| Gerät | IP am Prüftag | MAC | Verifikation |
|---|---|---|---|
| 1-126v01 | 192.168.21.248 | 4c:52:62:a6:33:b4 | VNC-Anmeldung und ServerInit erfolgreich |
| 1-114v01 | 192.168.21.246 | 4c:52:62:a6:33:c6 | VNC-Anmeldung und ServerInit erfolgreich |
| 6-304v01 | 192.168.21.122 | 4c:52:62:a6:3c:7b | VNC-Anmeldung und ServerInit erfolgreich |
| 3-PC03 | 10.64.11.164 | 4c:52:62:0f:17:04 | VNC-Anmeldung und ServerInit erfolgreich |
| 3-PC01 | 192.168.20.115 | 4c:52:62:0e:98:e4 | Server meldet laufende andere Verbindungsanfrage |
Die Desktopnamen der vier erfolgreichen Sitzungen enthalten die passende MAC-Adresse. Nur Anmeldung und geteilte Sitzung (ServerInit) ausgeführt; keine Tastatur-/Mausereignisse, kein Neustart, keine Konfigurationsänderung.
Bei 3-PC01 lautet die Serverantwort Another connection is currently being
queried. Auch nach Wartezeit unverändert. Dies beweist kein falsches Passwort.
Vor weiteren Versuchen vorhandene lokale VNC-Abfrage klären; eine eventuell
verlangte Benutzerbestätigung nicht deaktivieren oder umgehen.
SSH22, HTTP80, HTTPS443 und VNC5901 lehnten Verbindungen auf diesen fünf
Zielen ab. 1-207L02/192.168.22.70 bot keinen dieser Ports an.
Alle fünf Geräte sind per exakter MAC in Scout bestätigt: FUTRO S740, eLux RP,
GroupId3. Scout meldet im Feld Version 9.11.0.4; dieses Feld ist nicht
ungeprüft als Betriebssystemversion zu interpretieren. IP vor Wiederverwendung
per UniFi/MAC prüfen.
Die fünf zuerst untersuchten Geräte bezeichnet der Auftraggeber aktuell als Verwaltung.
Sie sind keine Gesamtzahl der Flotte.
Erweiterter Bestand Unterricht und Internat¶
Die ACP-Dokumentation Salzmannschule Schnepfenthal-v24-20250912_165009.pdf
führt im Kapitel „Übersicht der Thinclients RDS Unterricht“ auf Seiten 47 und 49
insgesamt 60 eindeutige MAC-Adressen (Quelldaten vom 08.09.2025).
Am 27.09.2026 wurden 59 davon im laufenden Scout auf SALZMANN1 per exakter
MAC bestätigt: FUTRO S740, eLux RP, gespeicherte OS version 6.3.1-2, GroupId3.
Das ist ein Abgleich dieser Liste, kein vollständiger Export sämtlicher Scout-Geräte.
Dazu gehören beispielsweise 1-010s01 bis 1-010s05 und 1-108s01.
Die Liste umfasst außerdem Internatsgeräte. Die ersten fünf, heute vom
Auftraggeber der Verwaltung zugeordneten Clients sind ebenfalls enthalten;
es sind daher 54 weitere Scout-Treffer, nicht 59 zusätzliche Unterrichtsgeräte.
Die heutige Nutzungszuordnung ist nicht für alle Einträge bestätigt.
Ein historischer Eintrag fehlt in Scout: 1-318s01, MAC 56:50:89:04:00:32.
Vollständiger redigierter Abgleich: docs/thinclients-unterricht-2026-09-27.json. Das Original-PDF enthält an anderer Stelle Zugangsdaten und wird nicht ins Repo kopiert. Sein Hash und die ausgewerteten Seiten sind im Nachweis festgehalten.
Für 58 der 60 Einträge wurden aktuelle oder gespeicherte Adressen auf SSH22 und VNC5900 geprüft. Acht Adressen boten VNC an, darunter die fünf oben:
| Weiterer Kandidat | geprüfte Adresse | Ergebnis |
|---|---|---|
| 8-PC01 | 10.64.11.40 | RFB erreichbar; Sitzung scheitert an lokaler Bestätigungsabfrage |
| 6-204v01 | 192.168.21.245 | RFB beim Porttest erreichbar; späterer Sitzungstest läuft in Timeout |
| 6-105 | 192.168.111.107 | RFB an gespeicherter Scout-IP erreichbar; aktuelle MAC-Bindung und Anmeldung offen |
8-PC01 meldet: The attempt to prompt the user to accept the connection failed.
Dies ist kein Nachweis eines falschen Passworts. Benutzerbestätigung vor Ort
klären, nicht abschalten. Für 6-105 vor Credentialnutzung aktuelle MAC/IP prüfen.
Bei zwei Einträgen wurde kein Porttest durchgeführt: fehlende Adresse bzw.
gespeicherte Adresse inzwischen einer anderen MAC zugeordnet (Details im JSON).
Die Unterrichtsgeräte 1-010s01 bis 1-010s05 und 1-108s01 antworteten an
ihren gespeicherten Adressen nicht auf SSH/VNC. Das beweist weder Ausbau noch
Ausschaltzustand; aktuelle Adresse, Einschaltzustand und Netzpfad vor Ort klären.
Scout-Daten ausgeschalteter oder lange nicht verbundener Geräte können veraltet sein.
Ein separater Unterrichts-Scoutserver oder ein Endpoint zur historischen
Scout-Appliance ist bislang nicht verifiziert. Der bestätigte Verwaltungsweg
für die 59 gefundenen Einträge ist derselbe Scout auf SALZMANN1.
DHCP-Abgleich am 27.09.2026¶
Für alle 60 historischen MACs wurden die UDM-Clientdaten (aktuell und historisch), konfigurierte feste IPs sowie die Windows-DHCP-Scopes, Leases mit allen Zuständen und Reservierungen abgeglichen. Nachweis: docs/thinclient-dhcp-2026-09-27.json.
| Netz | DHCP-Weg laut UDM |
|---|---|
| SMS_Schulnetz, VLAN2020, 192.168.20.0/22 | Relay zu 192.168.111.3 und 192.168.0.245 |
| SMS_Schulserver, VLAN2003, 192.168.111.0/24 | Relay zu denselben beiden Servern |
| SMS_Schulverwaltung, VLAN2005, 192.168.0.0/24 | Relay zu denselben beiden Servern |
| SMS_Schulnetz_Neu, VLAN401, 10.64.8.0/22 | UDM-DHCP, Pool 10.64.8.16–10.64.11.254 |
| SMS_Internat, VLAN400, 10.64.4.0/22 | UDM-DHCP, Pool 10.64.4.100–10.64.7.254 |
SMS-UDC1 (192.168.111.3) und SMS-UDC2 (192.168.111.7) sind in salzmann.lan
autorisierte DHCP-Server. Die Verwaltung verwendet SMS-DC01 (192.168.0.245)
und SMS-DC02 (192.168.0.252) in sms-verwaltung.local.
SALZMANN1 hat keinen DHCPServer-Dienst und dient hier nur als Scoutserver.
Direkte Abfrage über verschlüsseltes WinRM; domänenspezifische Vault-Bindung
im jeweiligen Systemkontext, keine Wiederverwendung zwischen den Domänen.
Auf UDC1 und UDC2 wurden dieselben 16 gültigen dynamische Thinclient-Leases gefunden, alle identisch zur gespeicherten Scout-IP. Fünf Unterrichtsgeräte darunter:
| Gerät | DHCP-Adresse | Lease gültig bis (UTC) |
|---|---|---|
| 1-307s01 | 192.168.22.142 | 30.09.2026 11:34 |
| 1-307s02 | 192.168.22.143 | 30.09.2026 11:25 |
| 1-318s02 | 192.168.22.212 | 28.09.2026 08:10 |
| 1-313s02 | 192.168.23.23 | 30.09.2026 11:25 |
| 1-313s03 | 192.168.23.24 | 30.09.2026 11:25 |
Alle fünf Adressen liefen beim direkten TCP-Test auf 22 und 5900 in Timeout.
Eine gültige Lease belegt die Adresszuordnung, nicht die aktuelle Erreichbarkeit.
Für 1-010s01 bis 1-010s05 und 1-108s01 wurde auf beiden Schul-DHCPs keine Lease gefunden.
Die beiden Verwaltungs-DHCPs liefern ebenfalls keine Leases oder Reservierungen
für die 60 MACs; sie bedienen den Scope 192.168.0.0/24.
Zusätzlich sind 25 Thinclient-Reservierungen in 172.16.11.0/24 bis
172.16.18.0/24 vorhanden. Einige derselben MACs sind inzwischen in 192.168-/10.64-
Netzen beobachtet; der DHCP-Status ActiveReservation allein ist deshalb kein
Beleg aktueller Nutzung. Keiner dieser 25 reservierten Endpunkte antwortete auf
SSH/VNC. Reservierungen und Scopes wurden nicht verändert oder bereinigt.
Die UDM kennt 35 der 60 MACs, davon sechs in der aktuellen Clientliste;
keine der sechs aktuellen IPs weicht von Scout ab. Für keine der 60 MACs war
eine feste UDM-IP konfiguriert. Zwei abweichende historische Beobachtungen
(1-PC03: 10.64.4.168, November2025; 1-122v01: 10.64.4.101, Oktober2025)
sind veraltet und keine bestätigten neuen IPs. Die direkte Route stat/leases
lieferte HTTP404; die UDM-Prüfung beruht auf Clientdaten und Netzkonfiguration,
nicht auf einer vollständigen rohen DHCP-Leasedatei.
Scout-Status-, Kontakt- und Versionsprüfung am 27.09.2026¶
Nachweis: docs/thinclient-scout-status-2026-09-27.json.
SCMD Type12 bestätigt für alle 59 gefundenen Clients eLux RP 6.3.1-2,
Image recovery.idf, Container UC_RP6_X64. Auf den fünf fokussierten
Unterrichtsgeräten meldet Scout BIOS V5.0.0.13 R1.10.0 for D3544-A1x.
Scout Server selbst läuft mit 15.3.1.1595.
Die aktuell gespeicherten Felder Status, LastContact, StatusModified und
Updatezeit/-ergebnis konnten nicht direkt ausgelesen werden: Diese
SCMD-Version liefert sie nicht, und die zusätzliche lesende SQL-Verbindung
mit Windows-Authentifizierung wurde von der Scout-LocalDB abgewiesen.
Keine Rechte geändert und keine Datenbank-Credentials aus Konfigurationen extrahiert.
Der aktuelle Serverlog eluxd.log enthält für die fünf Geräte zuletzt die
folgenden TerminalUp-/TerminalDown-Ereignisse. Zeiten in Europe/Berlin
(MESZ); das Logformat yyyyMMdd HHmmss und der Vergleich von letzter
Logzeile mit Dateizeit belegen lokale Serverzeit (UTC+2 am Prüftag).
| Gerät | Letztes TerminalUp in ausgewerteten jüngsten Treffern | Letztes TerminalDown |
|---|---|---|
| 1-307s01 | 22.09.2026 13:34:04 | 22.09.2026 13:36:16 |
| 1-307s02 | 22.09.2026 13:25:05 | 22.09.2026 14:07:46 |
| 1-313s02 | 22.09.2026 13:26:01 | 22.09.2026 14:04:59 |
| 1-313s03 | 22.09.2026 13:25:07 | 22.09.2026 14:08:06 |
| 1-318s02 | 22.09.2026 13:37:24 | 22.09.2026 14:08:38 |
Danach keine weiteren MAC-/IP-/Namenstreffer zu diesen Geräten im aktuellen
Serverlog (Datei zuletzt am 27.09.2026 09:31:48 MESZ geschrieben).
Das spricht zusammen mit den erfolglosen Ping-/SSH-/VNC-Prüfungen für offline;
es ist ausdrücklich kein ausgelesener aktueller Scout-Konsolenstatus und kein
exakter Wert des Datenbankfelds „Last contact“. disconnected allein bezeichnet
einen Verbindungsabschluss, nicht zwingend das Ausschalten eines Geräts.
Die Herstellerfreigabe für eLux RP 6.3.1 stammt vom 14.09.2018:
Unicon Releaseinformation.
Der gespeicherte Betriebssystemstand gehört damit zu einer acht Jahre alten
Versionsfamilie. Dies ist kein Nachweis, wann zuletzt ein Paket oder Firmware
aktualisiert wurde. Datum/Ergebnis des letzten Geräteupdates und ausstehende
Updateaufträge bleiben unbestätigt. recovery.idf ist hier der Image-Dateiname;
daraus weder Recovery-Modus noch Updatefehler ableiten.
Vor einem Update den unterstützten Migrationspfad, Scout-/eLux-Kompatibilität, FUTRO-S740-Hardwarefreigabe und eingesetzte RDP-/Citrix-Anwendungen prüfen; zunächst ein erreichbares Pilotgerät mit gesichertem Prestate und Rückweg. In diesem Lauf wurden keine Updates oder Konfigurationsläufe ausgelöst.
Wiederholbarer Prüfweg¶
- UniFi-System
sms-unifi-networkmit gebundenersms-unifi-network-apiausschließlich lesend abfragen; aktuelle Client-IP zur MAC auflösen. - Direkte TCP-/RFB-Prüfung am ausgewählten Client. Keine flächigen Passwortversuche.
- Scoutserver per WinRM und PowerShell7 prüfen: Identität, ScoutServer-Dienst,
Dateiversion und Listener. Für SCMD den getrennten, verifizierten
sms-scout-managerverwenden. - Bekannte MACs mit SCMD-Type12 abfragen: INI mit
[FileInfo],Type=12,[Setup],AttributeKey=MAC_address,AttributeValueString=<MAC ohne Trennzeichen>. Mehrere INI-Dateien lassen sich in einem SCMD-Aufruf abfragen. Nur benötigte Ergebnisfelder übernehmen; keine unredigierten SCMD-Debugausgaben protokollieren. - Mit passendem Scout-Zugang Gerätebestand lesen; anschließend einen Client über Scout spiegeln. Ein eventuell verlangtes Spiegelpasswort und eine Benutzerbestätigung gesondert beachten.
Die Herstellerdokumentation beschreibt TCP5900 als eLux-Spiegelung und erlaubt Konfigurationen mit eigenem Spiegelpasswort, Benutzerbestätigung oder Beschränkung auf Scout. Ein offener VNC-Port beweist daher keinen bedienbaren Desktop. Quellen: eLux-Ports, Spiegelung konfigurieren, SCMD starten.
Rückweg: Keine Zielkonfiguration geändert. Dokumentation per normalem Git-Revert zurücknehmen; neu importierte Vault-Einträge anhand der sechs protokollierten Item-IDs gezielt entfernen, sofern sie noch nicht anderweitig verwendet werden. Die bestehende Quelle bleibt unverändert und wird nicht ins Git übernommen.