Alteryx Server: Authentifizierung konfigurieren

Die Domäne, auf der Alteryx Server ausgeführt wird, muss über die gleiche Vertrauensrichtlinie wie andere Domänenbenutzer verfügen, damit Active Directory Benutzerberechtigungen auflösen und festlegen kann.

Beide Domänen müssen Teil derselben Forest-Struktur sein.

Der Alteryx Dienst muss in der Lage sein, alle Attribute aus den Behältern „CN=Users" und „CN=Computers" für beide Domänen zu lesen. Der Alteryx Dienst wird unter dem lokalen Systemkonto auf dem Server ausgeführt, auf dem er installiert ist. Wenn Sie ein dediziertes Dienstkonto definieren, anstatt das lokale System zu verwenden, muss das Konto über die Berechtigung verfügen, alle Attribute aus beiden Behältern zu lesen, um die Authentifizierung für beide Domänen zu aktivieren.

Informationen zur Konfiguration von Alteryx Server für SCIM mit Azure Active Directory finden Sie unter Konfigurieren von Alteryx Server für SCIM mit Azure Active Directory .

Weitere Informationen zu Azure SCIM finden Sie in der Dokumentation zu Microsoft Azure .

Informationen zur Bereitstellung und zum Testen Ihres SCIM-Endpunkts in Azure finden Sie im Tutorial: Entwickeln eines SCIM-Beispielendpunkts in Azure Active Directory .

Sobald Sie SCIM aktiviert haben, werden alle in Azure (oder bei einem anderen IDP) vorhandenen Entitäten mit Server synchronisiert. Zukünftige Änderungen an diesen Entitäten führen zu Änderungen an den zugehörigen Objekten in Server. Vorhandene Benutzer:innen und Gruppen in Server, die auch beim IDP vorhanden sind, werden verknüpft und mit beim IDP vorgenommenen Änderungen aktualisiert. Der IDP gilt als die ausschlaggebende Informationsquelle für diese Objekte. Beispiel: Der Benutzer „John Smith“ ist in Server und beim IDP vorhanden und Sie haben SCIM aktiviert. Wenn Sie jetzt „John Smith“ auf Server zu „John Doe“ ändern, wird es bei der nächsten Synchronisierung wieder zu „John Smith“ geändert.

Gruppen werden nach Namen und Benutzer nach E-Mail verlinkt.

Lokale Benutzer:innen und Gruppen, die nur in Server vorhanden sind, liegen außerhalb des IDP-Anwendungsbereichs und werden als Objekte weiterhin von Server verwaltet.

Bestimmte Zeichen werden möglicherweise nicht von SCIM zu Server übertragen – dies hängt vom IDP ab. Wenn der IDP Sonderzeichen, eingeschränkte oder reservierte Zeichen im Namen eines Gruppen- oder Benutzerobjekts zulässt, wird das Zeichen mit Server synchronisiert. Für diese Objektnamen werden von uns keine bestimmten Zeichen ausdrücklich zugelassen oder verboten.

Server initiiert für SCIM keine Verbindung zum IDP. Stattdessen wird eine Reihe von API-Endpunkten und ein Zugriffstoken bereitgestellt, das der IDP verwendet, um eine Verbindung zu Server herzustellen. Sie können diese Endpunkte mit Standard-API-Testtools wie Postman manuell testen.

Alle Änderungen an Benutzer- und Gruppenobjekten werden über die Audit-Protokollierung von Server geprüft. Das umfasst auch Änderungen, die per SCIM vorgenommen wurden.

Rollen, Berechtigungen oder Besitzer von Assets werden nicht per SCIM aktualisiert. Daher behalten alle vorhandenen Benutzer und Gruppen die Assets, deren aktueller Besitzer sie sind, sowie die ihnen zugewiesenen Rollen und Berechtigungen.

Die Berechtigungen sind abhängig von den gewählten Server-Gruppeneinstellungen. In Azure Active Directory werden keine Berechtigungen gespeichert.

Wenn Sie eine AD-Gruppe von Azure zu Server synchronisieren, können Admins Berechtigungen für diese neu erstellte Gruppe in Server festlegen. Wenn Sie dieser AD-Gruppe dann einen neuen Benutzer hinzufügen, fügt SCIM diese/n Benutzer:in automatisch auch der Server-Gruppe hinzu. Diese/r Benutzer:in erhält Berechtigungen basierend auf dieser Server-Gruppe.

Die SCIM-Funktion umfasst nur die Möglichkeit, Benutzer und Gruppen von Azure AD aus Zugriff auf Server zu erteilen. Die Synchronisierung umfasst keine Berechtigungen für andere Assets in Azure, wie z. B. Datenbanken. Benutzer:innen müssen weiterhin DCM- oder Server-Datenverbindungen für alle Daten verwenden.

Wenn Sie ein Rollback auf eine ältere Version von Server durchführen müssen, die SCIM nicht enthält, funktioniert SCIM nicht und ist erst dann verfügbar, wenn Server wieder aktualisiert wurde.

Wenn Sie ein DB-Backup aus der Zeit vor der Konfiguration von SCIM wiederherstellen, müssen Sie SCIM danach neu konfigurieren und die erste Synchronisierung durchführen.

Wenn Sie eine Sicherung auf einer Version von Server wiederherstellen müssen, die SCIM verwendet, müssen Sie eine vollständige Resynchronisierung von der IDP-Seite aus durchführen, damit unsere Datenbank wieder mit dem IDP synchron ist.

Wenn Sie eine/n Benutzer mithilfe von SCIM deaktivieren, verhalten sich Zeitpläne genauso wie jetzt, wenn Sie einen Benutzer deaktivieren oder löschen. Sie verhalten sich so, als ob Sie den/die Benutzer:in über die Server-Benutzeroberfläche oder -API deaktiviert oder über die API gelöscht hätten. Weitere Informationen finden Sie unter Benutzer deaktivieren .

Die Synchronisierungsdauer variiert je nach IDP und kann evtl. konfiguriert werden. Azure-Synchronisierungen können bis zu 40 Minuten dauern. Dabei handelt es sich um einen statischen Wert, der nicht konfiguriert werden kann.

Wir haben umfangreiche Tests mit Azure und begrenzt Tests mit Okta durchgeführt. Den Okta Provisioning Agent konnten wir jedoch nicht testen, da er nur zahlenden Kunden zur Verfügung steht. Die anderen IDPs sollten funktionieren, wurden jedoch nicht getestet.