Ein neuer kostenloser Dienst soll den Umgang mit Mailverschlüsselung unterstützen. Die Webseite “Open Keys” bietet verschiedene Schnittstellen, um (öffentliche) Zertifikate zu Mailadressen zu finden und herunterzuladen. Das kann eine entscheidende Hilfe sein, um Vertraulichkeit bei E-Mail endlich handhabbar zu machen.

Eine wichtige Hürde bei der Mailverschlüsselung ist wenig bekannt: Wenn ich einer anderen Person eine verschlüsselte Mail schicken will, dann muss ich das Mail-Zertifikat dieser Person haben. Nur mit diesem Zertifikat (genauer: mit dem darin enthaltenen Öffentlichen Schlüssel) kann ich die Mail so codieren, dass nur der rechtmäßige Empfänger sie mit seinem Privaten Schlüssel lesbar machen kann. Die Schwierigkeit liegt darin, dass ich also zunächst einmal das Zertifikat der anderen Person auf sicherem Weg erhalten muss. Eine zentrale Stelle, wo ich diese Zertifkate finden kann, gibt es (bislang) nicht.

Open Keys will genau so eine zentrale Instanz bereitstellen. Der Dienst umfasst im Wesentlichen zwei Elemente: Einerseits bindet er (dezentrale) öffentliche Verzeichnisse von Zertifikaten ein und macht sie so über eine zentrale Schnittstelle zugänglich. Andererseits umfasst der Dienst eine eigene Datenbank von Zertifikaten. Beide Quellen lassen sich zentral durchsuchen.

Der Dienst wird von der Firma NetatWork aus Paderborn kostenlos angeboten. Um ihn zu nutzen, muss man dem Unternehmen also vertrauen. Näheres dazu gibt es bei Frank Carius:

[“Open Keys” – Zentrale Quelle für SMIME-Zertifikate]
https://www.msxfaq.de/signcrypt/open_keys.htm

Und hier geht es zu dem Dienst selbst:

[Open Keys]
https://openkeys.de/find

Hat man in einer ADFS-Testumgebung Claim Rules entwickelt und erfolgreich getestet, so will man diese zum Abschluss ins Produktionssystem übertragen. Leider bietet das GUI keine einfache Möglichkeit dazu – dort ist der simpelste Weg, die Claim-Rule-Übersichten nebeneinander zu öffnen und jede Regel einzeln per Copy & Paste zu übertragen. Geht, aber nicht schön.

Natürlich ist das per PowerShell einfacher. Der größte Aufwand besteht darin, herauszufinden, wie das wohl geht. Wie immer bei ADFS ist das ganz gruselig dokumentiert. Daher hier eine kleine Anleitung.

… weiterlesen

Mit seiner neuen Update-Policy für Windows Server 2016 hat Microsoft mal wieder danebengegriffen. Die gerade veröffentlichte “Semi-annual-Version” 1709 enthält nämlich nicht alle Funktionen, die eigentlich im Server vorhanden sein sollten. Schlauerweise betrifft dies ausgerechnet die Hyperconverged-Funktion “Storage Spaces Direct (S2D)”, die ein wichtiges neues Feature des Servers 2016 ist. In den Release Notes zum 1709-Update erklärt Microsoft schlicht:

Storage Spaces Direct is not included in Windows Server, version 1709. If you call Enable-ClusterStorageSpacesDirect or its alias Enable-ClusterS2D, on a server running Windows Server, version 1709, you will receive an error with the message „The requested operation is not supported“.

It is also not supported to introduce servers running Windows Server, version 1709 into a Windows Server 2016 Storage Spaces Direct deployment.

(Quelle: https://docs.microsoft.com/en-us/windows-server/get-started/server-1709-relnotes)

In der ursprünglichen Fassung der Release Notes war das auch schon alles, was man dazu lesen konnte. Das führte nicht nur bei Kunden zu Irritation, sondern auch die Medien schlugen Alarm. Zahlreiche Webseiten meldeten, Microsoft habe seine Hyperconverged-Technik direkt wieder eingestampft und verabschiede sich von dem Markt.

Ein kommunikatives Desaster also – wie so oft. Tatsächlich verhält es sich nämlich ein wenig anders: Microsoft entwickelt die S2D-Technik weiter, hat die neue Fassung aber nicht rechtzeitig zum 1709-Release fertig bekommen. Statt nun die vorhandene Version weiterhin auszuliefern, hat man sich in Redmond entschieden, das Feature vorläufig im 1709-Release abzuschalten. Sobald die neue Version fertig ist, soll sie mit einem späteren Update dann veröffentlicht werden (was sich in der aktuellen Fassung der Release Notes herauslesen lässt).

Ein deutlicheres Signal, dass Microsoft seine eigenen Update-Ambitionen nicht im Griff hat, hätten die Redmonder kaum senden können. Ohnehin haben Kunden und Partner nicht verstanden, wo bei einem Server-Betriebssystem der Vorteil halbjährlicher Versions-Upgrades liegen soll. Die schlechten Erfahrungen mit den Client-Upgrades für Windows 10 scheinen sich also nun tatsächlich auch auf dem Server fortzusetzen.

Oder in Twitter-Kürze: #fail

ADFS enthält eine Regelsprache, mit der sich sehr leistungsfähige Bedingungen formulieren lassen, wann und wie ein Anwender auf eine Web-Applikation zugreifen kann. Einfache Regeln kann man direkt über einen Assistenten aufbauen, mit dem sich schon hilfreiche Dinge anstellen lassen. So kann man AD-Attribute mit anderem Namen weitergeben oder auch einfache Entscheidungen anlegen.

Schwieriger wird es, wenn die gewünschte Regel nicht zu einer der Assistenten-Funktionen passt. An dieser Stelle kommt die Claim Rule Language ins Spiel, die ausgesprochen flexibel ist – aber natürlich, weil das bei ADFS nun mal so ist, nicht besonders gut dokumentiert. Und natürlich gibt es auch keine Entwicklungsumgebung für die Regeln.

Eine Einführung in die Regelsprache muss ich mir auch für später aufheben. Da ich selbst aber jedes Mal wieder suche, hier zum Anfang eine Liste mit hilfreichen Links, die gute Informationen zur Claim Rule Language enthalten.

• [The Role of the Claim Rule Language | Microsoft Docs]
  https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-the-claim-rule-language
• [Understanding Claim Rule Language in AD FS 2.0 & Higher – TechNet Wiki]
  https://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0-higher.aspx
• [AD FS 2.0 Claims Rule Language Primer | Ask the Directory Services Team]
  https://blogs.technet.microsoft.com/askds/2011/10/07/ad-fs-2-0-claims-rule-language-primer/
• [AD FS 2.0 Claims Rule Language Part 2 | Ask the Directory Services Team]
  https://blogs.technet.microsoft.com/askds/2013/05/07/ad-fs-2-0-claims-rule-language-part-2/
• [AD FS 2.0: Selectively send group membership(s) as a claim – TechNet Wiki]
  https://social.technet.microsoft.com/wiki/contents/articles/8008.ad-fs-2-0-selectively-send-group-membership-s-as-a-claim.aspx
• [ADFS Claim to Flatten Groups and Return full DN]
  https://social.technet.microsoft.com/Forums/windowsserver/en-US/ca566e15-4b3b-4830-ae65-e25d83251c07/adfs-claim-to-flatten-groups-and-return-full-dn
• [ADFS: Transforming Claims using Regular Expressions | Southworks Blog]
  http://southworks.com/blog/2012/12/17/adfs-transforming-claims-using-regular-expressions/

Wenn man ADFS einrichtet, um die Anmeldung an Cloud-Applikationen im Unternehmen zu steuern, dann ist vieles an dem System leider ein Blindflug. Insbesondere, wenn man innerhalb von ADFS die Anmeldelogik mit Hilfe von Claims umsetzt (also von Daten aus dem AD oder aus anderen Quellen, die über den Zugriff entscheiden sollen), dann können Fehler in den Regeln dazu führen, dass einfach keine Anmeldung möglich ist. Da wird es dann schwierig, herauszufinden, wo denn der Fehler liegt. Die Meldungen, die der Anwender erhält, sind dabei wenig hilfreich.

Längere Zeit konnte man sich mit einer Claims-Testapplikation behelfen, die Microsoft-Mitarbeiter über ein Blog bereitgestellt haben. Die hat allerdings ihre Tücken, denn nicht nur erfordert sie einen separaten Server, sondern sie ist auch recht haklig aufzusetzen und unterstützt darüber hinaus nur das alte WS-Fed-Protokoll.

Auf der Ignite 2017 hat Microsoft nun endlich einen Dienst vorgestellt, der genau diese Lücke schließen soll. Ähnlich wie bei der genannten Testapplikation handelt es sich um eine Art Dummy-Service, der eine “Anmeldung” per ADFS erlaubt und dann die Details des Anmeldetokens anzeigt. Der kostenlose Dienst namens “Claims X-Ray” unterstützt alle ADFS-Techniken einschließlich SAML 2.0 und OAuth, und er zeigt neben den verarbeiteten Daten des Anmeldetokens auch das Rohformat der übertragenen Daten an.

… weiterlesen

Oder: Warum „Einfach“ nicht immer besser ist

Die Testumgebung

Wer IT-Umgebungen sicher (Hier sowohl als safety & security zu verstehen) betreiben will, kommt an einer Testumgebung nicht vorbei. Eine Testumgebung ist sowohl für neue Produkte wie auch bei Änderungen an bestehenden Systemen von enormer Bedeutung. Letztendlich habe ich nur so eine Chance die Auswirkungen meiner Änderungen zu entdecken bevor ich sie am produktiven Systemen umsetzen muss.

… weiterlesen

Dieser Artikel erschien zuerst auf blog.michael-wessel.de.

Durchs Web geht gerade eine Welle von Berichten, dass die Oktober-Updates für Windows gravierende Probleme verursachen. Konkret scheint es sich um „Delta-Updates“ zu handeln, die sich in vielen Konstellationen fehlerhaft auswirken. Diese Updates sollten eigentlich gar nicht veröffentlicht werden.

Microsoft empfiehlt, diese „Delta-Updates“ nicht auszurollen und nicht zu installieren.

Anscheinend werden diese Delta-Updates über WSUS für Windows 10 und Windows Server 2016 angeboten, möglicherweise aber auch für andere Varianten. Wenn die Fehler sich auswirken, kommt es zu Bluescreens „Inaccessible Boot Device“, weil anscheinend die BCD-Einträge zerstört werden. Microsoft hat die Updates zurückgezogen, sie können aber bereits auf WSUS-Servern im Umlauf sein.

Sollte der Fehler bereits auftreten, so kann schnelles und koordiniertes Handeln ihn beheben – es kommt aber auf die richtige Reihenfolge an. Näheres dazu findet sich in diesem Blog-Artikel:

[Quick Fix Publish: VM won’t boot after October 2017 Updates for Windows Server 2016 and Windows 10 (KB4041691) – Working Hard In IT]
https://blog.workinghardinit.work/2017/10/11/quick-fix-publish-vm-wont-boot-after-october-2017-updates-for-windows-server-2016-and-windows-10-kb4041691/

In einer AD-Migration bei einem Kunden sollten die Quell-OUs der Userkonten in einem freien Attribut gespeichert werden, um nach der Migration bei den Zielobjekten den ursprünglichen Ablageort feststellen zu können. Das folgende PowerShell-Skript erfüllte in der Quelldomäne die Aufgabe.

$Users = Get-ADUser -Filter * -SearchBase 'OU=Benutzer,DC=ad2016,DC=faq-o-matic,DC=net'
foreach ($Account in $Users) {
  $Parent = (([adsi]"LDAP://$($Account.DistinguishedName)").Parent).Substring(7)
  $Account.Name + ': ' + $Parent
  Set-ADUser -Identity $Account.DistinguishedName -Add @{info=$Parent}
}

Am Rande der cim Lingen 2017 hat mich Thorsten Butz für seinen Podcast “Sliding Windows” interviewt. Eine gute Stunde lang haben wir uns über Active Directory unterhalten und neben viel Nostalgie und Historie über Besonderheiten und Seltsamkeiten des Verzeichnisdienstes gesprochen.

[SLW 09: Active Directory mit Nils Kaczenski]
http://www.slidingwindows.de/slw09/

In einem weiteren Artikel auf dem Altaro-Blog stellt Eric Siron einige wichtige Techniken zum Troubleshooting der Live Migration in Hyper-V vor:

[Ultimate guide to Troubleshooting Hyper-V Live Migration]
https://www.altaro.com/hyper-v/troubleshooting-hyper-v-live-migration/