| Table of Contents |
|---|
...
- Die Anmeldung der Benutzer mit ACS (Azure AD-Anmeldung)
- Nutzung der Email-Funktionen von Business Central (Email-Versand über Office 365 Exchange Onlineetc.) - keine Nutzung des Outlook-AddIns
- Nutzung von Universal Print
- Nutzung von PowerBI
...
| Note |
|---|
Ab hier verweisen wir auf den Punkt: Alle manuellen Schritte zur Anlage von Azure App-Registrierungen / Konfiguration der Mittelschicht- oder WebserverInstanz entfallen! Trotzdem bleiben die bisherigen Schritte erhalten, weil sie gut als Grundlage und zum Verstehen der Thematik dienen. Lesen Sie bei Unklarheiten trotzdem einmal die Anleitung, schauen Sie auf die Links von Microsoft. |
...
Den Credential-Type bitte erst ändern, wenn alle Einstellungen für AzureAD in der Business Central Administration ordnungsgemäß eingefügt worden sind (Application ID , Valid Audiences etc.) Siehe: Task 4 und 5: Configure Business Central Server and WebServer
Disable Token-Signing Certificate Validation muss aktiviert werden, laut Microsoft.
...
Durch ein von uns erstelltes Skript entfällt diese händische manuelle Arbeit für Sie. Auf dieses Skript wird im Folgenden genauer eingegangen.
Skript zur automatischen Konfiguration von Azure App-Registrierungen, Konfiguration von Web- und Mittelschichtsserver
| Anchor | ||||
|---|---|---|---|---|
|
Vorwort
Wir stellen ein PowerShell-Skript bereit, welches Ihnen ermöglicht, alle hier in dieser Anleitung genannten manuellen Schritte zur Erstellung der Azure App-Registrierungen für SSO, Mail, PowerBI, Universal Print etc. von dem Skript automatisch anlegen zu lassen. Es entfallen somit alle manuellen komplexen Schritte der richtigen OAuth-Permissions, richtiger Einstellung der Authentifizierungen etc.
Wenn bereits der Punkt "Automatisches Anlegen der Azure Apps.." mit dem PowerShell-Skript durchgeführt wurde und Sie die notwendigen Daten aus der AppProperties.json vorliegen haben und Sie weitere Mittelschichten und Web-Instanzen auf Azure-Authentifizierung umstellen möchten, beachten Sie bitte den folgenden Punkt und fahren dort fort:
In der Testphase ist es natürlich auch möglich, eine Mittelschicht mit Windows-Auth bestehen zu lassen und eine neue Mittelschicht anzulegen, extra für die Azure-AD-Anmeldung - beide verbunden mit der selben Datenbank.
...
Beachten Sie unbedingt den Punkt: Ablaufdatum der Client Secrets
Folgende Information sollten bereit stehen, bevor man das Skript startet:
- Thumbprint / Fingerabdruck (vom verwendeten SSL-Zertifikat, wichtig für OData über SSL, Web- und Mittelschichts-Kommunikation etc.)
- PublicWebBaseURL (URL vom Webclient) also: https://WEBSERVER/WEBINSTANZNAME
- DOMÄNENNAME\BENUTZERNAME des Benutzers (meistens nbauen), der SUPER-Rechte auf der BC-Datenbank hat
- und die dazu passende Email-Adresse aus dem Azure-Portal
Das im folgenden Text beschrieben beschriebene Skript (Kapitel: Skript zur automatischen Konfiguration von Azure App-Registrierungen, Konfiguration von Web- und Mittelschichtsserver) finden Sie hier: Enable-AzureAD.ps1
Erläuterung des Skriptes
Hier werde ich die einzelnen Steps im Skript genau erklären.
...
- Nachdem Sie Punkt 4 mit ENTER bestätigt haben, geht es weiter: Sie müssen hier nun die PublicWebBaseURL eingeben. Diese setzt sich aus dem WEBSERVERCOMPUTERNAMEN und der zur Mittelschicht zugehörigen WEBSERVERINSTANZ zusammen.
Heißt: Bei einer AIO-Installation ist alles zusammen auf einem Server installiert (Mittelschicht und Webserver). Wenn der Computername also SRV-BCAIO ist und die Webserverinstanz BAU (verbunden mit der Mittelschicht BAU ist), ergibt sich hier folgende Eingabe:
- Bestätigen Sie Ihre Eingabe mit ENTER. Sie werden aufgefordert, sich mit einem Azure-Konto anzumelden (am besten der Azure-Administrator). Wenn es nicht der Azure-Administrator ist, muss zumindest sichergestellt sein, dass der User Berechtigungen hat, Azure App-Registrierungen anzulegen.
...
| Info | ||
|---|---|---|
| ||
| https://login.microsoftonline.com/ und https://autologon.microsoftazuread-sso.com/ müssen in der Domäne (wenn entsprechend konfiguriert) per GPO als TrustedSites eingestuft werden. |
...
In der Testphase ist es natürlich auch möglich, eine Mittelschicht mit Windows-Auth bestehen zu lassen und eine neue Mittelschicht anzulegen extra für die Azure-AD-Anmeldung - beide verbunden mit derselben Datenbank.
Sonstige Informationen
Zusätzliche Mittelschichten und Webinstanzen auf Azure AD umstellen
| Anchor |
|---|
...
|
...
|
Um zusätzliche Mittelschichten und Webserverinstanzen auf Azure Authentication umzustellen, muss man diverse Links in den bereits bestehenden App-Registrierungen ergänzen.
...
Wenn man dies erledigt hat, kann man mit Punkt 1 und Punkt 2 aus dem Skript die jeweilige Web- und Mittelschichts-Instanz auf dem jeweiligen neuen Server mit den bereits festgelegten Daten aus der AppProperties.json-Datei befüllen und entsprechend auch für die Azure AD-Authentifizierung umstellen. Man erstellt somit keine neuen Azure App-Registrierungen, sondern nutzt die bestehenden.
Wenn man Punkt 1 und Punkt 2 jeweils nacheinander ausführt, ist der Ablauf quasi identisch mit dem, was man ab hier sieht. Nachdem man Punkt 1 und 2 ausgeführt hat, muss man sich noch entsprechend auf der dazugekommenen Web-Instanz anmelden und die selben Schritte wie hier nochmals durchführen mit den bereits bestehenden Daten. Und auch dann müssen die User aus BusinessCentral natürlich wieder auf einem anderen Server mit einer anderen Datenbank entsprechend Ihre "Authentication Email" zugewiesen bekommen, siehe: Bisherige BusinessCentral-User auf Azure Authentication umstellen
Ablaufdatum der Client Secrets beachten und entsprechend auf Wiedervorlage setzen
| Anchor | ||||
|---|---|---|---|---|
|
| Note | ||
|---|---|---|
| ||
Zur Kommunikation von Business Central und den Azure-App Registrierungen werden diverse IDs und Secrets ausgetauscht. Bitte beachten Sie, dass die jeweils zu den App-Registrierungen benötigten und automatisch angelegten Client Secrets and Values ein End-Datum besitzen, wann sie ihre Gültigkeit verlieren. Die Secrets werden mit Hilfe des Skriptes auf 2 Jahre Gültigkeit ausgelegt. Nach diesen 2 Jahren müssen neue Secrets angelegt werden und entsprechend der Anleitung hier im WebClient wieder ergänzt werden, damit die diversen Azure-Dienste weiterhin nutzbar sind. Siehe Infos von Microsoft: https://devblogs.microsoft.com/microsoft365dev/client-secret-expiration-now-limited-to-a-maximum-of-two-years/ Die Namen der App-Registrierungen sind natürlich abweichend. Kopieren Sie anschließend wieder den Value und die Secret ID, speichern es im PasswordSafe sicher ab und tragen es im jeweiligen WebClient nach. |
...