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/

Sucht man nach Details zu dem Windows-Tool robocopy, so stellt man fest: robocopy und die entsprechende Dokumentation (plus Kommentare) scheinen schon seeeehr alt zu sein

In den Kommentaren ist das auch jemandem aufgefallen. Microsoft-Mitarbeiter Ned Pyle antwortete dazu:

It’s a little-known fact that we ported Robocopy from the original MIT/GE/Bell Labs 36-bit Multics operating system released in 1969. Just seemed easier to go with something established, like a time sharing GE-645 mainframe OS.

That, or our blog migration really screwed up old comments.

Quelle: https://blogs.technet.microsoft.com/filecab/2008/07/31/robocopy-mir-switch-mirroring-file-permissions/

In einem lesenswerten Artikel auf dem Altaro-Blog erklärt der Hyper-V-Spezialist Eric Siron die Technik und den Ablauf der Live Migration in Hyper-V:

[A Step-by-step guide to Hyper-V Live Migration]
https://www.altaro.com/hyper-v/a-step-by-step-guide-hyper-v-live-migration/

ADFS arbeitet typischerweise mit einer “klassischen” Benutzeranmeldung über Benutzername und Kennwort. Hierzu wird in der Regel das AD-Konto des betreffenden Anwenders herangezogen. Seit einigen Versionen bietet ADFS allerdings auch eine zertifikatsbasierte Anmeldung für den Anwender. Diese kann an die Stelle der Kennwortanmeldung treten, man kann sie aber auch als zweiten Faktor nutzen.

Bis einschließlich Windows Server 2012 R2 gab es dabei aber eine gravierende Einschränkung: Damit ADFS die Userzertifikate prüfen kann, musste der Client (also der Rechner des Anwenders) eine parallele Verbindung über Port 49443 herstellen. Das war oft nicht möglich, weil dieser Port in vielen WLANs gar nicht ansprechbar ist (z.B. in Hotels). Daher hat Microsoft das Verfahren geändert. In Windows Server 2016 lässt sich die User-Anmeldung per Zertifikat nun über den (ohnehin verwendeten) Standardport 443 durchführen.

Damit das aber gelingt, muss auf dem ADFS-Server der Endpoint “certauth.farmname.tld” erreichbar sein. Schlauerweise trägt dieser einen separaten Hostnamen, sodass dieser auch in dem TLS-Zertifikat für die ADFS-Farm als zusätzlicher Hostname auftauchen muss (Subject Alternate Name).

Details zu den neuen Anforderungen an die ADFS-Konfiguration liefert dieses Dokument:

[AD FS 2016 Requirements | Microsoft Docs]
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-2016-requirements