> ## Documentation Index
> Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Empfehlungen für Scans
> Konten mit möglichst geringen Rechten wählen, Aufträge aufteilen, Zeitpläne und Timeouts setzen und Warnungen im Monitoring einordnen.
Ports, Rechte und häufige Probleme beschreibt die Seite des jeweiligen
Scan-Moduls. Konten, die Aufteilung der Aufträge, Zeitpläne, Timeouts und
Warnungen im Monitoring betreffen alle Scan-Module gemeinsam.
## Konten und Rechte
Verwenden Sie je Zweck ein eigenes Konto mit genau den Rechten, die das
Scan-Modul braucht:
| Scan-Modul | Was genügt |
| - | - |
| *Active Directory* | ein Domänenbenutzer, solange das Active Directory im Standard konfiguriert ist; Domänen-Administrator nur für Konfigurationspartition und BitLocker-Schlüssel, oder dafür eine Delegierung |
| *Windows DHCP* | lokaler Administrator auf den DHCP-Servern |
| *Nutanix* | ein Benutzer ohne Rolle – das ergibt die View-Berechtigung |
| *VMware* | Rolle ReadOnly |
| *Proxmox* | Leserechte auf dem Cluster, Benutzer mit Realm |
| *Storage* | Rolle Browse |
| *Cisco Meraki* | API-Schlüssel mit organisationsweiten Leserechten |
| *Oracle Datenbank* | `CREATE SESSION` und `SELECT ANY DICTIONARY` |
| *Microsoft SQL Server* | ohne sysadmin ein eingeschränkter Scan |
| *Microsoft 365*, *Microsoft Intune* | Globaler Administrator nur zum Anlegen der App; die App liest nur |
| *Linux* | ein Benutzer mit `sudo` für genau die Befehle aus `gensudo.sh`, statt `root` |
* **Linux ohne `root`:** Nutzen Sie `sudo` mit der Regel aus `gensudo.sh` oder
die Anmeldung mit privatem Schlüssel. Der Benutzer braucht eine Login-Shell.
* **Dienstkonto des Gateways:** *Active Directory*, *Windows (AD)*,
*Windows DNS*, *Windows DHCP*, *DFS*, *Microsoft SQL Server* und *Hyper-V*
können ohne eigene Anmeldedaten unter dem Dienstkonto des Gateways laufen.
Dann braucht dieses Konto die Rechte. Läuft das Gateway unter dem lokalen
Systemkonto, erreicht es keine Freigaben; der Ordner für den *Dateiimport*
muss dann lokal liegen.
* **Kein MFA für Dienstkonten, die scannen**, etwa bei *Veeam B\&R*. Wo MFA
bleiben muss, scannen Sie per Skript unter dem lokalen Systemkonto.
* **Benutzerkontensteuerung:** Ein lokales Administratorkonto, das nicht der
vordefinierte Administrator ist, bekommt remote keine vollen Rechte. Nehmen
Sie ein Domänenkonto oder setzen Sie `LocalAccountTokenFilterPolicy` – siehe
[Windows inventarisieren](/docs/de/scan/windows#häufige-probleme).
* **Domänenkonten** geben Sie mit Domänenzusatz an: `DOMÄNE\Benutzer` oder
`benutzer@domäne.intern`.
Bei den Scan-Skripten mit `-u` und `-p` – `Discovery-ActiveDirectory.exe`,
`Discovery-Nutanix.exe`, `Discovery-Proxmox.exe`, `Discovery-HPE.exe` – steht
das Passwort im Klartext auf der Befehlszeile und damit in der geplanten Aufgabe
oder im Aufrufskript. Verwenden Sie dafür einen eigenen Benutzer nur mit
Leserechten und schützen Sie die geplante Aufgabe oder das Skript vor fremdem
Zugriff. Bei *Active Directory* nutzen Sie nach Möglichkeit die integrierte
Anmeldung und lassen `-u` und `-p` weg.
Gehören personenbezogene Daten aus dem Active Directory nicht nach
Docusnap365, rufen Sie `Discovery-ActiveDirectory.exe` mit `-noPersonalData`
auf.
## Aufträge aufteilen
* **Große Windows-Umgebungen:** Ab etwa 750 Windows-Systemen kann sich mehr als
ein wiederkehrender *Windows (AD)*-Auftrag lohnen – etwa einer für Server und
Domänencontroller und einer für Arbeitsstationen, oder einer je Standort. Im
Schritt *Scanumfang* schränkt *Auswahl einschränken…* die Systeme ein, mit
Textfilter und *Nur Server*.
* **Standorte und abgeschottete Netze:** Richten Sie je Standort oder VLAN ein
eigenes Gateway ein. Das Gateway vor Ort scannt das lokale Netz; ARP und damit
MAC-Adressen gibt es nur im eigenen Subnetz.
* **Abgeschottete Server**, etwa Backup-Server: Installieren Sie ein Gateway auf
dem Server selbst oder scannen Sie per Skript.
* **Scan-Skript zusätzlich zum Scan über das Gateway:** In Umgebungen ab etwa
750 Arbeitsstationen lassen Sie `Discovery-Windows.exe` per Gruppenrichtlinie
oder Softwareverteilung parallel laufen.
* **DFS** scannen Sie besser per Skript auf den Namespace-Servern. Der Scan über
das Gateway hat dort Grenzen (Double Hop, Replikationsstatus).
## Zeitpläne
* **Windows als wiederkehrender Auftrag**, etwa werktags. Ein wiederkehrender
Windows-Auftrag endet fast immer mit Fehlern, weil einzelne Systeme
ausgeschaltet sind. Sehen Sie die Fehler je System trotzdem regelmäßig durch.
* **Scan-Skripte auf Servern** laufen wöchentlich, etwa am Sonntag;
`Discovery-Windows.exe` auf Arbeitsstationen wöchentlich oder öfter.
* **Switches zu Stoßzeiten scannen.** Switches vergessen gelernte MAC-Adressen
inaktiver Geräte; die Portbelegung ist nur vollständig, wenn die Geräte
laufen.
* **Der Dateiimport-Auftrag** läuft nach den Scan-Skripten, damit er frische
Ergebnisse findet. Er liest alle Ergebnisdateien im Ordner.
Der Dateiimport-Auftrag löscht die Ergebnisdateien nach dem Einlesen. Um sie
zusätzlich aufzubewahren, nutzen Sie den Parameter `-a` des Scan-Skripts im
Ausgabeverzeichnis des Skripts, nicht im Importordner.
Ergebnisse geplanter Aufträge erscheinen erst mit der nächsten
Datenaktualisierung im Inventar: alle 24 Stunden in Pro, alle 12 in Business,
alle 6 in Enterprise. Ein Auftrag mit *Sofort ausführen* überträgt sein Ergebnis
sofort.
## Timeouts
* **SNMP:** *Timeout (ms)* gilt je Ziel und ist mit 2600 vorbelegt. Cisco-Geräte
antworten teils spät. Findet der Scan nicht alle Geräte, erhöhen Sie den Wert.
* **Windows über langsame Leitungen:** Für den Scan eines Windows-Systems gilt
ein Zeitlimit von 10 Minuten. Reicht das über eine langsame Leitung nicht,
stellen Sie das Gateway näher an die Systeme oder scannen das System per
Skript.
## Warnungen im Monitoring
* **IP-Scan:** Ein IP-Scan löst Warnungen aus – durch die Menge an
ICMP-Anfragen und durch bewusst ungültige Pakete, an deren Antwort NMAP das
Betriebssystem erkennt. Die Warnungen weisen nicht auf einen Fehler des Scans
hin.
* **SNMP-Scan:** Ein SNMP-Scan löst ebenfalls Warnungen aus, durch die Menge an
Anfragen.
* **Flooding Protection und Intrusion Protection** können Anfragen verwerfen.
Findet ein ganzer Adressbereich weniger als die einzelnen Adressen, liegt es
meist daran. Richten Sie für das Gateway eine Ausnahme ein.
* **SNMP-Geräte:** Geben Sie den Rechner des Gateways in der Zugriffsliste der
SNMP-Geräte frei, sonst antworten sie nicht.
* **Npcap:** Der Treiber für den IP-Scan greift in den Netzwerkstapel ein und
kann mit Wireshark oder PRTG konkurrieren. Installieren Sie das Gateway
deshalb nach Möglichkeit nicht auf einem Domänencontroller oder
Exchange-Server.
## Scan-Skripte aktuell halten
* **Ablageverzeichnis setzen.** Das Gateway legt die Scan-Skripte dort ab und
ersetzt sie, sobald ein Scan-Modul eine neue Fassung mitbringt. Geplante
Aufgaben, die das Scan-Skript aus diesem Verzeichnis starten, nutzen so immer
die aktuelle Fassung.
* **Kopien außerhalb** des Ablageverzeichnisses, etwa im OneDrive-Ordner oder
auf Linux-Systemen, ersetzen Sie nach einem Update von Hand.
* **`gensudo.sh` erneut ausführen**, wenn sich das Linux-Skript ändert. Die
Befehlsliste kann wachsen.
## Weiterführend
Wie Sie Scan-Skripte verteilen und ihre Ergebnisse einlesen, steht in
[Per Skript scannen](/docs/de/scan/scan-by-script). Ports, Rechte und häufige
Probleme je Scan-Modul stehen etwa in
[Windows inventarisieren](/docs/de/scan/windows),
[Active Directory inventarisieren](/docs/de/scan/active-directory) und
[Netzwerk über SNMP inventarisieren](/docs/de/scan/snmp). Die Datenaktualisierung je
Edition beschreibt [Editionen und ihr Umfang](/docs/de/settings/editions).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.