Technische Details

Systemvoraussetzungen

Um LOGINventory installieren zu können, benötigen Sie administrative Rechte auf einer von Microsoft unterstützten Version von Windows (nur x64). Prinzipiell ist kein Windows Server-Betriebssystem notwendig, für den produktiven Betrieb aber empfohlen.

Hardware-seitig empfehlen wir mindestens vier logische Prozessoren, mindestens 8 GB RAM und die Verwendung einer SSD.

LOGINventory benötigt ein vorhandenes Microsoft .Net Framework 4.8 sowie eine Microsoft SQL Server 2012 SP4 Datenbank oder höher.

Natürlich können auch bestehende Datenbanken benutzt werden, die diese Mindest-Anforderungen erfüllen (siehe Datenbank-Konfiguration).

LOGINventory Rechner

Hardware

• Microsoft .Net Framework 4.8 kompatibler PC ab 4 logische Prozessoren
• 4 GB RAM
• 10 GB freier Festplattenspeicher (vorzugsweise SSD)

Betriebssystem

• Windows 10 (x64)
• Windows 11
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022

Software

• Microsoft .NET Framework 4.8
• Visual C++ Redistributable for Visual Studio 2015-2022 x64
• Microsoft PowerShell 4.0 oder später

Infrastruktur

Datenbank

Die Datenbank kann sich auf der gleichen Maschine, wie die LOGINventory-Installation befinden, oder auf einem anderen Rechner.

• Mindestens: Microsoft SQL Server 2012 SP4 oder neuer (alle Editionen)
• Empfohlen: Microsoft SQL Server 2016 oder neuer (alle Editionen)
• LOGINventory Datenbank (enthalten): entspricht SQL Server Express Edition 2019

Rechner mit portablem LMC

Für Rechner, auf denen das portable LMC ausgeführt werden, soll gelten die gleichen Voraussetzungen, wie für den Rechner mit der LOGINventory-Installation. Zusätzlich müssen die Ports 1433 (TCP) und 1434 (UDP) auf dem LOGINventory-Rechner für die zugreifende Maschine geöffnet sein. Eine detaillierte Erläuterung findet sich im Helpdesk.

Gerät, auf dem der Web Viewer aufgerufen wird

Mit jedem modernen Web-Browser kann der Web Viewer aufgerufen werden.

Voraussetzungen zur agentenlosen Erfassung

Auf Grund der agentenlosen Arbeitsweise lassen sich prinzipiell nur Netzwerk-Geräte erfassen, welche eine der folgenden Remote abfragbaren Schnittstellen implementiert haben:

• Windows RPC (WMI, Remote Registry)
• SNMP v1, v2c oder v3
• SSH

Geräte, bei denen dies nicht Fall ist –  wie z.B. Fritz!Boxen, nicht managebare Switches, Windows Home Editions, Fernseher etc. – können auf diese Weise nicht erfasst werden.

Microsoft Exchange:

• Exchange 2010, 2013, 2016, 2019, 2022 (alle Editionen)

Windows Rechner:

• Windows Server 2003 / 2008 / 2012 / 2016 / 2019 / 2022 (alle Editionen)
• Windows XP SP3 / Vista / Windows 7 / Windows 8.x / Windows 10 / Windows 11 (jeweils alle Editionen außer "Home")

Netzwerkgeräte:

• Alle mit SNMP v1, v2c, v3
• Linux/Unix Derivate und MacOS mit SSH und Perl 5.8 oder später
• VMware vCenter ESXi v5.x und höher
• XenServer 4.x oder neuer

CPUs:

• x86 oder x64 Intel-Architektur bei lokaler Datenakquise über LOGINfo
• Beliebig bei Remote Datenaquise (IP-Scan)

Windows Rechner

Remote Scan

Der Remote Scan von Windows Rechnern wird in LOGINventory über eine Definition vom Typ Asset Inventarisierung konfiguriert und ausgeführt.

Die notwendigen APIs sind in Windows Home Editionen nicht vorhanden, bei allen anderen Windows Editionen muss zumindest der Dienst „Server“, bzw. „Datei und Drucker-Freigabe“ gestartet sein und selbstverständlich darf auch keine Firewall die Kommunikation behindern.

In gleicher Domain – oder mit Trust

Der Scan innerhalb der gleichen Domain oder anderer Domains mit Vertrauensstellung (Trust) benötigt als Voraussetzung zusätzlich den Vollzugriff auf Administrative Shares (C$, Admin$, …). Alternativ muss der Dienst "Remote Registry" laufen. Achtung: Dieser Dienst steht ab Windows 10 per Default auf „Deaktiviert“.

In anderer Domain – ohne Trust

Prinzipiell funktioniert der Scan über non-trusted Domain-Grenzen nur, wenn es Vollzugriff auf Administrative Shares (C$, Admin$, …) gibt.

In Workgroup

Bei Workgroup-Rechnern – oder beim Erfassen mittels lokalem Konto des Remote Rechners (auch in Domains):

• UAC-Remote muss abgeschaltet sein, also in der Registry:
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, LocalAccountTokenFilterPolicy (DWORD) muss auf 1 gesetzt werden.
  • Außerdem muss folgende Policy gesetzt sein (z.B. lokal über GPEDIT.EXE), die bei Domain-Mitgliedern immer so gesetzt ist: Computerkonfiguration / Windows-Einstellungen / Sicherheitseinstellungen / Lokale Richtlinien / Sicherheitsoptionen / Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten = Klassisch
  • Diese beiden Policies gelten erst nach einem Policy-Refresh (Reboot + gpupdate /force (bzw. nach 2h))
• Das Kennwort des Remote-Administrators darf nicht leer sein.

Verwendete Ports und Protokolle bei Remote Scan

Verwendet wird zur Erfassung TCP/IP (IPv4 oder IPv6) und:

• ICMP Echo Request (Ping)
• Client für Microsoft Netzwerke
  • TCP Port 139 (NetBIOS Session Services)
  • UDP Ports 137 und 138 (NetBIOS Name Server, NetBIOS Datagram)
  • TCP Ports 135 und 445 (RPC, WMI)
  • Dynamische Ports:
    • Windows Server 2008, Windows Vista und höher: TCP Ports 49152-65535
    • Windows 2000, Windows XP und Windows Server 2003: TCP Ports 1025-5000
• UDP Port 161 (SNMP)
• TCP/UDP Port 22 (SSH)
• TCP/UDP Port 443 (VMware vSphere)

Die Windows Firewall-Konfiguration ist explizit unten beschrieben.

Als Zugriffstest empfohlen:

C:\> NET USE * \\RemotePc-or-IP\Admin$ /USER:Domain\AdminAccount AdminPassword

Und:

C:\> WMIC /NODE:RemotePc-or-IP /USER:Domain\AdminAccount /PASSWORD:AdminPassword CPU

Logon Skript

Bei der Ausführung der Erfassung im Logon- oder Startup-Skript müssen auf dem jeweiligen Rechner keine weiteren Voraussetzungen erfüllt werden. Das ausführende Konto muss lediglich das Recht haben, die bei der Erfassung entstehende .INV Datei im „Datenverzeichnis“ des LOGINventory-Rechners abzulegen, also Schreibrechte auf der Freigabe und im Filesystem haben.

Wir empfehlen: Authenticated Users (= Domain User + Domain Computers) mit Schreibrechten („Change“)

Windows Offline Agent

Mit dem Offline-Agenten können die Inventardaten sowohl über http/https an einen Webserver als auch an eine Datei-Freigabe geliefert werden. Auch hier muss das verwendete Konto Schreibrechte auf der Freigabe und im Filesystem des „Datenverzeichnisses“ haben.

Damit auf einem Windows-Rechner der Offline Agent installiert werden kann, muss das .NET Framework 3.5 vorhanden sein.

Exchange Organisation

Zur Inventarisierung einer komplette Exchange Organisation dient im Remote Scanner der Definitionstyp „Microsoft Exchange Inventarisierung“. Das verwendete Konto benötigt in der Exchange Organisation die Mitgliedschaft in der Rolle „View-Only Organization Management“ oder „Organization Management“. Als Quelle müssen Sie nur einen Exchange Server aus der vorgeschlagen Liste auswählen, und zwar den mit der höchsten Version, jedoch keine Edge-Rolle. Gleichzeitig muss das Konto auf dem Exchange Server Rechner - wie stets bei Windows - lokale Administrator-Rechte besitzen.

VMware vSphere, ESXi

Für VMware ESXi und vCenter gibt es in LOGINventory den Definitions-Typ „VMware vSphere Inventarisierung“.

Das verwendete Konto benötigt hier lediglich „Nur lesen“ Rechte.

Typischerweise erhalten Sie im Job-Monitor beim Erfassen von ESXi oder vCenter eine Nachricht: „Warnung: Ungültiges SSL Zertifikat“ - und zwar dann, wenn Sie die von VMware automatisch erstellten „SelfSigned“ Zertifikate verwenden und noch keine vertrauenswürdige Zertifizierungsstelle verwendet haben. Diese Warnung beeinträchtigt die Inventarisierung nicht.

XenServer

Auch hier wird ein Konto mit Administrator-Rechten auf dem XenServer benötigt.

XenApp Server

Für den Zugriff auf die XenApp-Daten auf einem entsprechenden Windows Server muss das verwendete Konto in der Methode „XenApp Inventarisierung“ sowohl auf Windows als auch auf XenApp Administrator-Rechte besitzen. Außerdem muss auf XenApp-Rechner das Citrix XenApp PowerShell SDK installiert sein (wird in der ISO beim XenApp-Setup mitgeliefert).

Unix, Linux, macOS

Bei der Erfassung von Linux-basierenden Systemen muss unterschieden werden, ob diese remote, also via SSH-Verbindung, oder lokal, also durch Ausführen eines Skripts oder durch den Linux- / macOS-Offline Agenten ausgeführt werden soll.

In beiden Fällen wird eine Perl-Installation und das Perl-Modul Exporter benötigt. (Beim Remote-Scan ist zwar ggf. auch eine Erfassung ohne installiertes Perl möglich, jedoch fehlen viele wichtige Informationen, daher sollte Perl installiert sein.)

In beiden Fällen werden folgende Module / Kommandos empfohlen:

• Die Perl-Module JSON, Parse::EDID (für Monitore auf Linux),Net::IP (für Netzwerkadapter auf macOS), XML::LibXML, XML::LibXSLT, XML::Simple (zum Auslesen von SwidTags).
• dscl (zuletzt angemeldeter Nutzer auf macOS (bei Domain Usern))
• smartctl (verbesserte Laufwerks-Informationen auf Linux)
• lshw (Video-Adapter auf Linux)
• qm (VmGuests auf Linux)

Generell gilt, dass ein höher privilegiertes Konto bessere Informationen liefert, daher sollten nach Möglichkeit für die Erfassung Nutzer mit sudo- oder wheel-Rechten verwendet werden.

Für den Remote-Scan werde zusätzlich folgende Kommandos benötigt:

chmod cp gzip mkdir mv rm rmdir tar

Die Authentifizierung des Benutzers für SSH erfolgt alternativ über Benutzername und Passwort oder Benutzername und Schlüsseldatei sowie Passphrase. Bei manchen Systemen muss die Passwort-Authentifizierung extra freigeschaltet werden, die Authentifizierung über Schlüsseldatei mit Passphrase ist prinzipiell immer möglich. Die Schlüssel-Datei muss dabei im OpenSSH-Format vorliegen, da SSH.NET verwendet wird. PPK-Keys von PuTTY können in dieses Format konvertiert werden.

macOS

Um den Remote-Scan eines Geräts mit macOS zu ermöglichen, muss SSH aktiviert sein. Wählen Sie dazu auf dem Mac Menü „Apple“ > „Systemeinstellungen“ und klicken auf „Freigaben“ . Aktivieren Sie danach „Entfernte Anmeldung“ für das Konto, mit dem der Remote-Scan erfolgen soll.

Wird dem Benutzer das Recht Benutzer darf diesen Computer verwalten gewährt, können detaillierte Informationen zu verbundenen Monitoren und auf dem Gerät vorhandenen Accounts ermittelt werden.

Außerdem muss mindestens macOS 10.15 (Catalina) installiert sein. Ältere macOS / OS X Versionen sind nicht supported.

Die Erfassung von macOS-Geräten kann auch mit Domänenbenutzern / Domänenadministratoren erfolgen. Dazu muss wie folgt vorgegangen werden:

• Einrichtung eines "Netzwerkaccount-Servers"
• Benutzer in der Domäne anlegen
• Lokal am macOS-Gerät mit dem Domänen-Benutzer anmelden (ein "Mobiler Account" muss erstellt werden)
• Wenn nötig dem Benutzer das Recht Entfernte Anmeldung gewähren. Evtl. hat der Benutzer durch eine Gruppenzugehörigkeit das Recht bereits.

SuSe Linux

Zur SSH-Aktivierung müssen folgende Aktionen durchgeführt werden:

• NetServices: sshd enable
• Firewall / Service / SSH-Daemon freigeben

Zur Passwort-Authentifizierung muss in der Datei /etc/ssh/sshd_config der Eintrag geändert werden: PasswordAuthentication no -> yes

Nach einer Änderung ist ein Restart des Systems oder ein Neustart des Daemons notwendig.

Ubuntu Linux

Die Aktivierung des SSH-Daemon muss explizit wie folgt durchgeführt werden:

sudo apt-get install openssh-server

Die Passwort-Authentifizierung ist hier per Default aktiviert.

Red Hat Linux, CentOS

Der SSH-Daemon und die Passwort-Authentifizierung sind hier per Default aktiviert.

Oracle Solaris

Der SSH-Daemon und die Passwort-Authentifizierung sind hier per Default bereits aktiviert. Für die Benutzung der Benutzerkennung »root« muss jedoch die Konfiguration des SSH-Daemon angepasst werden:

• In der Datei /etc/ssh/sshd_config muss der Eintrag für PermitRootLogin auf den Wert yes gestellt werden
• In der Datei /etc/default/login muss der Eintrag für CONSOLE auskommentiert werden: #CONSOLE=/dev/console
• In der Datei /etc/user_attr muss der Eintrag ;type=role aus dem ‚root‘-Eintrag entfernt werden. Dies kann durch folgendes Kommando erfolgen: rolemod –K type=normal root
• Nun muss der SSH-Daemon neu gestartet werden: svcadm restart svc:/network/ssh:default

Fehlersuche beim Scannen von Unix, MacOS und Linux

Falls die Erfassung dieser Geräte nicht erfolgreich ist und die Gründe dafür unbekannt sind, kann mit Hilfe eines Dialogfensters auf Fehlersuche gegangen werden. Dieses Fenster lässt sich öffnen, indem im Knoten Fehlerhafte Inventarisierung die Eigene Aktion "SSH Test" für ein fehlerhaft inventarisiertes Asset aufgerufen wird oder durch Auswahl von "SSH Problembehandlung" im Job Monitor. Öffnen lässt sich das Fenster auch direkt über den Befehl %ProgramFiles%\LOGIN\LOGINventory9\LOGINfoX.exe /w.

In dem sich öffnenden Dialog können dann verschiedene Benutzernamen, Passwörter, Schlüsseldateien, Ports, Timeouts, etc. getestet werden. Anhand der Meldungen ist direkt ersichtlich, inwiefern die Inventarisierung mit diesen Werten und Parametern erfolgreich ist. Wenn die Inventarisierung erfolgreich war, wird der Ergebniscode 20300 ausgegeben.

Drucker, Router, Switches

Diese Geräte werden üblicherweise über die Asset Inventarisierung mittels SNMP v1, v2c oder v3 erfasst. Die SNMP v1/v2c API ist standardmäßig in Windows vorhanden und funktioniert ohne weitere Konfigurationsschritte. Die meisten Drucker haben einen SNMP v1/v2c ReadOnly-Community-String „public“ voreingestellt, mit dessen Verwendung sich die Konfiguration einfach auslesen lässt.

Bei Routern und Switches ist dies meist nicht der Fall und muss dann manuell konfiguriert werden. Wir empfehlen die Verwendung unterschiedlicher Community-Strings, um beim Erfassen bestimmte Geräte-Typen zu selektieren. Angepasst werden müssen eventuell auch die Default View (sollte die OID 1 sein) sowie die IP der zulässigen Management Station(s), also des LOGINventory-Rechners (0.0.0.0 = alle Rechner).

Soll SNMP v3 benutzt werden, kann ein Benutzerkonto vom Typ NetSNMP Credentials dafür verwendet werden. Wie Sie generell die SNMP-Verbindung testen können, ist im Helpdesk beschrieben.

Auslesen von Online-Diensten

Zum Auslesen gewisser Online-Daten von Microsoft (Azure) oder Amazon (AWS) ist es nötig die Authentifizierung nicht mittels Benutzername und Passwort, sondern mit einem modernen Authentifizierungs-Verfahren ("Modern Authentication") durchzuführen. Dafür müssen im entsprechenden Portal eine App-Registrierung angelegt und die erzeugten Zugangsdaten im Remote Scanner hinterlegt werden.

Konfigurieren einer App-Registrierung bei Microsoft Azure

1. Neue App-Registrierung anlegen

• Loggen Sie sich unter portal.azure.com ein und wählen Sie Microsoft Entra ID (früher: Azure Active Directory) aus.
• Navigieren Sie zum Menü App-Registrierungen (App registrations) und legen Sie eine neue Registrierung (New registration) an.
• Vergeben Sie einen aussagekräftigen Namen (z.B. "LOGINventory").

2. Anlegen eines "Client Secret"

• Gehen Sie zum Zertifikate & Geheimnisse (Certificates & secrets)-Menü der gerade angelegten App und wählen Sie Neuer geheimer Clientschlüssel (New client secret)
• Geben Sie eine Beschreibung für Ihren Schlüssel ein, wählen Sie, ob oder wann er abläuft, und wählen Sie Hinzufügen (Add).

• Kopieren Sie den generierten Schlüssel, der nun im Feld Wert (Value) auf dieser Seite zu sehen ist.
  Die Geheime ID (Secret ID) wird NICHT benötigt und muss auch nicht kopiert werden.

3. Berechtigungen der App-Registrierung Anpassen

Falls mit der App-Registrierung auch die Mailboxes eines Online Exchange Servers erfasst werden sollen oder bei Azure Usern auch Daten zur letzten Anmeldung ausgelesen werden sollen, ist eine weitere Zuweisung von Berechtigungen notwendig! Falls dies nicht mit der App-Registrierung gemacht werden soll, kann dieser Schritt übersprungen werden und direkt mit Schritt 4 weitergemacht werden.

Zum Anpassen der Berechtigungen ist jeweils eine Administratorzustimmung ("Admin Consent") nötig.

Exchange Online

Die folgenden Schritte orientieren sich an dieser Anleitung von Microsoft: https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#step-2-assign-api-permissions-to-the-application

• Gehen Sie zur Option Manifest der neu angelegten App-Registrierung.
• Suchen Sie den Abschnitt, der mit requiredResourceAccess beginnt (ca. Zeile 50).
• Ersetzen Sie den bestehenden Abschnitt durch die folgenden Zeilen und speichern Sie danach die Änderung:

"requiredResourceAccess": [
   {
      "resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
      "resourceAccess": [
         {
            "id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
            "type": "Role"
         }
      ]
   }
],

• Gehen Sie zur Option API-Berechtigungen (API permissions) und wählen Sie dort Administratorzustimmung für ... erteilen (Grant admin consent for ...) aus.

Datum der letzten Anmeldung

• Gehen Sie zur Option API-Berechtigungen der neu angelegten App-Registrierung.
• Fügen Sie über das Plus-Zeichen eine neue Berechtigung hinzu. (Add a permission)
• Wählen Sie "Microsoft Graph" und danach "Anwendungsberechtigungen"("Application permissions")
• Tippen Sie ins Suchfenster "AuditLog" ein.
• Wählen Sie "AuditLog.Read.All" aus.
• Bestätigen Sie die Auswahl über den Button Berechtigung hinzufügen (Add permissions).
• Wählen Sie Administratorzustimmung für ... erteilen (Grant admin consent for ...) aus.

4. Rollen Zuweisen

• Navigieren Sie in der Microsoft Entra ID-Konfiguration zu Rollen und Administratoren (Roles and Administrators) und suchen nach der Rolle "Global Reader" (bzw. "Globaler Leser") und klicken Sie auf den Namen der Rolle, um diese auszuwählen.
• Wählen Sie Zuweisungen hinzufügen (Add assignments) und suchen Sie den Namen der zuvor angelegten App-Registrierung (z.B. "LOGINventory") und wählen Sie diese aus.

5. Berechtigung zum Zugriff auf das Abonnement

• Wählen Sie unter portal.azure.com Abonnements (Subscriptions) aus.
• Wählen Sie in der Liste der Abonnements diejenige aus, der die Virtuellen Maschinen in Azure zugeordnet sind.
• Wählen Sie Zugriffssteuerung (IAM) (Access control (IAM)) aus.
• Wählen Sie im Dropdown-Menü bei Hinzufügen (Add) Rollenzuweisung hinzufügen (Add role assignment) aus.
• Klicken Sie auf der Seite Rolle (Role) in die Zeile mit dem Namen Leser (Reader). Daraufhin verschwindet der rote Punkt neben Rolle (Role) und Sie können zur Seite Mitglieder (Members) wechseln.
• Wählen Sie auf der Seite Mitglieder (Members) Mitglieder auswählen (Select members) und suchen Sie den Namen der zuvor angelegten App-Registrierung (z.B. "LOGINventory") und wählen Sie diese aus.
• Auf der Seite Überprüfen und zuweisen bestätigen Sie die Zuweisung dieser App-Registrierung zur Rolle Leser (Reader).

6. Hinterlegen der Zugangsdaten im Remote Scanner

• Legen Sie im Remote Scanner ein neues Konto vom Typ Azure Credentials an und wählen Sie bei Auth. Typ "ClientSecret" aus.
• Bei Tenant ID muss die Tenant ID Ihres Azure Active Directory (Microsoft Entra ID) eingetragen werden. Diese können Sie z.B. hier abrufen:
• Bei Client ID muss die "Application (client) ID" der zuvor angelegten App-Registrierung eingetragen werden. Diese finden Sie auf der Übersichts-Seite der zuvor angelegten App-Registrierung:
• Bei Abonnement-ID muss nur etwas eingetragen werden, falls mit den Zugangsdaten die Virtuellen Maschinen bei Azure erfasst werden sollen, siehe Schritt 5.
  Die Abonnement-ID (Subscription ID) finden Sie unter portal.azure.com bei Abonnements (Subscriptions).
• Tragen Sie bei Client Secret den "Wert" bzw. "Value" des Secrets ein, das Sie unter Schritt 2 angelegt und kopiert haben.
  Erinnerung: Es wird nicht die Client Secret ID, sondern der Wert benötigt!

Die fertige Konfiguration schaut dann z.B. so aus:

Jetzt kann dieses Konto der entsprechenden Definition zugeordnet werden und der Scan gestartet werden. Im Job Monitor kann der Fortschritt der Erfassung beobachtet werden.

Auslesen von Microsoft-Online-Diensten ohne App-Registrierung

Falls die Authentifizierung beim Auslesen mittels Benutzername & Passwort erfolgen soll, ist dies nur möglich, wenn für den verwendeten Benutzer die Mehrfaktor-Authentifizierung (MFA) dekativiert wurde ODER die IP-Adresse des LOGINventory-Rechners von einer "Trusted Location" stammt.

Für die Exchange Online Erfassung kann hier ein User zur Rolle "View-Only Organization Management" hinzugefügt werden, falls der verwendete Account nicht über genügend Rechte verfügt.

Konfigurieren eines Zugriffsschlüssels bei AWS

Für das Auslesen der Informationen zu virtuellen Maschinen bei AWS, ist es notwendig, einen Zugriffschlüssel bei AWS anzulegen, wie in dieser Anleitung beschrieben: https://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/id_credentials_access-keys.html

Im Einzelnen bedeutet dies, dass unter https://us-east-1.console.aws.amazon.com/iamv2/home#/security_credentials ein neuer Zugriffsschlüssel (Access Key) angelegt werden muss.

Wenn hier ein Zugriffschlüssel angelegt wird, muss der Geheime Zugriffsschlüssel (Secret Access Key) nun kopiert werden und im Remote Scanner beim einem Konto vom Typ AWS Credentials gemeinsam mit dem Zugriffsschlüssel hinterlegt werden.

Unterschiede zwischen den Erfassungsmethoden

Je nachdem, ob die Erfassung eines Windows-Geräts mit einem privilegiertem User (lokaler Administrator) oder unprivilegiertem User, bzw. remote oder lokal durchgeführt wird, stehen teilweise unterschiedliche Daten zur Verfügung. Zu ca. 99 % sind die Daten jedoch identisch.

Nur beim Ausnahmefall, wenn der remote-scannede User dem aktuell angemeldeten User des zu scannenden Geräts entspricht, werden auch die verbundenen Netzlaufwerke beim Remote-Scan miterfasst.

Der unprivilegierte Scan unterscheidet sich vom privilegiertem Scan durch den fehlenden Zugriff auf bestimmte Informationen:

• Verschlüsselungsstatus der Partitionen (Bitlocker)
• Einträge aus dem Security-Eventlog (dazu zählen User-Logons)
• Festplatten-Daten zu SMART-Werten und, ob es sich um eine SSD handelt
• TrustedPlatformModule-Werte

Weiterhin gibt es folgende Informationen, die ein unprivilegierter Nutzer jeweils nur teilweise (z.B. die im User-Kontext vorhandenen Werte) ermitteln kann:

• Geplante Tasks
• SQL Server Datenbanken

Für Informationen, die nur im User-Kontext zur Verfügung stehen, ist auf Grund dieses Verhaltens auch eine Bereinigungsfunktion notwendig. Mit der Bereinigung der Veralteten Daten, werden also Kontext-bezogenen Informationen gelöscht, die länger als X Tage nicht mehr erfasst wurden.

Besonderheiten bei der Hypervisor-Erfassung

Bei der Hypervisor-Erfassung (z.B. VMware ESXi, Hyper-V, XenServer) gibt es ein paar Besonderheiten zu beachten.

Auslesen von Informationen

Generell gilt: Die virtuellen Maschinen können sowohl direkt (z.B. durch die Asset-Inventarisierung des entsprechenden IP-Bereichs), als auch durch Abfrage des Hypervisors erfasst werden.

Wenn nur der Hypervisor gescannt wird, dann wird nur dieser als Asset angelegt, sowie alle zum Scan-Zeitpunkt laufenden Maschinen ebenfalls als Asset (diese haben bei LastInventory.Method dann der Wert Stub). Dieses Verhalten lässt sich durch Verwendung des Kommandozeilen-Parameters /StoppedVMs (siehe Schalter) umschalten, was zur Folge hat, dass auch gestoppte VMs als Asset angelegt werden.

Trotzdem können natürlich in jedem Fall bei Doppelklick auf den Hypervisor unter "VM-Gäste" jeweils alle Informationen zu den virtuellen Maschinen (egal ob gestoppt oder nicht) betrachtet werden.

Bestimmte VMs nicht erfassen

Mit Hilfe von Kommandozeilen-Parametern kann eingestellt werden, dass bestimmte VMs nicht erfasst werden.
Dazu kann im Reiter "Allgemein" das Kommandozeilen-Argument //IgnoreVMs "[Name:<NAME>][OperatingSystem:<OPERATINGSYSTEM>]" verwendet werden. Anstelle von <Name> und <OPERATINGSYSTEM> können Namens-Filter unter Verwendung des Wildcard-Zeichens * verwendet werden.

Setzen von Eigenen Eigenschaften

Falls den Hypervisor-Hosts bei der Erfassung direkt eine Eigene Eigenschaft mitgegeben werden soll (analog zur Asset-Inventarisierung), dann ist dies ausschließlich durch Hinzufügen eines entsprechenden Kommandozeilen-Arguments möglich. Die Syntax hierbei lautet ///Custom.Eigenschaft "Wert".

Falls den virtuellen Maschinen auf den Hypervisor-Hosts eine Eigenschaft zugewiesen werden soll, geht das analog mit dem Kommandozeilenargument ///Vm.Custom.Property Wert und findet nur Anwendung, wenn die VMs ausschließlich durch die Erfassung des Hosts gescannt werden. Wenn die VMs direkt gescannt werden, muss mittels ///Custom.Eigenschaft gearbeitet werden.

Installierte Dienste

Bei der Installation von LOGINventory werden verschiedene Dienste mitinstalliert, die unterschiedliche Funktionalitäten bieten.

Falls mehrere Mandanten angelegt werden, werden auch zusätzliche Instanzen der Dienste LOGINventory9 Inventory Service und LOGINventory9 Automation Service angelegt, die jeweils für einen Mandanten gelten. Diese managen dementsprechend die Erfassung und die Durchführung der Tasks.

System-Tasks

Um verschiedene Berechnungen / Optimierungen durchzuführen werden folgende Systemtasks automatisch gestartet:

Zusätzlich gibt es noch eine spezielle Task (keine System-Task): Die Berechnung des Lizenzstatus der Produkte im Lizenzmanagement. Die zugehörige Task befindet sich auf dem Lizenzmanagement-Knoten und kann editiert werden, sodass die Berechnung zu einer anderen Zeit durchgeführt werden kann, als die Standard-Einstellung 02:00 Uhr.

Windows Firewall-Konfiguration

Als Zugriffstest empfohlen:

C:\> NET USE * \\RemotePc-or-IP\Admin$ /USER:Domain\AdminAccount AdminPassword

Und:

C:\> WMIC /NODE:RemotePc-or-IP /USER:Domain\AdminAccount /PASSWORD:AdminPassword CPU

Falls es Probleme bei der Erfassung gibt, empfehlen wir an einem zu scannenden Rechner testweise die Firewall im aktiven Profil abzuschalten und dann den Scan noch einmal laufen zu lassen. Das Deaktivieren der Windows Firewall ist über die Systemsteuerung möglich.

Falls dann das Problem bei der Erfassung behoben ist, sollte die Firewall für alle Rechner dementsprechend konfiguriert werden.

Einfachste Lösung

Über Gruppenrichtlinien kann die Firewall im Domänennetzwerk für alle Rechner deaktiviert werden.

Empfohlene Lösung

Auf allen zu scannenden Rechnern können (manuell oder über Gruppenrichtlinien) entsprechende Regeln definiert werden, die die für den Scan benötigten Verbindungen vom LOGINventory-Server (bzw. für das ganze Server-Subnetz) aus zulassen.

Diese Regel können dadurch hinterlegt werden, dass Sie die Erweiterte Einstellungen der Firewall öffnen:

• Neue Eingehende Regel definieren

• Benutzerdefiniert auswählen; Weiter

• Alle Programme auswählen; Weiter

• Protokolltyp: Alle auswählen; Weiter

• Für welche lokalen IP-Adressen gilt diese Regel? Beliebige IP-Adresse (default)
• Für welche Remote-IP-Adressen gilt diese Regel? Diese IP-Adressen: hier geben Sie die Adresse (oder das Subnet) des LOGINventory Rechners an, z.B.: 192.168.169.170 oder 192.168.169.0/24
• Verbindung zulassen wählen
• Im nächsten Schritt Haken beim Profil Domäne setzen
• Zuletzt muss noch ein Name für die Regel festgelegt werden, z.B.: LOGINventory zulassen

Dies können Sie natürlich auch als Gruppenrichtlinie in der Domain festlegen. Dazu müssen Sie zuerst z.B. auf einem Domain Controller:

• Gruppenrichtlinienverwaltung öffnen
• In die gewüschte OU navigieren
• Gruppenrichtlinienobjekt hier erstellen und verknüpfen (Name z.B. "Firewall") und dieses dann bearbeiten:
• Navigieren Sie zu Computerkonfiguration / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen /Windows-Firewall / Windows-Firewall / Eingehende Regeln und wählen Sie Neue Regel.

Das weitere Vorgehen entspricht dann dem am Anfang dieses Kapitels beschriebenen Ablauf.

Fallback-Methode

Als Fallback-Methode, falls administrative Shares nicht verfügbar sind, können auch über die Remote-Registry Daten erfasst werden. Dazu muss der Dienst "Remoteregistrierung" ("RemoteRegistry") beim Starttyp auf Automatisch oder Manuell gestellt werden.

Dies kann auch zentral über Gruppenrichtlinien unter Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Systemdienste geschehen.

Log-Dateien und Ereignisanzeige

Die einzelnen Module von LOGINventory9 schreiben Log-Informationen in das Verzeichnis %ProgramData%\Login\LOGINventory\9.0.

Über das LOGINventory Data Service Icon in der Taskleiste und über das Ribbon-Menü von LOGINventory unter Extras lässt sich die LOGINventory Ereignisanzeige starten.

Diese beinhaltet ebenso Informationen über den Programmablauf von LOGINventory und kann wertvolle Rückschlüsse auf Fehlerquellen liefern.

Klassenhierarchie "HardwareAsset"

In LOGINventory lassen sich sowohl automatisch scanbare Geräte (=Entität Device) (PCs, Server, Virtuelle Maschinen, Drucker, Switches, Smartphones, etc.), als auch nicht-scanbare Geräte (=Entität PeripheralDevice) (Dockingstations, Tastaturen, Webcams, Headsets, Monitore, Mäuse, etc.) verwalten.

Beide Geräte-Typen sind Datenmodell-seitig von der Klasse HardwareAsset abgeleitet.

Zum HardwareAsset gehören Eigenschaft, wie Name, Info, WarrantyStart, SerialNumber oder InventoryNumber, also Eigenschaften, die sowohl für Device, als auch PeripheralDevice verfügbar sind.

Aufbau von .inv-Dateien

Die erfassten Daten eines Assets werden in .inv-Dateien gespeichert und dann in die hinterlegte Datenbank eingetragen. Eine .inv-Datei ist dabei im Prinzip eine verschlüsselte .xml-Datei. Diese Dateien lassen sich auch selbst erzeugen um beispielsweise mit einem externen Tool Daten in LOGINventory zu schreiben. Dazu kann eine .xml-Datei erstellt und diese dann in .inv umbenannt werden, also z.B. test.inv. Wenn diese Datei ins Datenverzeichnis verschoben wird, wird sie automatisch in die Datenbank eingetragen und in LOGINventory wird ein neues Asset angelegt.

Eine .inv-Datei kann exemplarisch wie folgt aussehen.

<?xml version="1.0" encoding="utf-8"?>

<Inventory xmlns="http://www.loginventory.com/schemas/LOGINventory/data"

    Version="9.0"

    Agent="Notepad" Account="Domain\user"

    Timestamp="2018-11-09T13:47:23Z" Duration="1000" >

<Device xmlns="http://www.loginventory.com/schemas/LOGINventory/data/9.0/LogInfo">

    <NAME>MyAsset8</NAME>

    <ARCHIVED></ARCHIVED>

    <DeviceInfo>

        <SERIALNUMBER>CZ3233TEYP</SERIALNUMBER>
        <ASSETTAG>Asset-CZ3233TEYP</ASSETTAG>

    </DeviceInfo>

    <NETWORKADAPTER>

        <INTERFACEINDEX>1</INTERFACEINDEX>

        <NAME>NIC8</NAME>

        <IP>192.68.200.8</IP>

        <MAC>A0:05:CA:33:A8:AD</MAC>

    </NETWORKADAPTER>

    <OperatingSystem>

        <NAME>Unknown OS</NAME>

        <Version>6.3</Version>

    </OperatingSystem>

</Device>

</Inventory>

Identifikation von Assets mittels Fingerprint

Die Identifizierung der Assets basiert auf einem Fingerprint, der genutzt wird, um zu erkennen, ob es sich um ein bestehendes oder ein bisher nicht erfasstes (= neues) Asset handelt. Dieser Fingerprint ist aus einer Reihe von Device-Eigenschaften (falls vorhanden) zusammengestellt:

Name, LastInventory.Mac, SystemUUID, SerialNumber, AssetTag, DnsHostName, Contact, Description, Location, MachineSid, Operatingsystem.DistinguishedName, MobileDevice.IMEI, MobileDevice.ID

Fast alle genannten Kriterien werden nicht einzeln als eindeutiges Identifikations-Merkmal eines Assets genutzt, sondern in Kombination. Unter gewissen Voraussetzungen kann es jedoch gewünscht sein, das Fingerprint-Verfahren zum umgehen oder abzuändern.

Umgehen des Fingerprint-Verfahrens

Umgehen via CustomID

Das Fingerprint-Verfahren lässt sich dadurch umgehen, dass der Wert CustomID vorhanden ist. Dieser Wert kann entweder folgendem Registry-Wert gelesen werden HKLM\Software\LOGIN\LOGINfo\CustomID oder über die Datei LOGINfo.script gesetzt werden, z.B.: CustomID=%$DeviceInfo.SerialNumber%.

Der erwähnte Registry-Wert ist nicht standardmäßig auf Geräten vorhanden, sondern kann - falls gewünscht - z.B. via Software-Verteilung auf die Geräte gebracht werden. Wir empfehlen jedoch zuvor immer das Testen der Anpassungen "im Kleinen", um sich der möglichen Auswirkungen bewusst zu werden.

Ignorieren von Identifikations-Regeln

Bestimmte Regeln lassen sich deaktivieren. Dazu muss der Name der Regel mit einem Parameter bei der Erfassung des Geräts verwendet werden.

Durch die Verwendung des Parameters IgnoreFingerPrintRules <NAMEDERREGEL> kann eingestellt werden, dass diese Regel ignoriert wird.

Der Parameter sollte - ebenso wie die CustomID - mit Vorsicht wie folgt verwendet werden:

• Asset-Inventarisierung im Remote Scanner: Verwenden des Kommandozeilen-Arguments /IgnoreFingerPrintRules <NAMEDERREGEL>
• Ausführen der LOGINfo.exe: Verwenden des Kommandozeilen-Arguments /IgnoreFingerPrintRules <NAMEDERREGEL>
• VMware-Inventarisierung im Remote Scanner: Verwenden des Kommandozeilen-Arguments /IgnoreFingerPrintRules <NAMEDERREGEL>
• Generelles Ausschalten für alle Windows-, Linux- und Hyper-V-Scans: Hinzufügen des Eintrags !SET IgnoreFingerPrintRules=<NAMEDERREGEL> in der LOGINfo.script-Datei
  Achtung: Dies betrifft nicht die VMware-Inventarisierung

Name

Name der Regel: NameOnly

Insbesondere in Fällen, in denen es in einer Infrastruktur mehrere Geräte (egal ob physische oder virtuelle Maschinen) gibt, die den gleichen Namen tragen, kann es gewünscht sein, dass der Name nicht als Fallback-Matching-Kriterium verwendet wird und somit auch alle anderen Regeln deaktiviert werden, die den Namen nutzen.

Seriennummer

Name der Regel: SerialNumberOnly

Die Identifikation von Asset unter alleiniger Betrachtung der Seriennummer geschieht ausschließlich im Falle des Pre-Stagings, siehe oben.

Diese Regel lässt sich deaktivieren, falls im Zuge des Pre-Stagings ein Asset angelegt wurde, zudem nur die Seriennummer bekannt ist UND zu erwarten ist, dass bei einem demnächst laufenden Scan ein Asset mit genau dieser Seriennummer automatisch erfasst wird, wobei es sich jedoch nicht um das gleiche Objekt handelt, wie zuvor händisch angelegt wurde. Somit sollen also in LOGINventory zwei verschiedene Assets (mit gleicher Seriennummer) bestehen.

Auslesen von Dockingstation-Informationen

Bei der Erfassung von Windows-PCs ist es unter bestimmten Voraussetzungen möglich, Informationen zu verbundenen Dockingstations, darunter Modellbezeichnung, Seriennummer und Firmware-Version auszulesen. So muss jeweils ein bestimmter Treiber auf dem Windows-PC installiert sein, die Dockingstation muss gemäß der Spezifikationen des Herstellers das Auslesen unterstützen, der Windows-PC muss vom gleichen Hersteller stammen, wie die angeschlossene Dockingstation & der Scan muss mit administrativen Rechten ausgeführt werden.

Folgende Hersteller werden dabei unterstützt:

Wenn bei der Erfassung des PCs erfolgreich Dockingstation-Informationen ausgelesen werden konnten, sind diese u.a. nach einem Doppelklick auf das Asset sichtbar:

Falls die Erfassung nicht erfolgreich ist, obwohl die Bedingungen anscheinend erfüllt sind, prüfen Sie, ob mit einer administrativen Powershell auf die Daten gemäß der Beschreibung des Hersteller zugegriffen werden kann. Wenn Sie die Erfassung am lokalen PC testen, stellen Sie sicher, dass die LOGINfo.exe als Administrator ausgeführt wird!

Auslesen fehlgeschlagener Anmeldeversuche

In der Entität UserLogons (Benutzeranmeldungen) werden sowohl erfolgreiche, als auch fehlgeschlagene Anmeldungen / Anmeldeversuche ermittlt. So ist für Windows-Geräte sichtbar, wer sich wann auf diesem Gerät angemeldet hat. Diese Daten stammen dabei stets aus dem Event Log (Windows Ereignisanzeige) des jeweiligen Rechners. Bei fehlgeschlagenen Anmeldungen wird ausschließlich die Event-ID 4625 beachtet.

Falls fehlgeschlagene Anmeldeversuche nicht ausgelesen werden sollen, obwohl Event Log Einträge vorhanden sind, kann bei der Erfassung der Schalter //NoFailedLogons 1 verwendet werden.

Backup / Restore

Generell empfehlen wir stets, die LOGINventory Installation auf einem Windows Server Betriebssystem durchzuführen und die normale tägliche Datensicherung auch hier zu verwenden. In Ausnahmefällen kann die Installation aber auch auf einem Desktop Betriebssystem durchgeführt werden; für diese steht aber normalerweise kein Datensicherungs-Mechanismus zur Verfügung. Für solche Ausnahmefälle, in denen gar kein Backup-Verfahren zur Verfügung steht, liefern wir zwei Batch Dateien mit: Backup-LIV.bat und Restore-LIV.bat. Diese Dateien befinden sich im Unterordner "Resources" im LOGINventory-Installationsverzeichnis. Mit Hilfe dieser Dateien kann eine einfache Datensicherung der LOGINventory Datenbank, Konfiguration und Scandefinitionen durchgeführt werden, falls folgende Voraussetzungen erfüllt sind:

• Es wird die mitgelieferte lokale Datenbank in der Instanz „LOGINventory“ benutzt
• Der Name der Datenbank lautet LOGINventory9
• Der ausführende Benutzer ist lokaler Administrator

Die Datei Backup-LIV.bat führt dann folgendes aus:

• Abfrage des Verzeichnisses, in das gesichert werden soll;
• Die zentralen Konfigurationsdateien LOGINventory.Config und scan.db werden in das o.a. Verzeichnis kopiert;
• Die Datenbank „LOGINventory9“ aus der Instanz „LOGINVENTORY“ wird in das o.a. Verzeichnis gesichert.

Die Datei Restore-LIV.bat führt dann folgendes aus:

• Abfrage des Verzeichnisses, in dem die gesicherten Daten liegen;
• Die zentralen Konfigurationsdateien LOGINventory.Config und scan.db werden aus dem o.a. Verzeichnis zurück kopiert;
• Die Datenbank „LOGINventory9“ aus der Instanz „LOGINVENTORY“ wird aus dem o.a. Verzeichnis restauriert.

Erweiterte Erfassung mittels Kommandozeile

Wenn mittels Remote-Scanner erfasst wird, wird von der GUI aus, abhängig vom Definitions-Typ, eine entsprechende .exe-Datei aufgerufen, die die eigentliche Erfassung durchführt, woraufhin eine .inv-Datei entsteht, in der sich die gesammelten Informationen befinden. Diese .exe-Dateien lassen sich - unter Verwendung der richtigen Parameter - auch direkt über die Kommandozeile oder innerhalb eines Skripts aufrufen.

Die für die Erfassung relevanten .exe-Dateien befinden sich im LOGINventory-Programmverzeichnis (standardmäßig C:\Program Files\LOGIN\LOGINventory9).

Dabei gilt folgende Syntax für die Angabe weiterer Parameter:

...exe [!Target] [DataDir] /USER domain\user password [/AdditionalParameters]

Via ! wird also immer das zu erfassende Gerät mittels FQDN oder IP angegeben - dabei ist zu beachten, dass es nicht zu "conflicting credentials" kommt. Im danach angegebenen Pfad [DataDir] wird die entstehende .inv-Datei abgelegt, die Erfassung wird mit dem bei /USER angegebenen Nutzer ausgeführt und die danach zusätzlich angegeben Parameter beeinflussen die Erfassung zusätzlich.

LOGINfo.exe

Die Verwendung der LOGINfo.exe ist hier bereits ausführlich beschrieben. Die weiteren verfügbaren Schalter werden ebenfalls dort erklärt.

LOGINfoAD.exe

Für die Stand-Alone-Ausführung der AD-Erfassung müssen zusätzliche Dateien aus dem Programmverzeichnis in das Verzeichnis mit der LOGINfoAD.exe kopiert werden:

• EntityFramework.dll
• Essential.Diagnostics.Core.dll
• Essential.Diagnostics.RollingFileTraceListener.dll
• Login.Quiry.dll
• Login.Tasks.dll
• Login.Ventory.Common.dll
• Login.Ventory.Data.dll
• LoginfoAD.exe
• LoginfoAD.exe.config

Durch einen Aufruf der LOGINfoAD.exe wird der Lookup auf diejenige Domain ausgeführt, an die der aktuelle Benutzer angemeldet ist und die resultierenden .inv-Dateien in das gleiche Verzeichnis geschrieben. LOGINfoAD kann prinzipiell nur auf einem Rechner ausgeführt werden, der Domain-Mitglied bei der zu erfassenden Domain ist, oder dazu eine Vertrauensstellung verwenden kann.

So kann die Domain "meine.domain.com" mit dem folgenden Befehl erfasst werden:

LOGINfoAD.exe !meine.domain.com C:\temp

Alternativ kann hinter dem ! auch direkt ein Domain-Controller angegeben werden.

LOGINfoESX.exe

LOGINfoMX.exe

Alle Test-Parameter lassen sich auch mehrfach kombinieren, um verschieden Befehls-Kombinationen bei der Erfassung zu testen. Dies kann nützlich sein, um Fehler oder Probleme zu identifizieren.

Beispiel-Test-Befehl:

LOGINfoMX.exe !exchange2019 C:\Temp /user domain\admin password /test /testmd "echo hallo" /testpowershell "write-output Hallo2" /norpc

LOGINfoX.exe

Aktivieren des Beta-Modus

Ausgewählte neue Funktionen stehen zunächst nur im Beta-Modus zur Verfügung. Um den Beta-Modus Ihrer LOGINventory-Installation zu aktivieren, gehen Sie bitte wie folgt vor.

1. Navigieren Sie mittels Windows Explorer zu dem Verzeichnis, in dem LOGINventory installiert wurde, z.B. C:\Program Files\LOGIN\LOGINventory9
2. Navigieren Sie in den Unterordner Manufacturer
3. Führen Sie die Datei SetBetaMode_On.reg per Doppelklick aus und bestätigen Sie im nächsten Dialog, dass der Vorgang fortgesetzt werden soll.
4. Starten Sie LOGINventory erneut