Blog von Haiko Hertes zu allen Themen rund um Microsoft, Cloud und Datacenter
Gestern Abend war ich zu Gast bei #Geeksprech. Cloud and Datacenter MVP Eric Berg hat mir viele Fragen zu PowerShell gestellt und ich habe Sie nach bestem Wissen beantwortet. Außerdem sind wie über das eine oder andere Randthema ins Gespräch gekommen.
Die Aufzeichnung findet ihr als Podcast auf verschiedenen Plattformen:
Facebook-Auftritt von Geeksprech
Hört mal rein – es lohnt sich! Und an Eric: Danke für die Einladung 
Nur als kurze “Randnotiz”: Wenn man eine Office 365 Subscription hat und seine Benutzerkonten aus einem On-Premise Active Directory nach Azure AD synchronisiert, dann kann man zwar an verschiedenen Stellen Dinge wie Passwort-Reset und andere Self-Service-Angebote aktivieren, diese aber nicht (so ohne Weiteres) benutzen. Der Benutzer bekommt beim Versuch, das Kennwort zu ändern eine Fehlermeldung, in etwa so:
oder so:
Im Wortlaut für die Suche:
“Ihr Konto ist für ein Zurücksetzen des Kennworts nicht aktiviert. Leider hat der Administrator Ihr Konto nicht zum Verwenden dieses Dienstes eingerichtet.”
bzw.
“Sie können Ihr Kennwort hier nicht ändern. Eine Kennwortänderung auf dieser Website wird von Ihrer Organisation nicht gestattet.”
Das Problem dabei ist: Mit dem in Office 365 enthaltenen Azure AD Lizenzen (Entspricht der Lizenzstufe Azure AD Basic) ist das nicht möglich – man bräuchte dazu Azure AD Premium! Und das wiederum wäre nur für dieses eine Feature (wenn man den Rest nicht braucht) in meinen Augen zu teuer…
Zitat aus der Microsoft Doku (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords):
Pricing and availability
Azure AD Password Reset is available in 3 tiers, depending on which subscription you have:
- Azure AD Free – cloud-only administrators can reset their own passwords
- Azure AD Basic or any Paid O365 Subscription – cloud-only users and cloud-only administrators can reset their own passwords
- Azure AD Premium – any user or administrator, including cloud-only, federated, or password synced users, can reset their own passwords (requires password writeback to be enabled)
Heisst also, man kann nur die nicht-synchronisierten Accounts in der kostenlosen Stufe ändern bzw. zurücksetzen lassen.
2 CommentsJa, ich weiß, ich erzähle jetzt hier nichts brandneues mehr. Aber vielleicht geht es anderen so wie mir diese Woche, daher also dieser Artikel. Aber erst mal von Anfang an:
Ich habe diese Woche in unserer ActiveDirectory Umgebung eine neue GPO angelegt. Mein Ziel war, damit eine neue Mailsignatur an alle Benutzer auszurollen. Die nötigen Einstellungen befinden sich im Benutzer-Zweig der GPOs, daher spreche ich gerne von einer “Benutzer-GPO”, was man bei mir auch immer im Namen sieht. Um das Ganze erstmal sinnvoll testen zu können, habe ich auf die Sicherheitsfilterung zurückgegriffen. Ihr wisst schon, damit kann man die GPO statt auf die gesamte verknüpfte OU auf einzelne Benutzer oder Gruppen anwenden. Also habe ich die “Authentifizierten Benutzer” entfernt, und stattdessen mich und einen weiteren Kollegen dort eingetragen:
Das Problem
Leider wirkte sich die GPO dann nicht wie gewünscht aus. Auffällig war aber, dass ich plötzlich auch das Verzeichnis, in dem sich die GPO-Daten und damit auch das Skript, dass die GPO ausführen sollte, befanden, nicht mehr lesen konnte. Selbst mit einem Domänen-Admin-Konto nicht! Sobald ich die “Authentifizierten Benutzer” bzw. in meinem Fall “Authenticated Users” wieder hinzugefügt hatte, konnte ich die Dateien wieder lesen. Natürlich hätte ich damit aber auch die GPO für die gesamte GPO ausgerollt.
Die Ursache
Ein bisschen Recherche im Internet brachte mich dann auf die Ursache des Problems und damit auch auf dessen Lösung:
Microsoft hatte durch ein Update, dass bereits im Juni 2016 erschienen war, eine wesentliche Arbeitsweise von GPOs geändert:
Bisher war es so, dass für das Wirksamwerden von Computer-GPOs das Computerkonto für die GPO das Lesen-Recht haben musste und bei Benutzer-GPOs das Benutzerkonto. Das Ganze passte auch zur Logik, dass Computer-Richtlinien nur auf Computerkonten wirken und Benutzer-Richtlinien nur auf Benutzerkonten (Ausnahme: Loopback-Verarbeitung). Das hat man auch nicht geändert. Was allerdings geändert wurde ist, dass auch bei Benutzer-Richtlinien das Computerkonto die Leserechte auf die GPO braucht.
Wenn man entweder keine Benutzer-GPOs benutzt oder bei diesen immer die “Authenticated Users” in der “Security Filtering” drin lässt (womit dann faktisch nur noch eine Steuerung über die verknüpfte OU oder über WMI-Filter möglich wird, wenn man nicht vom “verweigern” der Berechtigungen Gebrauch machen will) ändert sich für einen selbst nichts.
Wenn man aber so wie ich gerne mal auch bei Benutzer-GPOs auf die Gruppen- oder Benutzerkonten-bezogene Filterung zurückgreift, dann muss man diese Änderung unbedingt kennen!
Die Lösung
Die Lösung des Problem ist eigentlich recht einfach – wenn man die Ursache kennt. Das Computerkonto des Computers, an dem der jeweilige Benutzer arbeitet muss also in die Lage versetzt werden, die GPO zu lesen. Da man nicht immer weiß, wer gerade wo arbeitet und sich das ja auch täglich ändern könnte, bleibt fast nur, den “Domänen-Computern” das Leserecht zu geben. Und das funktioniert über den Reiter “Delegation” bzw. “Delegierung”:
Hier findet ihr noch den Blog-Artikel bei Microsoft, der mich zum Problem und dessen Lösung brachte:
https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/
8 Comments
Ihr könnt die aufgezeichnete Session über PowerShell DSC auf dem MSTS in Darmstadt jetzt auf Channel9 ansehen:
Viel Spaß dabei!
Die Slides dazu gibt es hier:
Schreibe einen Kommentar...