Um zu erfahren, was hinter einer (UNOFFICIAL-)Signatur von clamav steckt, hilft dieser Befehl weiter:
sigtool --find-sigs MBL_83013055 | sigtool --decode-sigs
Um zu erfahren, was hinter einer (UNOFFICIAL-)Signatur von clamav steckt, hilft dieser Befehl weiter:
sigtool --find-sigs MBL_83013055 | sigtool --decode-sigs
Um die IP eines Druckeranschlusses in Windows auszulesen hilft folgender Powershell Befehl:
Get-Printer -name "*" | %{Get-PrinterPort -Name $_.PortName | Select Name, PrinterHostAddress} >> drucker.txt
Alle Mitglieder einer Gruppe ausgeben:
Get-ADGroupMember -Identity GRUPPENNAME -recursive | sort -property name | ft name
Alle Mitglieder eine OU ausgeben:
Get-ADUser -Filter { Name -Like "*" -and Enabled -eq $true } -Searchbase "OU=accounts,OU=usa,DC=test,DC=com" | Where-Object {($_.name -notlike "test*") -and ($_.name -notlike "*_c1")} | sort name | ft name
Quelle: https://www.antary.de/2014/02/13/alle-user-einer-gruppe-ou-mit-powershell-auslesen/
Trotz fest eingetragener IP-Adresse erhält der Server eine APIPA-Adresse. Das führt dazu, dass der Server nicht (mehr) Netzwerk erreichbar ist.
Lösung:
Als Administrator CMD starten
netsh interface ipv4 show inter
| Idx | Met | MTU | State | Name |
| 1 | 75 | 4294967295 | connected | Loopback Pseudo-Interface 1 |
| 18 | 15 | 1500 | connected | Ethernet |
netsh interface ipv4 set interface 18 dadtransmits=0 store=persistent
Danach den Server neu starten.
Quelle:
https://wsuspraxis.de/windows-server-bekommt-apipa-trotz-fester-ip-adresse/
Das Ausführen des Zertifikate-Snap-Ins unter Windows 10 stürzt ab. Stattdessen muss man über Start -> Ausführen
certmgr
eingeben um die Zertifikate des aktuell angemeldeten Benutzers anzuzeigen bzw. zu verwalten oder
certlm
eingeben um die Zertifikate des lokalen Computers anzuzeigen bzw. zu verwalten.
Schlüssel generieren
openssl req -x509 -newkey rsa:2048 -keyout private.key
Zertifikatsrequest erstellen
openssl req -new -key private.key -out new_csr.csr
CSR auf Windows Zert einreichen und Zertifikat als BASE64 kodiert abspeichern.
PFX inkl. Zertifikatskette erstellen
openssl pkcs12 -export -out cert.pfx -inkey private.key -in ucweb_base64.cer -certfile chain.cer
^[\t ]*\n
Privaten Schlüssel generieren
openssl genrsa -des3 -out <Name_des_Schlüssels>.pem 2048
CSR erstellen
openssl req -new -key <Name_des_Schlüssels>.pem -out <Name_der_Anforderung>.csr
Die Laufzeit der zweistufigen PKI war zu kurz gewählt.
Die Datei %windir%\capolicy.inf auf dem Offline-CA Server anlegen. Inhalt:
[Version] Signature="$Windows NT$" [PolicyStatementExtension] Policies=AllIssuancePolicy Critical=FALSE [AllIssuancePolicy] OID=2.5.29.32.0 [Certsrv_Server] RenewalKeyLength=2048 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=23
Mit dem Befehl auf der Offline-CA
certutil -setreg CA\ValidityPeriodUnits 23
die Laufzeit auf 23 Jahre ändern (doppelte Laufzeit der Sub-CA + 1 Jahr). Anschließend von der Offline-CA das Zertifikat erneuern.
Die Datei %windir%\capolicy.inf auf der Sub-CA anlegen. Inhalt:
[Version] Signature="$Windows NT$" [PolicyStatementExtension] Policies=AllIssuancePolicy Critical=FALSE [AllIssuancePolicy] OID=2.5.29.32.0 [Certsrv_Server] RenewalKeyLength=2048 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=11
Danach die Laufzeit der Zertifikate, die von der Sub-CA ausgestellt werden können, mit dem Befehl
certutil -setreg CA\ValidityPeriodUnits 11
verlängern (doppelte Laufzeit der Zertifikate + 1 Jahr).
Das Zertifikat der Sub-CA erneuern. Befehl:
certutil -renewcert
Die resultierende Datei auf den Offline-CA Server kopieren und mit dem Befehl:
certreq -submit <Pfad zur kopierten Datei von vorher>.req
Auf der Offline-CA den CA Manager starten und in „Ausstehende Anforderungen“ die Anforderung auswählen und per Rechtsklick „Ausstellen“ auswählen (hier die ID merken). Anschließend den Befehl
certreq -retrieve <ID> <Pfad zum ausgestellten Zertifikat>.crt
Den Zertifizierungsdienst stoppen
net stop certsvc
Diese Datei dann auf die Sub-CA kopieren und den Befehl
certutil -installcert <Pfad zum ausgestellten Zertifikat>.crt
ausführen. Das dauert einen Moment. Anschließend den Zertifizierungsdienst wieder starten:
net start certsvc
Es kommt die Fehlermeldung […]AccessDenied[…]. Neben den üblichen Treffern im Internet bzgl. den Pfadangaben für Powershell im IIS könnte es auch an der Proxy-Einstellung liegen. Bei mir konnte das Problem mit netsh winhttp reset proxy behoben werden.
Quelle: Kommentar von „Joel“ auf http://dbanda.blogspot.com/2013/05/problem-with-exchange-2013-management.html