Konfigurieren Sie Anspruchsregeln für eine bessere Office 365-Zugriffssteuerung

Der größte Vorteil besteht darin, dass Unternehmen die mit ihnen verbundenen Kennwörter und Richtlinien steuern können. Clientzugriffsrichtlinien sind eine gute Wahl für Organisationen, die eine differenzierte Kontrolle über die Authentifizierung von Benutzern über Active Directory-Verbunddienste für den Zugriff auf Office 365 wünschen. Diese Art der Kontrolle kann für einige Organisationen sogar eine entscheidende Rolle spielen.

Sobald Sie mit was vertraut sind Active Directory-Verbunddienste (AD FS) Clientzugriffsrichtlinien sind und wie Sie sie verwenden, können Sie untersuchen, wie Sie diese Richtlinien verwenden.

Nachdem Sie AD FS für konfiguriert haben Büro 365wird eine Standard-Anspruchsregel aufgerufen Zugriff auf alle Benutzer zulassen wird existieren. Diese Regel generiert ein Token für alle erfolgreich authentifizierten Benutzer.

Öffnen Sie zum Anzeigen der Anspruchsregel die AD FS-Verwaltungskonsole und navigieren Sie zu Vertrauensstellungen für vertrauende Parteien. Klicken Sie mit der rechten Maustaste auf Microsoft Office 365-Identitätsplattform und dann auswählen Anspruchsregeln bearbeiten. Klicken Sie im neuen Fenster auf Ausstellungsautorisierungsregeln Registerkarte (Abbildung 1).

Wie Sie dem Screenshot entnehmen können, haben wir bereits eine neue Anspruchsregel erstellt. Diese Anspruchsregel, die wir analysieren werden, verwendet die Gruppenmitgliedschaft eines Benutzers, um zu bestimmen, ob ein Token generiert wurde. In diesem Fall, wenn das Benutzerkonto Mitglied einer angerufenen Gruppe ist NoADFSAccessEs wird kein Token generiert und der Benutzer wird nicht für Office 365-Dienste authentifiziert.

Es ist jedoch wichtig zu verstehen, wie Anspruchsregeln verarbeitet werden. Wenn sich ein Benutzer authentifiziert, verarbeitet der AD FS-Server die Regeln in der Reihenfolge ihrer Priorität. Wenn eine Übereinstimmung gefunden wird, wird entweder ein Token erstellt (wenn die Aktion auf “Zulassen” gesetzt ist) oder der Zugriff verweigert (wenn die Aktion auf “Verweigern” gesetzt ist). Es findet keine weitere Verarbeitung statt, wenn eine Übereinstimmung gefunden wird. In diesem Beispiel ist es wichtig, dass die benutzerdefinierte Anspruchsregel zuerst verarbeitet wird. Andernfalls würde für jeden Benutzer unabhängig von seinem NOADFSAccess-Gruppenmitgliedschaftsstatus ein Token generiert.

Verwenden Sie die Gruppenmitgliedschaft, um den Office 365-Zugriff einzuschränken

Benutzerdefinierte Ansprüche können auf zwei Arten generiert werden. Sie verwenden entweder die GUI-basierter Assistent, der die entsprechende Anspruchsregelsprache für Sie erstellt, oder Sie schreiben Ihre eigene Anspruchsregel.
Persönlich bevorzuge ich es, den Assistenten zu verwenden, wenn dies möglich ist, da er den Fehlerbereich verringert und einfacher ist. Leider unterstützt der Assistent die Erstellung bestimmter erweiterter Anspruchsregeln nicht. In diesem Beispiel verwenden wir einen Windows Server 2012 R2-basierten AS FS-Server.
Von dem Anspruchsregeln bearbeiten Fenster, klicken Sie Anspruch hinzufügen und folgen Sie diesen Schritten.
1. Stellen Sie sicher, dass Sie auswählen Benutzer aufgrund eines eingehenden Anspruchs zulassen oder verweigern und klicken Sie auf Nächster (Figur 2).

Benutzer aufgrund eines eingehenden Anspruchs zulassen oder verweigern

2. Geben Sie einen beschreibenden Namen für die Regel ein. Verwenden Sie etwas, das sofort zeigt, wofür die Regel verwendet wird.
3. Wählen Sie Gruppen-SID von dem Typ des eingehenden Anspruchs Dropdown-Box und dann verwenden Durchsuche um die entsprechende Gruppe aus Active Directory auszuwählen.
4. Stellen Sie sicher, dass Sie auswählen Verweigern Sie Benutzern mit diesem eingehenden Anspruch den Zugriff und dann klicken Fertig (Figur 3).

Verweigern Sie Benutzern mit dem eingehenden Anspruch den Zugriff
Dies sollten Sie nach dem Bearbeiten der Anspruchsregel sehen.

Nachdem die Regel erstellt wurde, können Sie die Prioritäten mithilfe des Pfeils neu anordnen.

Dekonstruieren Sie die Anspruchsregel

Schauen wir uns nun die Anspruchsregelsprache an. Klicken Regel bearbeiten und dann Regelsprache anzeigen um die Anspruchsregel zu bearbeiten. Für diese Regel wurde die folgende Sprache erstellt:
C :([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “^(?i)S-1-5-21-<group-id>“])
=> issue (Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);
Wenn Sie sich die Anspruchsregelsprache genauer ansehen, werden Sie feststellen, dass sie ziemlich lesbar ist. Der erste Teil bezieht sich auf die Gruppenmitgliedschaft. Die Sprache gibt an, dass der Zugriff verweigert werden sollte, wenn die Gruppen-SID einem bestimmten Wert entspricht (der Gruppen-SID aus der von uns ausgewählten Gruppe):
=> Problem (Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Erstellen Sie komplexere Anspruchsregeln

Sobald Sie festgelegt haben, wie Anspruchsregeln erstellt werden, können Sie sich mit komplexeren Beispielen befassen. Microsoft unterstützt sofort eine Reihe von Ansprüchen, mit denen das Verhalten von AD FS geändert werden kann. Sie können jedoch Ansprüche hinzufügen, um neue Anspruchsregeln zu erstellen. Zum Beispiel können Sie die verwenden X-MS-Proxy Anspruchsregel, um festzustellen, ob der Verkehr einen AD FS durchlaufen hat Proxy Server. Dies wird häufig verwendet, um zu bestimmen, ob eine Authentifizierungsanforderung von innerhalb (der Anspruch ist nicht vorhanden) oder außerhalb (der Anspruch ist vorhanden) des Unternehmensnetzwerks stammt. Weitere Informationen zum Hinzufügen von Ansprüchen zu Ihrer AD FS-Konfiguration finden Sie auf der TechNet-Website von Microsoft.
Sie können auch eine Anspruchsregel verwenden, um den Zugriff auf Office 365 auf Benutzer zu beschränken, die Mitglieder einer bestimmten Gruppe sind und sich im Unternehmensnetzwerk befinden. Lassen Sie uns zur Verdeutlichung ein Beispiel verwenden. In diesem Beispiel wird eine Gruppe mit dem Namen verwendet Office365access um festzustellen, wer Zugriff auf Office 365 hat. Hier ist die Logik hinter der Anspruchsregel:
1. Jedem, der kein Mitglied der Gruppe ist, wird der Zugriff verweigert.
2. Jedem, der Mitglied der Gruppe ist, aber versucht, von außerhalb des Unternehmensnetzwerks auf Dienste zuzugreifen, wird der Zugriff verweigert.
In diesem Beispiel wird auch davon ausgegangen, dass Sie den X-MS-Proxy-Anspruch bereits hinzugefügt haben, wie im Prozess aus dem zuvor erwähnten TechNet-Artikel beschrieben.
Damit die folgende Anspruchsregel funktioniert, ist es wichtig, dass der externe Datenverkehr immer über einen AD FS-Proxyserver oder den Windows-Webanwendungsproxy fließt. Dadurch wird sichergestellt, dass der X-MS-Proxy-Header vorhanden ist. Wenn nicht, kann AD FS nicht feststellen, ob der Datenverkehr intern oder extern ist.
Zunächst verwenden wir eine Behauptung, die der im vorherigen Beispiel ähnelt, um festzustellen, ob ein Benutzer Mitglied einer bestimmten Gruppe ist:
existiert ([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “^(?i)S-1-5-21-<group-id>“])
Dann fügen wir einen Code hinzu, um anzugeben, dass ein Benutzer intern sein muss:
&& existiert nicht([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
Wenn beide Bedingungen erfüllt sind, sollte ein Anspruch erstellt werden, der den Zugriff auf Office 365 gewährt:
=> issue (Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”);
Wenn wir alles zusammenbringen, erhalten wir den folgenden Code:
existiert ([Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “^(?i)S-1-5-21-<group-id>“])
&& existiert nicht([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
=> issue (Type = “http://schemas.microsoft.com/authorization/claims/permit”, Value = “true”);
Dieser Code wird in die folgende Logik übersetzt:
1. Wenn eine bestimmte Gruppen-ID vorhanden ist (= Mitglied einer bestimmten Gruppe) und
2. Es besteht also kein x-ms-Proxy-Anspruch (der Datenverkehr wurde nicht über den AD FS-Proxy geleitet und gilt daher als intern)
3. Stellen Sie ein Token aus.
Obwohl wir jetzt den richtigen Anspruch haben, müssen wir noch eine letzte Änderung vornehmen. Die Standardregel akzeptiert alle authentifizierten Benutzer. Daher müssen wir die Regel ändern, um allen Benutzern den Zugriff zu verweigern, und dann sicherstellen, dass sie eine niedrigere Priorität als die neue benutzerdefinierte Anspruchsregel hat.
Es gibt viele andere Szenarien, in denen benutzerdefinierte Anspruchsregeln nützlich sein können. Beispielsweise können Sie den Zugriff auf bestimmte Workloads zulassen oder verweigern, z Exchange ActiveSync. Sie können die Quell-IP-Adresse des Benutzers verwenden, um zu bestimmen, ob der Zugriff gewährt werden soll.
Gehen Sie in der Regel nicht mit ihnen über Bord. Das Hinzufügen eigener Anspruchsregeln kann die Unterstützung der Authentifizierung erheblich erschweren. Wenn Sie ohne sie auskommen können, empfehle ich das. Wenn Sie sie verwenden müssen, verwenden Sie den Assistenten so oft wie möglich und vermeiden Sie das Erstellen eigener Anspruchsregeln. Wenn es keine andere Option gibt, sehen Sie sich die hier und in diesem TechNet-Artikel verfügbaren Beispiele an. In den meisten Fällen helfen sie Ihnen bei der Lösung des Problems.
Über den Autor:
Michael Van Horenbeeck ist ein Technologieberater, Microsoft Certified Trainer und Exchange MVP aus Belgien, der hauptsächlich mit Exchange Server, Office 365, Active Directory und etwas Lync arbeitet. Er ist seit 12 Jahren in der Branche tätig und ein häufiger Blogger, Mitglied der belgischen Unified Communications-Benutzergruppe Pro-Exchange und regelmäßiger Autor des Podcasts The UC Architects.

Similar Posts

Leave a Reply