Im Event mit ID 2887 im Logfile Directory Service, Source Microsoft-Windows-ActiveDirectory_DomainService wird einmal täglich angemeckert wenn sich Clients ohne TLS/SSL oder ohne Signing der Daten verbinden – wenn man dann Diagnostics für LDAP Interface (HKLM/SYSTEM/CurrentControlSet/Services/NTDS/Diagnostics/LDAP Interface=0x2) enabled bekommt pro einem solchen Versuch einen Event mit ID 2889 im gleichen Logfile (Source „LDAP Interface“) wo in den Event-Properties dann Client (Adresse) und benutzter User drin steht, ist daher nett mit Powershell auswertbar:
Invoke-Command (Get-ADDomain).ReplicaDirectoryServers { Get-WinEvent -LogName "Directory Service"|? { $_.Id -eq 2889 }|% { write-output "$($_.TimeCreated): $($_.Properties[0].Value) => $($_.Properties[1].Value)" } }
Skype for Business: File transfer failed for some replica machines
Frontend Server testweise mit Zertifikat von Let’s Encrypt versorgt – ab da Events mit Source LS File Transfer Agent Service und ID 1017:
File transfer failed for some replica machines. Skype for Business Server 2015, File Transfer Agent will continuously attempt to replicate to these machines.
While this condition persists, configuration changes will not be delivered to these replica machines.
Replica file transfer failures: edgeserver.meinedomäne.com: Https request failed.
Details: System.ServiceModel.FaultException: Invalid certificate presented by remote source in cluster frontendserver.meinedomäne.com. Details: No match.
In Anlehnung an diesen Artikel das Zertifikat der Let’s Encrypt Intermediate CA in den Computer Store, Folder „Intermediate Certification Authorities“ importiert, SfB Services restarted und Ruhe kehrt ein.
Event Microsoft-Windows-CAPI2 mit ID 513 bei Backup
Eventtext: Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object. Details: AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol. System Error: Access is denied.
Lösung ist hier beschrieben aber IMHO falsch weil nicht nur der notwendige DACL ACE eingefügt wird sondern auch eine SACL die vorher nicht existiert hat erzeugt wird (startet mit S: in der SDDL).
Daher:
sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)Geht eigentlich nur um das hier: (A;;CCLCSWLOCRRC;;;SU) – vorne das A heißt ALLOW und hinten SU ist das Kürzel für Service Users.
Und gut ists (gilt für Windows Server 2016).
Zertifikat mit CERTUTIL finden und revoken
Die CA Konsole ist jetzt nicht gerade ein Ausbund an Komfort daher macht es Sinn bei wi(e)derkehrenden Tätigkeiten die Commandline zu bemühen, so auch beim Find und Revoken eines Zertifikats.
Finden:
certutil -view -config "meineca.meinfqdn.com\CA Displayname" -out NotBefore,CommonName,RequesterName,SerialNumber -restrict "Issued Common Name=meinzertifikat.meinfqdn.com"
Gibt man bei -out nichts an wird der gesamte Datenbankeintrag gedumped; ganz oben im Output gibt CERTUTIL dankenswerterweise das DB Schema aus, dort findet man dann die gewünschten Felder und deren Kurznamen. Wichtig fürs Revoken ist auf alle Fälle die Seriennnummer.
Revoken:
certutil -revoke -config "meineca.meinfqdn.com\CA Displayname" meineseriennummer 4
Der letzte Parameter (4 im Beispiel) gibt den Grund für das Revoke an, ruft man CERTUTIL -revoke ohne Parameter auf bekommt man alle möglichen Werte präsentiert:
0: CRL_REASON_UNSPECIFIED -- Unspecified (default) 1: CRL_REASON_KEY_COMPROMISE -- Key Compromise 2: CRL_REASON_CA_COMPROMISE -- CA Compromise 3: CRL_REASON_AFFILIATION_CHANGED -- Affiliation Changed 4: CRL_REASON_SUPERSEDED -- Superseded 5: CRL_REASON_CESSATION_OF_OPERATION -- Cessation of Operation 6: CRL_REASON_CERTIFICATE_HOLD -- Certificate Hold 8: CRL_REASON_REMOVE_FROM_CRL -- Remove From CRL 9: CRL_REASON_PRIVILEGE_WITHDRAWN -- Privilege Withdrawn 10: CRL_REASON_AA_COMPROMISE -- AA Compromise -1: Unrevoke -- Unrevoke
BMC/IPMI low level reset
IPMIUTIL gibts zwar auch für Windows, hat aber leider nicht wie IPMITOOL (welches es wiederum nur für Linux gibt) ein spezielles Kommando um den BMC zu resetieren (was, man möge es kaum für möglich halten, echt manchmal notwendig ist weil das Teil einfach abgekackt ist).
In der IPMIUTIL-Doku gibts das CMD Kommando mit dem man raw commands ausführen kann, die notwendigen Parameter sind wie folgt beschrieben:
PARAMETERS
The following parameters are used by icmd. Each is represented as a two-digit hex byte. The parameters have no default values.
bus This byte contains the bus number for this command, usually 00.
rsSa This is the resource slave address, usually 0x20 for the BMC.
netFn/lun
This byte combines the net Function and Lun. The 2 low-order
bits are the Lun and the 6 high-order bits are the net Function.
This representation is consistent with the DOS CMDTOOL/IPMITOOL.
cmd This byte contains the IPMI command.
[data bytes]
This is a sequence of zero to 16 bytes that represent data bytes
specific to this command.
00 20 ist also schon mal klar. netFn/lun ist etwas tricky aber wer sich durch IPMI Spezifikation gewühlt hat wird fündig:
- In Abschnitt 19.3. finden wir den Hinweis dass die mandatory commands mit LUN 0x00 abgesetzt werden müssen.
- In Abschnitt 5.1. finden wir die Network Function Codes, 0x06 ist hier für „App“ definiert
- Im Appendix G finden wir in der Tabelle unter „IPM Device Global Commands“ die Werte für Cold und Warm Reset (0x02 bzw. 0x03) – als NetFn steht dort „App“ (also 0x06 wie wir aus 5.1. wissen)
D.h. wir fummeln 0x00 (LUN) und 0x06 (um 2 Bit geshifted) zusammen, bekommen also binär 0001 1000 = hex 18 für netFn/lun raus.
Alles zusammen sieht das Kommando für einen remote Kaltstart also so aus:
ipmiutil cmd -N meinbmc -U meinuser -P meinpw -V 4 00 20 18 02
(-V 4 brauchen wir weil in der Tabelle in Appendix G ein Kreuzerl bei „A“ steht – und -V 4 heißt „Administrator Level aktivieren“)
Voll easy, ey 😀
Fujitsu iRMC Zertifikat
Wie wir in Supermicro IPMI Zertifikat gelernt haben wollen diverse Linux basierte Oberflächen Zertifikat und private Key im PEM Format:
openssl pkcs12 -in my.pfx -nokeys -out my_cert.pem
openssl pkcs12 -in my.pfx -nocerts -nodes -out my_key.pem
Fujitsu iRMC setzen da aber noch eins oben drauf, der private Key muss auch noch im RSA Format vorliegen, dies kann mit
openssl rsa -in my_key.pem -out my_rsa_key.pem
erledigt werden.
SSL/TLS Schwachstellen testen
Zusammenfassung von https://www.contextis.com//resources/blog/manually-testing-ssltls-weaknesses/
- SSLv2:
openssl s_client –ssl2 -connect example.com:443
- SSLv3:
openssl s_client –ssl3 -connect example.com:443
- Cipher Suites:
nmap --script ssl-enum-ciphers -p 443 example.com
- Zertifikate:
openssl s_client -connect example.com:443 | openssl x509 -noout -text
- Heartbleed:
nmap -p 443 --script ssl-heartbleed --script-args vulns.showall example.com
- Change Cipher Spec:
nmap -p 443 --script ssl-ccs-injection example.com
SCRRUN.DLL / WSHOM.OCX deregistrieren
Wer heute halbwegs vernünftig denken kann disabled Windows Scripting Host (32 Bit Knoten mit selbem Namen gibts auch, also nicht vergessen) – damit kann man zwar CSCRIPT/WSCRIPT/Doppelklick auf .VBS/.JS unterbinden aber ein paar ziemlich nützliche COM-Objekte bleiben übrig und können z.B. von einem Office Makro aus sehr wohl für sehr böse Dinge benutzt werden.
MS hat es gut gemeint und ja seit Windows Vista (vermutlich) alles dem TrustedInstaller übergeben und selbst die Administratoren von ganz schön vielen Teilen des Betriebssystems (etwas halbherzig) ausgeschlossen – d.h. einfach SCRRUN.DLL (Home of Scripting.FileSystemObject, etc.) bzw. WSHOM.OCX (WScript.Shell, etc.) deregistrieren geht nicht mehr (lustigerweise liefert erstere Fehler und macht nix, letztere liefert OK macht aber auch nix).
Wie jeder weiß kann man als Admin den Besitz der TrustedInstaller-owned Files/Registrykeys übernehmen – daher ist eine Deregistrierung der entsprechenden Keys durchaus möglich, ich benutze SetACL für die Besitzübernahme (Script ist für ein 64 Bit System gedacht, deregistriert werden beide Varianten der Objekte):
SetACL.exe -on "HKEY_CLASSES_ROOT\TypeLib\{420B2830-E718-11CF-893D-00A0C9054228}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\TypeLib\{420B2830-E718-11CF-893D-00A0C9054228}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_LOCAL_MACHINE\WOW6432Node\Classed\TypeLib\{420B2830-E718-11CF-893D-00A0C9054228}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_LOCAL_MACHINE\WOW6432Node\Classed\TypeLib\{420B2830-E718-11CF-893D-00A0C9054228}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\Scripting.Encoder" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\Scripting.Encoder" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\Scripting.FileSystemObject" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\Scripting.FileSystemObject" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\Scripting.Dictionary" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\Scripting.Dictionary" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\HTML.HostEncode" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\HTML.HostEncode" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\ASP.HostEncode" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\ASP.HostEncode" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\JSFile.HostEncode" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\JSFile.HostEncode" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\VBSFile.HostEncode" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\VBSFile.HostEncode" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
c:\windows\system32\regsvr32 /u /s c:\windows\system32\scrrun.dll
c:\windows\syswow64\regsvr32 /u /s c:\windows\syswow64\scrrun.dll
SetACL.exe -on "HKEY_CLASSES_ROOT\TypeLib\{F935DC20-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\TypeLib\{F935DC20-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\CLSID\{F935DC22-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\CLSID\{F935DC22-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\CLSID\{F935DC26-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\CLSID\{F935DC26-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\CLSID\{72C24DD5-D70A-438B-8A42-98424B88AFB8}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\CLSID\{72C24DD5-D70A-438B-8A42-98424B88AFB8}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\CLSID\{093FF999-1EA0-4079-9525-9614C3504B74}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\CLSID\{093FF999-1EA0-4079-9525-9614C3504B74}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WScript.Shell" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WScript.Shell" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WScript.Shell.1" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WScript.Shell.1" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WScript.Network" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WScript.Network" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WScript.Network.1" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WScript.Network.1" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{F935DC22-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{F935DC22-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{F935DC26-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{F935DC26-1CF0-11D0-ADB9-00C04FD58A0B}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{72C24DD5-D70A-438B-8A42-98424B88AFB8}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{72C24DD5-D70A-438B-8A42-98424B88AFB8}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{093FF999-1EA0-4079-9525-9614C3504B74}" -ot reg -actn setowner -ownr "n:Administrators" -rec yes
SetACL.exe -on "HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{093FF999-1EA0-4079-9525-9614C3504B74}" -ot reg -actn ace -ace "n:Administrators;p:full" -rec yes
c:\windows\system32\regsvr32 /u /s c:\windows\system32\wshom.ocx
c:\windows\syswow64\regsvr32 /u /s c:\windows\syswow64\wshom.ocx
Remote Desktop Connection Broker: Interner vs. externer Name
Remote Desktop Web Access mit Remote Desktop Connection Broker ist ja eine relativ feine und einfache Sache – nur wird der Connection Broker wenn man von extern zugreift immer mit dem internen Namen angezeigt und man connected auch da drauf (zwar über RDG und dessen externen Namen aber schön ist anders); problematisch ist hier vor allem nebem dem Anzeigeproblem (man will die internen Namen ja nur bedingt zur Schau stellen) auch das Zertfikat – oftmals hat man für die internen Namen keine öffentlichen Zertifikate (sondern eben auch nur interne) und der Benutzer (der ja per Design von internen Zertifikaten und CAs nichts wissen muss) bekommt eine deftige (aber überspringbare) Fehlermeldung vor den Latz geknallt.
Lösung: Den Connection Broker hochverfügbar machen (gerne auch nur mit einem Knoten) – da kann bzw. muss man nämlich einen „Client Access Name“ angeben welcher ziemlich beliebig sein kann (sofern er intern auflösbar ist) – und damit kann man die Zertifikatshürde auch elegant umgehen weil man was nehmen kann was auf ein externes Zertifikat matched; angezeigt wird am Client auch nur der neue/hoffentlich schöne HA Name 🙂
Credits: https://msfreaks.wordpress.com/2013/12/09/windows-2012-r2-remote-desktop-services-part-1/, ich weiß zwar nicht ob das mit der Namensänderung dort Absicht war/ist aber durch den Artikel ist mir klar geworden dass die Namensänderung mit HA machbar ist.
RDWeb: Nutzung RDP Datei ohne RDWeb Auth einschränken
Weil Remote Desktop Web Access (RDWeb) ja nur mit IE wirklich so funktioniert wie Microsoft sich das vorstellt (weil ActiveX zum Zug kommen kann) und bei allen anderen Browsern in Wahrheit nur ein RDP File erzeugt/heruntergeladen/gestartet wird kann man dieses RDP File dann leider für immer benutzen. Zwar muss man sich am RDG und RDSH natürlich anmelden aber eine etwaig im Web Access eingebaute 2FA (siehe hier) geht damit flöten.
Man kann dann den Weg gehen und die Nutzung von RDP Files via ADFS Pre-Authentication grundsätzlich zu verhindern – nur ist das halt ein bisserl weltfremd im Jahre 2017 den IE zu erzwingen (vor allem wenn man auch iOS/Android/macOS bedienen will oder muss), daher habe ich folgenden „Workaround“ ersonnen (und auch erfolgreich implementiert):
Am RDWeb Server ein Verzeichnis erstellen und für die relevanten Benutzer lesend freigeben.
AM RDWeb Server in die login.aspx Seiten nach der OTP Authentication (hier beschrieben) folgendes einbauen (ich habe den Pfad für das Timestampdirectory in einen Parameter in der web.config hinterlegt):
if(bOTPAuthenticated)
{
// NEU: RDP File Start Handling
StreamWriter oWriter=new StreamWriter(ConfigurationManager.AppSettings["OTPAuthenticatedPath"]+"\\"+strOTPUsername.ToUpper());
oWriter.WriteLine(DateTime.Now.AddHours(8).ToString(@"yyyy\/MM\/dd HH:mm:ss"));
oWriter.Close();
// NEU-Ende
if (String.IsNullOrEmpty(strReturnUrlPage))
Response.Redirect("default.aspx");
else
SafeRedirect(strReturnUrlPage);
}
Entweder über lokale Group Policy oder all Users Startup eine Prüfung der Datei (sofern vorhanden) gegen den aktuellen Timestamp und Logoff (oder Meldung + Logoff oder was auch immer), ich habe dafür KIXTART genommen:
$SharePath="\\mein.server.com\MeinTimestampshare$"
IF EXIST($SharePath+"\"+@USERID) = 0
? @USERID+" existiert auf "+$SharePath+" nicht, logoff wird initiiert"
LOGOFF 1
ELSE
? @USERID+" existiert auf "+$SharePath
IF OPEN(3, $SharePath+"\"+@USERID) = 0
$Date=READLINE(3)
IF @ERROR <> 0
? "Timestamp Datei kann nicht gelesen werden, logoff wird initiiert"
LOGOFF 1
ELSE
? "Ablauftimestamp aus Timestamp Datei: "+$Date
$Diff=TimeDiff($Date,"now","m")
? "Zeitunterschied in Minuten: "+$Diff
IF $Diff > 0
? "Ablauftimestamp liegt in der Vergangenheit, logoff wird initiiert"
LOGOFF 1
ELSE
? "Ablauftimestamp liegt in der Zukunft, logon ok"
ENDIF
ENDIF
$dummy=ClOSE(3)
ELSE
? "Timestamp Datei kann nicht geöffnet werden, logoff wird initiiert"
LOGOFF 1
ENDIF
ENDIF
Credits für TimeDiff: https://community.spiceworks.com/scripts/show/599-kixtart-function-timediff