AD FS-Föderation mit Entra ID: Leitfaden

Von Mirko Peters · 2026-04-30 · Aktualisiert 2026-09-13

Verstehen Sie AD FS-Föderation, SSO, Vertrauensstellungen und Sicherheit. Danach erfahren Sie, wie Sie von AD FS zu Microsoft Entra ID migrieren und welche typischen Probleme bei der Fehlerbehebung auftreten.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Die Föderation mit Active Directory Federation Services (AD FS) spielt eine zentrale Rolle, wenn moderne Organisationen digitale Identitäten und Single Sign-on (SSO) verwalten. Mit wachsenden Unternehmen und sich ändernden Anforderungen, insbesondere durch die Verbreitung von Cloud-Anwendungen und Collaboration-Plattformen, wird das Verständnis von AD FS immer wichtiger. Dieser Leitfaden erklärt, was AD FS leistet, wie es in das größere Microsoft-Ökosystem passt und warum der Wechsel zu modernen Lösungen wie Entra ID und Azure AD die Authentifizierung in Unternehmen grundlegend verändert.

Von grundlegenden Konzepten wie der föderierten Identität bis hin zu detaillierten Migrationsstrategien und Sicherheitsempfehlungen erhalten Sie einen umfassenden Überblick darüber, wie AD FS funktioniert. Außerdem erfahren Sie, worauf Sie bei der Planung eines Umstiegs auf moderne Cloud-Identitäten achten sollten. Ob Sie eine bestehende Umgebung beheben oder einen neuen Ansatz entwerfen: Dieser Leitfaden unterstützt Sie dabei, fundierte Entscheidungen zu treffen und Ihre Authentifizierung zuverlässig abzusichern.

Grundlagen der Active Directory Federation Services

Active Directory Federation Services (AD FS) bildet in vielen Organisationen das Bindeglied zwischen unterschiedlichen Authentifizierungssystemen, besonders wenn lokale Ressourcen und Cloud-Dienste nebeneinander bestehen. Das Grundprinzip ist einfach: Mit föderierter Identität greifen Benutzer auf Anwendungen außerhalb ihrer Heimatumgebung mit ihren gewohnten Anmeldedaten zu. Es geht darum, die digitalen Grenzen zwischen Organisationen und Diensten zu überwinden und den Zugriff für alle Beteiligten sicherer und reibungsloser zu gestalten.

Stellen Sie sich vor, Partner, Dienstleister oder Remote-Teams müssen auf Ihre Systeme zugreifen, Sie möchten aber keine zusätzlichen Benutzernamen und Kennwörter verteilen. AD FS schafft an dieser Stelle „vertrauenswürdige Brücken“, sodass sich diese Benutzer anmelden können, als wären sie im eigenen Netzwerk. Microsoft bietet damit die Antwort auf die alte Frage, wie sich Ressourcen teilen lassen, ohne die Sicherheit aufzugeben. Dafür nutzt AD FS etablierte Standards wie SAML und OAuth.

Wenn Sie gerade erst in die Identitätsföderation einsteigen oder seit Jahren Domänenvertrauensstellungen verwalten, legt dieser Abschnitt die Grundlagen. Wir betrachten, was AD FS tatsächlich leistet, warum es nach wie vor relevant ist und wie es sich mit den Anforderungen von Cloud- und Hybridumgebungen weiterentwickelt hat. Die Details folgen in den nächsten Teilen. Für den Moment gilt: AD FS ist Ihr Ausgangspunkt für sichere, domänenübergreifende Authentifizierung in Microsoft-geprägten Umgebungen.

Was ist Active Directory Federation und wie funktioniert sie?

Active Directory Federation Services (AD FS) ist ein von Microsoft entwickeltes Werkzeug, mit dem sich sichere und nahtlose Authentifizierung über Organisations- und Domänengrenzen hinweg realisieren lässt. Im Kern implementiert AD FS die „föderierte Identität“. Das bedeutet, dass Ihre Benutzer auf Systeme, Apps oder Dienste zugreifen können, die nicht von Ihrer Domäne verwaltet werden, und dabei ihre üblichen Anmeldedaten verwenden. Niemand muss sich also ein Dutzend Kennwörter merken oder zwischen mehreren Anmeldungen wechseln, um zu arbeiten.

Wie funktioniert das? AD FS nutzt branchenübliche Protokolle wie SAML (Security Assertion Markup Language) und OAuth, um vertrauenswürdige Beziehungen herzustellen. Diese werden häufig als „föderierte Vertrauensstellungen“ bezeichnet. Sie bestehen zwischen Ihrer Organisation (dem Identitätsanbieter) und externen Anwendungen oder Partnern (den vertrauenden Beteiligten). Die Besonderheit liegt in der anspruchsbasierten Authentifizierung: Nach der Überprüfung des Benutzers stellt AD FS ein „Sicherheitstoken“ aus, das Ansprüche enthält, also Angaben zur Identität und zu den Berechtigungen des Benutzers. Die Zielanwendung prüft das Token und gewährt den Zugriff, wenn alles stimmt.

Historisch half AD FS großen Unternehmen dabei, Single Sign-on (SSO) sowohl für lokale Anwendungen als auch für Cloud-Ressourcen wie Office 365 bereitzustellen. Damals, bevor cloudnative Verzeichnisse wie Entra ID verbreitet waren, war AD FS die Brücke, die eine reibungslose Authentifizierung auch über Unternehmensgrenzen hinweg sicherstellte. Heute ist es ein grundlegender Baustein für hybride Umgebungen, auch wenn viele Organisationen inzwischen den Weg zu cloudbasierten Identitätslösungen planen, um mehr Flexibilität und Sicherheit zu erreichen.

Kernkomponenten der AD FS-Architektur

• Federation Server: Die zentrale AD FS-Engine, die Benutzer authentifiziert, anspruchsbasierte Token ausstellt und Vertrauensstellungen zu vertrauenden Beteiligten verwaltet.
• Web Application Proxy (WAP): Fungiert als Gateway, bietet sicheren Proxy-Zugriff für externe Benutzer und schützt die Federation-Server vor einer direkten Exposition gegenüber dem Internet.
• Claims Provider: Stellt die Identitätsdaten der Benutzer bereit, die häufig aus Active Directory stammen, und speist sie in die Token-Erstellung und die Ausstellung von Claims ein.
• Relying Party Trust: Repräsentiert die externen Anwendungen oder Systeme, die AD-FS-Token nutzen und validieren; legt fest, wie Claims transformiert werden und welche Benutzer autorisiert sind.
• Domain Controller: Authentifiziert Benutzer gegen Active Directory und bestätigt die Anmeldedaten vor der Token-Ausstellung.

ADFS-Authentifizierungsabläufe und föderiertes Vertrauen im Detail erklärt

Wenn es um Single Sign-on und sicheren Zugriff geht, glänzt AD FS dadurch, dass die Anmeldung für Endbenutzer einfach wirkt, auch wenn die Infrastruktur im Hintergrund alles andere als einfach ist. Das Fundament bilden die Authentifizierungsabläufe und das föderierte Vertrauen von AD FS. Entscheidend ist, Anmeldedaten, Token und Claims sicher und effizient zu übertragen, vom Moment der Anmeldung eines Benutzers bis zu dem Augenblick, in dem er die Zielanwendung oder Ressource tatsächlich erreicht.

Hier zeigt sich der Wert der Details der Protokolle (etwa SAML, WS-Federation und OAuth). Der Ablauf verläuft schnell: Anmeldedaten werden validiert, Claims ausgestellt, Attribute transformiert und die richtigen Token an die richtigen Systeme gesendet. Dabei sorgen föderierte Vertrauensbeziehungen dafür, dass Organisationen auf beiden Seiten der Verbindung sicher sein können, wer durch die digitale Tür kommt.

Als Nächstes zeigen wir den typischen AD-FS-Authentifizierungsablauf Schritt für Schritt und erläutern anschließend, wie föderiertes Vertrauen konfiguriert wird, damit zwei völlig getrennte Organisationen sicheren unternehmensübergreifenden Zugriff ermöglichen können, ohne sich darüber Sorgen machen zu müssen. Wer diese Konzepte versteht, ist für alles gerüstet, vom Aufbau einer sicheren Föderation bis zur späteren Fehlersuche bei hartnäckigen Zugriffs- oder Claims-Problemen.

Die ADFS-Authentifizierungsabläufe im Detail

1. Benutzer greift auf Anwendung zu: Der Benutzer versucht, eine föderierte Anwendung zu öffnen. Handelt es sich um einen externen Zugriff, läuft die Anfrage zunächst über den Web Application Proxy; interne Anfragen gehen direkt an AD FS.
2. Authentifizierungsanfrage gesendet: Die Relying Party der Anwendung leitet den Browser des Benutzers mit einer Authentifizierungsanfrage an den AD-FS-Server weiter. Die Anfrage enthält auch die Angabe, auf welche Ressource der Benutzer zugreifen möchte.
3. Validierung der Anmeldedaten: AD FS fordert den Benutzer zur Anmeldung auf (mit Windows-Anmeldedaten, Formularen, MFA oder Zertifikat) und prüft diese Angaben beim Domain Controller von Active Directory.
4. Erstellung der Claims: Nach erfolgreicher Validierung erstellt AD FS ein claimbasiertes Token. Dieses Token enthält Attribute über den Benutzer, etwa Benutzername, Gruppenmitgliedschaft oder E-Mail-Adresse, und zwar auf Grundlage vorab konfigurierter Regeln.
5. Ausstellung des Tokens: AD FS signiert das Claims-Token sicher und übergibt es an den Browser des Benutzers zurück.
6. Anwendung validiert das Token: Der Browser übergibt das Token an die Zielanwendung, die dessen Echtheit anhand des öffentlichen Teils des AD-FS-Zertifikats überprüft.
7. Zugriff gewährt: Stimmen Token, Claims und Regeln, lässt die Anwendung den Benutzer endlich ein, ohne ein weiteres Passwort abzufragen.

Dieser schrittweise Ablauf funktioniert für typisches SSO, unabhängig davon, ob sich Benutzer intern anmelden oder über einen föderierten Partner kommen. Ähnliche Logik gilt für OAuth (häufig bei SaaS-Anwendungen), wodurch AD FS flexibel eine breite Palette von Authentifizierungsszenarien und Protokollen abdecken kann.

Föderiertes Vertrauen zwischen Organisationen aufbauen

Ein föderiertes Vertrauen in AD FS einzurichten bedeutet, eine Beziehung zu schaffen, in der zwei Organisationen vereinbaren, die Authentifizierungstoken der jeweils anderen zu akzeptieren. Technisch bedeutet das, auf beiden Seiten so zu konfigurieren, dass die andere Seite als vertrauenswürdiger Claims Provider oder Relying Party erkannt wird. Zur Absicherung der Kommunikation werden SSL-Zertifikate ausgetauscht, und benutzerdefinierte Vertrauensrichtlinien legen fest, welche Claims akzeptiert werden und wie Benutzeridentitäten zugeordnet werden.

Eine korrekte Vertrauenskonfiguration bildet die Grundlage für sicheres, nahtloses SSO für Geschäftspartner, Lieferanten oder Tochtergesellschaften und ermöglicht Zusammenarbeit, ohne die Sicherheitsstandards der Organisation zu senken.

Sicherheitsaspekte und Best Practices für die AD-FS-Bereitstellung

Sobald es um Föderation und SSO geht, hat Sicherheit höchste Priorität. Schon eine einzige Kompromittierung oder eine falsch konfigurierte Vertrauensstellung kann sich schnell ausbreiten. Bei AD FS geht es darum, die gesamte Token-Ausstellungskette zu schützen, sicherzustellen, dass sich nur die richtigen Personen authentifizieren können, und Angreifer von Ihren wertvollsten Ressourcen fernzuhalten.

Die Bedrohungslage reicht von Credential Phishing und Token-Diebstahl über Denial-of-Service-Angriffe bis hin zu Brute-Force-Versuchen. Sie benötigen an jeder Stelle starke Abwehrmaßnahmen: von strikten Authentifizierungsrichtlinien über verschlüsselte Token-Flüsse bis hin zu regelmäßigem Patching und Echtzeitüberwachung. Diese mehrschichtige Sicherheit hält nicht nur Angreifer fern. Sie hilft Organisationen auch, Anforderungen aus Audits und Governance zu erfüllen.

In den nächsten Abschnitten stellen wir konkrete Schutzmaßnahmen für AD FS vor, zeigen die häufigsten Angriffsvektoren samt passender Gegenmaßnahmen und fassen bewährte Vorgehensweisen zusammen: für eine sichere Konfiguration, laufende Audits und die Integration in umfassendere Sicherheits- und Governance-Programme. Wenn Sie praxisnahe Strategien zur Risikominderung suchen, auch mit Lektionen aus Microsoft Entra ID- und Azure-Umgebungen, lesen Sie weiter. Und wenn Sie wissen möchten, wie Identität, bedingter Zugriff und Governance in der Cloud zusammenspielen, sehen Sie sich diese Episode zur Sicherheitsstrategie für Identitäten an. Sie bietet vertiefende Einblicke.

Token-Ausstellung und Authentifizierung in AD FS absichern

• Starke Kennwort- und Anmeldeinformationsrichtlinien erzwingen: Legen Sie komplexe Kennwörter und strikte Ablaufregeln fest, um das Risiko schwacher Anmeldeinformationen zu verringern.
• Multi-Faktor-Authentifizierung (MFA) aktivieren: Fügen Sie einen zweiten Bestätigungsschritt hinzu (etwa einen Code per Telefon oder einen Hardware-Token), um unbefugte Anmeldungen zu blockieren, selbst wenn ein Kennwort kompromittiert wurde.
• Sichere, verschlüsselte Token-Kanäle verwenden: Verlangen Sie SSL/TLS für alle Token-Austausche und stellen Sie sicher, dass Tokens signiert und verschlüsselt sind, um Manipulation und Abhören zu verhindern.
• Token-Lebensdauer begrenzen: Verwenden Sie kurzlebige Tokens, um das Zeitfenster für Angriffe zu verkleinern, falls ein Token gestohlen oder erneut abgespielt wird.

Um mehr darüber zu erfahren, wie sich Angriffe verhindern lassen, die sogar MFA umgehen, etwa Missbrauch der OAuth-Zustimmung, lesen Sie diese wesentlichen Kontrollen zur Absicherung von Entra ID.

Wichtige Sicherheitsaspekte und Abwehr von Bedrohungen

• Credential Phishing: Schulen Sie Benutzer darin, Phishing zu erkennen, und verlangen Sie MFA, um bereits beim Anmelden zu schützen.
• Replay und Token-Diebstahl: Verwenden Sie kurze Token-Laufzeiten und kontinuierliche Token-Validierung, um Schäden durch abgefangene Tokens zu begrenzen.
• Denial-of-Service-(DoS-)Angriffe: Betreiben Sie AD FS- und Proxy-Server in Hochverfügbarkeitskonfigurationen und begrenzen Sie die Exposition gegenüber nicht vertrauenswürdigen Netzwerken.
• Patch-Management: Aktualisieren Sie alle AD FS-Server und abhängigen Systeme regelmäßig, um Sicherheitslücken zu schließen, bevor Angreifer sie ausnutzen.
• Audit und Überwachung: Implementieren Sie robuste Protokollierung und Überwachung, um verdächtige Aktivitäten frühzeitig zu erkennen. Einen breiteren Zero-Trust-Ansatz behandelt diese Podcast-Episode zu Zero Trust.

Bewährte Vorgehensweisen für Bereitstellung und Überwachung von AD FS

• Redundanz und Lastverteilung: Betreiben Sie mehrere Föderations- und Proxy-Server, um Single Points of Failure zu vermeiden und hohe Benutzerzahlen zu bewältigen.
• Kontinuierliche Überwachung: Nutzen Sie Überwachungsprotokolle, Ereignisüberwachung und Echtzeitwarnungen, um verdächtige Muster schnell zu erkennen.
• Regelmäßige Sicherheitsaudits: Prüfen Sie Konfigurationen und Vertrauensstellungen auf Abweichungen oder Lücken und halten Sie sich über aktuelle Best Practices auf dem Laufenden.
• Integration in Cloud-Sicherheitsplattformen: Verbinden Sie AD FS-Protokolle und -Ereignisse mit SIEM-Werkzeugen wie Microsoft Sentinel oder Microsoft Purview Audit, um Risiken zentral zu erkennen und Compliance-Berichte zu erstellen.
• Lebenszyklusverwaltung: Aktualisieren Sie Tokens, Zertifikate und Richtlinieneinstellungen regelmäßig, um „Identity Debt“ und technische Risiken zu minimieren.

Einschränkungen von ADFS und Fehlerbehebung in modernen Organisationen

AD FS hat vielen Organisationen in den vergangenen Jahren geholfen, Systeme und Benutzer miteinander zu verbinden. Doch die Technologie bereitet heute einige Kopfschmerzen. Wenn Sie AD FS-Infrastruktur verwaltet haben, kennen Sie das Prozedere: Es fallen Wartungskosten an, Vertrauensstellungen sind komplex konfiguriert, und Updates stehen oft dann an, wenn Sie es am wenigsten erwarten. Kommen schnell wachsende Cloud-Umgebungen hinzu, wirken die alten Methoden schnell veraltet.

Die Einschränkungen sind nicht nur technischer Natur, sie können zu geschäftlichen Risiken werden. Denken Sie an die Zuverlässigkeit der Authentifizierung, daran, wie einfach sich die Lösung skalieren lässt, und wie schnell Sie auf neue SaaS-Anforderungen reagieren können. Diese Schwachstellen bewegen immer mehr Teams dazu, cloudbasierte Identitäten wie Entra ID in Betracht zu ziehen. Bevor Sie jedoch einen großen Schritt wagen, sollten Sie wissen, worauf Sie achten müssen und was zu tun ist, wenn in Ihrer AD FS-Landschaft etwas ausfällt.

Im Folgenden gehen wir auf die wesentlichen Einschränkungen ein, die AD FS für heutige Unternehmen zum Problem machen, und erläutern praxisnahe Schritte zur Fehlerbehebung bei den Problemen, die am ehesten im Helpdesk auftauchen. Wer diese Grundlagen beherrscht, gewinnt wertvolle Zeit und Sicherheit, egal ob Sie den laufenden Betrieb sichern oder sich auf eine Migration vorbereiten.

Wesentliche Einschränkungen von AD FS für die Unternehmensauthentifizierung

• Hoher Wartungsaufwand: AD FS-Bereitstellungen erfordern laufendes Patchen, Überwachung und Hardwarepflege, was die Betriebskosten erhöht.
• Eingeschränkte Cloud-Integration: Legacy-AD FS kann nicht mit der tiefen, nativen Integration mithalten, die Entra ID oder Azure AD für SaaS und cloudnative Sicherheit bieten.
• Komplexe Konfiguration: Multi-Forest- und domänenübergreifende Szenarien bringen mehr bewegliche Teile und mehr Möglichkeiten für Fehlkonfigurationen mit sich.
• Herausforderungen bei der Skalierung: Wachsende Benutzerzahlen oder globale Zugriffsanforderungen erfordern oft zusätzliche Server und aufwendige Netzwerkkonfigurationen.

Fehlerbehebung bei häufigen AD FS-Problemen

1. Authentifizierungsfehler: Prüfen Sie die Berechtigungen des Dienstkontos, die Verbindung zum Domänencontroller und fehlgeschlagene Anmeldeversuche in den AD FS-Ereignisprotokollen (Ereignis-ID 364 weist auf Probleme bei der Token-Ausstellung hin).
2. Fehler bei der Token-Ausstellung: Überprüfen Sie die Anspruchsregeln und die Zertifikatskonfigurationen. Nicht übereinstimmende oder abgelaufene Zertifikate sind häufig die Ursache für Fehler.
3. Fehlkonfigurierte vertrauende Parteien: Überprüfen Sie Endpunkte, Vertrauensstellungen und Anspruchstransformationen auf die korrekte Zuordnung zwischen den Systemen.
4. Kontosperrungen oder Kennwortprobleme: Stellen Sie sicher, dass die Kennwortsynchronisierung und die Kontorichtlinien über alle Gesamtstrukturen und Domänen hinweg konsistent sind.
5. AD FS-Protokolle überwachen: Nutzen Sie relevante Ereignis-IDs (etwa 100 für erfolgreiche Token-Ausstellung oder die 300er-Reihe für Konfigurationsprobleme), um Ursachen schnell einzugrenzen.

Migration von AD FS zu Entra ID und die Zukunft der Föderation

Für Organisationen, die noch auf das alte AD FS setzen und gleichzeitig den Schritt in die Cloud gehen, wird der weitere Weg immer klarer. Cloudbasierte Identitätslösungen wie Azure AD und Entra ID bieten robuste, flexible und sicherere Authentifizierung für moderne Workloads, auch für die alten, eigensinnigen Anwendungen, die bisher ausschließlich auf AD FS angewiesen waren. Die Branche bewegt sich aus gutem Grund in diese Richtung: weniger Hardwareaufwand, einfachere Vertrauensmodelle und Sicherheitskonzepte, die auf sich entwickelnde Bedrohungen und Compliance-Anforderungen ausgelegt sind.

Der Wechsel von AD FS ist jedoch kein Schalter, den man einfach umlegt. Die Migration zu Entra ID (der neuen Markenfamilie für die Identitätsdienste von Microsoft) bedeutet, Vertrauensstellungen, die Anwendungsintegration und die Funktionsweise von Richtlinien wie bedingtem Zugriff und Governance in der neuen Welt neu zu bewerten. Richtig umgesetzt, erzielen Sie eine höhere Zufriedenheit der Benutzer und konsistentere, stärkere Kontrollen über Cloud- und lokale Systeme hinweg.

Im Folgenden finden Sie einen direkten Vergleich von AD FS mit cloudbasierter Identität sowie bewährte Strategien für einen reibungslosen, schrittweisen Übergang, der Benutzer nicht ausbremst und keine neuen Sicherheitslücken öffnet. Wenn Sie einen Eindruck von den Risiken und Governance-Herausforderungen bekommen möchten, die der bedingte Zugriff in Entra ID mit sich bringt, ist dieser ausführliche Beitrag über Identity-Security-Loops ebenfalls ein guter Einstieg.

AD FS vs. cloudbasierte Identität mit Azure AD und Entra ID

• Einschränkungen von AD FS: Hardwareanforderungen vor Ort, Patchen, komplexe Verwaltung von Vertrauensstellungen und Anspruchsregeln, eingeschränkte native Cloud-/SaaS-Integration und langsamere Reaktion auf neue Sicherheitsbedrohungen.
• Vorteile von Azure AD und Entra ID: Native Integration in Microsoft 365, einfachere Einrichtung, integrierter bedingter Zugriff, schnelles Onboarding von SaaS-Anwendungen, einheitlich durchgesetzte Richtlinien und erweiterter Identitätsschutz für Cloud-Workloads.
• Strategische Treiber für die Migration: geringerer Wartungsaufwand, vereinfachte Verwaltung, skalierbarer Zugriff und richtlinienbasierte Sicherheitsmodelle, die mit dem Wachstum des Unternehmens mitwachsen.

Wie sich angesammelte Ausnahmen und Berechtigungen zu „Identitätsschulden“ entwickeln und wie eine saubere Governance in Entra ID die Sicherheit von Cloud-Identitäten verändert, erfahren Sie in diesem Podcast über Identität als Kontrollebene.

Migrationsstrategien für einen reibungslosen Übergang von AD FS zu Entra ID

• Discovery: Erfassen Sie alle Relying-Party-Trusts, Claim-Regeln und integrierten Anwendungen, die mit AD FS verbunden sind. Ordnen Sie die Abhängigkeiten zu und ermitteln Sie Workloads, die bereit für die Migration sind.
• Planning: Entwerfen Sie einen phasenweisen Migrationsplan, richten Sie Entra ID ein und validieren Sie bei Bedarf Cloud-Connectors für die hybride Koexistenz.
• Coexistence: Betreiben Sie AD FS parallel zu Entra ID und verlagern Sie Anwendungen schrittweise auf die Authentifizierung über Azure AD. Überwachen Sie dabei das Benutzererlebnis und die Zugriffsprotokolle.
• Cutover: Migrieren Sie Benutzer und die letzten Workloads zu Entra ID, entfernen Sie veraltete Trusts und benutzerdefinierte Regeln und stilllegen Sie die lokale AD-FS-Infrastruktur, sobald die Validierung abgeschlossen ist.
• Post-Migration Tuning: Überprüfen Sie in Entra ID die Richtlinien für bedingten Zugriff, die Benutzerbereitstellung und das Reporting. So schließen Sie den Kreis und machen Ihre Identitätspraxis zukunftssicher.

Das sollten Sie sich außerdem anhören

Wenn Sie sich mit ADFS-Föderation mit Entra ID beschäftigen, liefern diese Episoden praxisnahe Hintergründe zu Architektur, Sicherheit, Governance und Implementierung:

• Microsoft AI Agent Harness – Simply Explained — Verstehen Sie Orchestrierung, Leitplanken, Evaluierung und zuverlässige KI-Workflows.
• Microsoft Defender XDR – Simply Explained — Verbinden Sie Identitäts- und KI-Entscheidungen mit Sicherheitsüberwachung und Reaktion.
• Microsoft Teams Governance – The Illusion of Control — Erfahren Sie, wie Governance, Verantwortlichkeiten und Richtlinien das betriebliche Risiko reduzieren.
• Azure Virtual Network – Simply Explained — Verstehen Sie den architektonischen Hintergrund der Cloud-Konnektivität.