Microsoft hat zu Beginn des Jahres die Auswahl „niemals“ aus der Gültig-Bis Auswahl für geheime Clientschlüssel bei neuen AzureAD Apps entfernt. Hier ist im Azure WebGUI die Auswahl seither nur noch bis „2 Jahre“ möglich.
Die Auswahl ist auf bis zu 24 Monate eingeschränk
Die Limitierung beschränkt sich aber auf das GUI, die PowerShell kann weiterhin geheime Clientschlüssel erstellen, die deutlich länger gültig sind.
Lösung
Sofern die App selbst schon im WebGUI erstellt ist (Neue Registrierung > Name, URL > Registrieren) lässt sich für diese App schnell ein Secret erstellen.
AzureAD Anwendung geheimen Clientschlüssel via PowerShell hinzufügen, mit deutlich längerer Laufzeit
# Mit AAD Verbinden
Connect-AzureAD
# Apps auflisten, passende ObjectId kopieren
Get-AzureADApplication
# "Gültig von" und "bis" holen
$startDate = Get-Date
$endDate = $startDate.AddYears(99)
# Secret erstellen lassen
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId <ID> -StartDate $startDate -EndDate $endDate -CustomKeyIdentifier <ANZEIGENAME-DES-SECRETS>
# Secret anzeigen (um es zu kopieren und sicher zu verwahren)
echo $aadAppsecret01.Value
Dies ist wieder so ein „Schnipsel den man ständig braucht“ Beitrag.
Der ActiveDirectory Admin möchte nach einer Objektänderung diese „sofort“ ins Azure AD synchronisiert wissen und nicht die üblichen 30 Minuten warten.
Synchronisation starten
An der PowerShell auf dem AADConnect-Server ist das in zwei Zeilen (ausgeführt als Admin) erledigt:
Start-ADSyncSyncCycle
Gegebenenfalls ist vorher noch der Import des ADSync Moduls erforderlich (sollte ab PowerShell 3.0 aber automatisch erfolgen.)
Das Cmdlet stößt den Sync nur an, daher sollte die Rückmeldung Success recht schnell erfolgen.
Der eigentliche Prozess dauert (je nach Objekt- und Änderungsmenge) etwas länger, kann aber einfach im Synchronization Service überwacht werden. (Auch ersichtlich an der CPU-Last der Maschine 😉)
Neue Vollsynchronisation starten
Das Cmdlet startet standardmäßig nur einen „Delta“ Sync (-PolicyType Delta). In seltenen Fällen ist allerdings eine neue „Vollsynchronisation“ notwendig. Auch diese lässt sich „sofort“ via PowerShell starten:
Start-ADSyncSyncCycle -PolicyType Initial
Hinweis:
Dieses Vorgehen sollte ausschließlich als manuelle „Ausnahme“ des herkömmlichen Intervalls dienen und sollte nicht verwendet werden um automatisiert das „AllowedSyncCycleInterval“ des AADConnect schedulers zu unterschreiten. Dies könnte bei zu häufiger verwendung dazu führen, dass Microsoft weitere Sync-Vorgänge vorübergehend nur in *noch größeren* Abständen zulässt um einer Überlastung der AAD Dienste vorzubeugen.
Löscht man in Microsoft 365 einen Benutzer mit persönlicher Sharepoint-Site, erhält man in Veeam Backup for Office 365 beim sichern diese Fehlermeldung:
Failed to process site: https://<TENANT>-my.sharepoint.com/personal/<USER>. Cannot contact site at the specified URL https://<TENANT>-my.sharepoint.com/personal/<USER>. Access to this Web site has been blocked. Please contact the administrator to resolve this problem.
Der „System Administrator“ kann den gelöschten Nutzer aber nicht mehr sehen, auch in der Veeam-Objektliste nicht.
Das liegt daran, das Microsoft die Site und deren Daten noch 90 Tage lang aufbewahrt, die Site aber den Status „locked“ bekommt. Die Fehlermeldung ist also technisch korrekt, aber wenig hilfreich.
Löschen der Sharepoint-Site
Man kann die Site, sofern nicht mehr benötigt (ist ja gesichert …), einfach „richtig“ löschen, dann verschwindet auch der Fehler sofort.
PowerShell „Als Administrator“ öffnen und das SharePoint Online (SPO) Module installieren: Install-Module -Name Microsoft.Online.SharePoint.PowerShell
Im Tenant als Global Admin bei SPO-Admin anmelden: Connect-SPOService -Url "https://TENANT-admin.sharepoint.com"
Prüfen ob der SPO Nutzer noch vorhanden ist: Get-SPOUser -site "https://TENANT-my.sharepoint.com"
Wenn der Benutzer noch da ist, diesen löschen Remove-SPOUser -Site "https://TENANT-my.sharepoint.com" -LoginName <UPN>
Jetzt kann man nachsehen, ob die persönliche SharePoint Site von diesem Nutzer noch da ist (was vermutlich der Fall ist). Die genaue URL zur Benutzer-Site kann man aus der Veeam-Fehlermeldung kopieren Get-SPOSite "https://TENANT-my.sharepoint.com/personal/USER" | select *
Wenn der Befehl einen Eintrag zurückgibt, auf den „LockState“ schauen. Dieser sollte „Unlock“ sein. Wenn das nicht der Fall ist, Lockstate zurücksetzen: Set-SPOSite "https://<TENANT>-my.sharepoint.com/personal/<USER>" -LockState Unlock
Dann kann man die verweiste Site einfach entfernen: Remove-SPOSite "https://TENANT-my.sharepoint.com/personal/USER"
Wir würden uns wünschen, das Veeam hier eingreift. v5.0.1.252 fixt den Fehler leider nicht nicht, Backup-Jobs aus vorhergehenden Versionen stoppen bei diesem Fehler einfach. Wenn der Standard „Ignore this Object“ wäre, wäre das alles halb so schlimm …
Das „MyAnalytics“ Tool ist ja nett gemeint, aber aufgrund seiner „Opt Out“ Konfiguration in den meisten Fällen sehr nervig und was den Datenschutz betrifft ser „anfällig“. Wir können auch nicht nachvollziehen, wiso Microsoft so ein Tool für alle Nutzer Standartmäßig einschaltet.
Abschalten von MyAnalytics für den ganzen Tenant
Als Globaler Admin einloggen. Mit der „Delegierten Administration“ ist die Konfiguration nicht möglich.
Links unter (Alle anzeigen) Einstellungen > Einstellungen der Organisation > MyAnalytics öffnen
Manchmal muss der Admin genau ein einziges Objekt, oder nur wenige ganz bestimmte Objekte von der Synchronisation vom lokalen AD in das Microsoft 365 Azure AD ausschließen.
Das geht überraschend einfach, mann kann exclude-Regeln einfach im „Synchronization Rule Editor“ hinzufügen.
Schritt für Schritt Anleitung um ein Objekt nicht mehr zu synchroniseren
Zeitplan für die Synchronisation abschalten, damit keine automatischen Aufgaben die Änderungen durcheinander bringen:
Set-ADSyncScheduler -SyncCycleEnabled $False
Der Status des ADSyncSchedulers lässt sich jeder überprüfen mittels:
2. „Synchronization Rules Editor“ starten (als Administrator)
3. In der „View and manage …“ Liste die „Direction“ auf „Inbound“ stellen und eine freie Nummer unterhalb der bestehenden „Precedence“ Regeln finden (und merken). In der Regel ist das irgendetwas <100.
4. Oben rechts „Add New rule“
5. Den „Create inbound synchronization rule“ Assistenten nun ausfüllen:
Name: Ein beschreibender Name, z.B. „In from AD – Bernd auslassen“
Connected System: Der lokale AD Forest
Connected System Object Type: user
Metaverse Object Type: Person
Link Type: join
Precedence: Die gemerkte Nummer von oben (z.B. „90“)
„Tag“, „Enable Password Sync“ oder „Disabled“ nicht verändern
Next > …
6. „Add group“ > dann > „Add clause“
7. Als „Attribut“ ein zu filterned Attribut wählen, zum Beispiel den „name“ oder ein anderes Attribut. Bei größeren Mengen an Objekten nutzen wir hier gerne die „Extended Attributes“, die normalerweise solange ungenutzt und leer sind. Der Operator ist im Beispiel „equal“, der „Value“ der zu matchende Inhalt.
8. „Next >“, an den nun angezeigten „Add join Rules“ nichts ändern > „Next >“
9. Bei den „Add join rules“ eine Transformation hinzufügen:
11. „Connectors“ > Actions > Run > Full Synchronization > OK
12. „Operations“ Den Zyklus abwarten, Full dauert immer einen Moment …
13. Den Synchronization Schedule wieder einschalten:
Set-ADSyncScheduler -SyncCycleEnabled $True
14. Und einmal die Initial-Synchronisation laufen lassen:
Start-ADSyncSyncCycle -PolicyType Initial
❤️
Wir nutzen Cookies für den Login, Spam-Erkennung, die Betriebssicherheit und für Google AdSense um Geld einzuspielen. Google nutzt völlig übertriebenes Tracking zur Anzeige von "passenden" Anzeigen. Für diese Verarbeitungszwecke werden Cookies mit Geräte-Kennungen und andere Informationen gespeichert und abgerufen. Durch Klicken des „Zustimmen“-Buttons willigen Sie ein, dass Google (und anhängige) in den USA diese Daten verarbeiten darf. Anzeigen und Inhalte werden dort basierend auf dem Profil personalisiert, die Performance von Anzeigen und Inhalten gemessen und Erkenntnisse über Zielgruppen abgeleitet.
Durch das Klicken des „Zustimmen“-Buttons stimmen Sie der Verarbeitung zu.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
