Supportende für DirSync & Azure AD Sync am 13. April 2017

Hallo zusammen,

es wird Zeit für ein Upgrade … ein Upgrade auf Azure AD Connect!

Am 13. April 2017 läuft der Support für die beiden AD Synchronisations-Tools

  • Windows Azure Active Directory Sync (DirSync ; WAADS)
  • Azure Active Directory Sync (Azure AD Sync)

seitens Microsoft aus.
Dies wurde letztes Jahr schon einmal angekündigt und wird nun umgesetzt.

Ein Upgrade der Software auf Azure AD Connect muss bis zum 31. Dezember 2017 erfolgen. Ab diesem Zeitpunkt nimmt Azure AD keine Verbindungen von diesen Tools mehr entgegen.

Somit ist hier sofortiger Handlungsbedarf gegeben. Die beiden wichtigsten Fragen habe ich euch unten beantwortet…

Wie bekomme ich heraus welche Software ich einsetze?
Ganz einfach. Ihr findet auf eurem Synchronisations-Server unter „Programme & Funktionen (appwiz.cpl)“ die genaue Beschreibung euer Software inkl. der Versionsnummer.

Dort sollte wie auf dem Screenshot zu sehen „Microsoft Azure AD Connect“ zu finden sein. Falls nicht habt ihr eine vorgänger Version.

aadconnect-uninstall

Wie kann ich auf die neuste Version Upgraden?
Das Upgrade kann durch verschiedene Wege durchgeführt werden. Hier sind mehrere Faktoren Abhängig. Vorallem aber die aktuelle Konfiguration. Daher hier der offiziele Link von Microsoft zum Upgraden der Software:

DirSync -> AD Connect
https://docs.microsoft.com/de-de/azure/active-directory/connect/active-directory-aadconnect-dirsync-upgrade-get-started

Zudem solltet ihr in Zukunft euer AD Connect immer aktuell halten. Eine Anleitung zum Update von AD Connect findet ihr hier.

Hier zudem noch die Release History von AD Connect.

Greetz
Stephan


Werbeanzeigen

Public Preview – Azure AD group-based license

Hallo zusammen,

heute kann ich euch ein cooles neues Feature im Bereich Azure AD und Lizensierung von Benutzern zeigen. Bisher musste man seine Benutzer ja im O365 Portal einzeln lizensieren bzw. Massenbearbeitung verwenden. In größeren Umgebung hat man sich hierfür dann kleine PowerShell Skripte geschrieben die dem User dann passend Lizenzen zugeordnet haben.

Mit dem neuen Feature „group-based license management“ im Azure Active Directory ist es möglich neuen Benutzern auf Basis von Gruppenmitgliedschaften Lizenzen zu erteilen.
Dafür erstellt man ein Lizenz-Template und fügt dieses einer Gruppe zu.
Aktuell ist das Feature noch in Preview, also bitte noch nicht Produktiv verwenden.
Weiter unten habe ich euch noch einige Tipps und Einschränkungen zusammen gefasst.

Kurzer Überblick:

  • Lizensierung kann auf alle Sicherheitsgruppen angewendet werden. Egal ob synchronisiert oder im Portal erstellt.
  • Alle Microsoft Online Services die Userbasiert sind, sind Supportes.
  • Die Lizenzen können granular eingestellt werden.
  • Aktuell ist das Feature nur per Azure Portal konfigurierbar.
  • Die Lizenzen werden innerhalb von Minuten nach dem eintritt/verlassen der Gruppe hinzugefügt bzw. entfernt.

Nutzung:

Um das Feature zu nutzen braucht ihr eine aktive Subscription mit „Azure AD Basis“ oder höher. Später soll das Feature im E3 Plan inkludiert sein.

Zuweisung von User-Lizenzen Gruppenbasiert:

  1. Ihr findet das Feature über folgenden Pfad im Portal: Active Directory -> Licenses -> Products -> “ Eure Lizenz“ -> Licensed Groups1
  2. Gruppe hinzufügen und Lizenz Optionen auswählen
  3. Danach werden den Mitgliedern die Lizenzen zugewiesen.

 

Automatisierung – Dynamische Gruppen

Wenn man ein Azure AD Premium P1 besitzt hat man ebenfalls die Möglichkeit dynamische Gruppen mit dem Lizenzmanagement zu verbinden.

Dafür habe ich eine dynamische Gruppe angelegt, die Ihre Mitgliedschaft auf Basis eines Attributes pflegt.

5.jpg

Danach füge ich dann diese Gruppe ebenfalls hinzu, wie oben beschrieben. Ich baue mir somit mehrere Gruppen zu meinen Verschiedenen Lizenz Szenarien zusammen. Anschließend setze ich dann zum Beispiel bei einem Benutzer On-Premise, das Attribute „extensionAttribute1“ auf „E5_Basic;EMS“ und er kommt automatisiert die in der Gruppe hinterlegten Lizenzen für E5_Basic und EMS.

Achtung: Beim verändern von Regeln in Dynamisches Gruppen werden anschließend alle Mitglieder entfernt und auf Basis der neuen Regel wieder hinzugefügt. Das heißt das die Benutzer für dieses Zeitraum keine Lizenz haben und somit die Services nicht nutzen könne. Ggf. kann hier auch eine Datenverlust nicht ausgeschlossen werden.
Microsoft und auch ich empfehle daher immer eine neue Gruppe zu erstellen und die Regel entsprechend zu erstellen, danach abzuwarten bis alle die neue Mitgliedschaft bekommen haben und zum Schluss erst die alte Gruppe zu entfernen.

Weitere Informationen:

Wenn ein Benutzer mehrere Lizenzen durch mehrere Gruppenmitgliedschaften bekommt werden diese kurz gesagt zusammen geführt.

Das vermischen von direkter Lizensierung und gruppenbasierter Lizensierung ist möglich.

Lizenzen die per Gruppe dem Benutzer zugeordnet werden, können nicht am Benutzer entfernt werden. Trifft aktuell noch auf das Office 365 Portal zu. Es kommt eine Fehlermeldung.

Gruppen in Gruppen ist aktuell nicht Supported. Es werden nur direkte Mitglieder berücksichtigt.

Gruppenbasierte Lizensierung reagiert nicht automatisch auf Aktionen in der gesamten Umgebung. Beispiel: Es sind nicht genug Lizenzen vorhanden! Wenn man dann hingeht und direkt vergebene Lizenzen frei macht damit wieder genug Lizenzen vorhanden sind. Werden diese nicht automatisch für die Gruppe verwendet. Der Status bleibt „Not enough licences“. Es ist aber möglich über den „Reprocess“ Button ein neuen Durchlauf zu forcieren.

Quelle: https://blogs.technet.microsoft.com/enterprisemobility/2017/02/22/announcing-the-public-preview-of-azure-ad-group-based-license-management-for-office-365-and-more/

Euer Stephan

September 2016 Exchange Updates

Hallo zusammen,

am Dienstag sind die quartals Updates für Exchange Server 2016 und Exchange Server 2013 erschienen.

Hier ein kleiner ausschnitt aus den Neuerungen:

Windows Server 2016 Support
Mit dem CU3 ist nun endlich der Server 2016 Support gekommen.Auch sind nun Domain Controller auf Basis Server 2016 unterstützt. Hier muss aber ein FFL von Server 2008R2 gegeben sein. Exchange Server 2013 wird auf Server 2016 weiterhin nicht unterstützt.

.Net 4.6.2 Support
Mit Windows Server 2016 ist .Net 4.6.2 vorinstalliert. Somit ist nun diese .Net Version in kombination Windows Server 2016 und Exchange Server 2016 CU3 nun supported.
Eine unterstützung für Server 2012/R2 ist für das nächste Release geplant.
Ab März 2017 wird .Net 4.6.2 erforderlich sein, daher empfehle ich jetzt schon die kompatibilität zu allen 3rd Party produkten zu erstellen.

HA Verfügbarkeit
Mit Exchange Server 2016 CU3 wurde die benötigte Netzwerk-Bandbreite zwischen DAG DB Kopien reduziert.

Zeitzonen Updates und Sicherheitsupdates
Sowohl CU3 als auch CU14 enthalten die neusten Zeitzonen Änderungen und Sicherhheitspatches.

Outlook on the Web
Die Ansichten von Outlook on the Web wurden weiter dem O365/Exchange Online angepasst.

Die installation von Exchange Server 2016 CU3 enthält ein Schema Update, was bei der Installation automatisch durchgeführt wird. Vorraussetzung hierfür ist, dass das Setup mit ausreichend Bereichtungen gestartet wird.

Die Installation von Exchange Server 2013 CU14 enthält kein Schema Update.

Gruß
Stephan

Microsoft Authenticator

Hallo zusammen,

heute hat Microsoft das Erscheinen der neuen Microsoft Authenticator App bekannt gegeben. Ab dem 15. August soll die neue App in allen App-Stores zur Verfügung stehen.

Diese neue App wird sowohl Microsoft Accounts als auch Azure AD Accounts unterstützen.
Bisher brauchte man hierfür zwei verschiedene Apps.

Folgende weitere Neuerungen gibt es:

  • Neue „User experience“ für einfacheres Handling.
  • Push-Benachrichtigungen erlauben das direkte „Bestätigen“ von Login-Anforderungen.
  • Smartwatch komptibilität für Apple Watch und Samsung Gear Geräten.
  • Fingerprint Unterstützung für IPhone und Android Geräte
  • Zertifikatsbasierte Authentifizierung

Die neue App wird als ein Update für die bestehende Azure Authenticator App zur Verfügung gestellt. Alle bestehen Accounts sollen automatisch übernommen werden.
Diese werde natürlich nochmal testen und berichten.

Den original Artikel vom Microsoft Blog findet ihr hier:

https://blogs.technet.microsoft.com/enterprisemobility/2016/07/25/microsoft-authenticator-coming-august-15th/

Schönen Abend noch ..

Gruß
Stephan

 

 

Exchange Online – CBA

Hallo zusammen,

der Exchange Team Blog hat diese Woche die zertifikatsbasierte Authentifizierung (certificate-based authentication – CBA) für Exchange Online in die Preview genommen. Der Exchange On-Premise kann dies bereits für Verschiedene mobile Apps.
Die Preview in Exchange Online ist aktuell für „Outlook for Android“ und „Exchange ActiveSync“ verfügbar. „Outlook for iOS“ wird zukünftig ebenfalls unterstützt.

Hier gibt es es vollständigen Artikel inkl. Anleitungen:

https://blogs.technet.microsoft.com/exchange/2016/07/19/preview-of-certificate-based-authentication-cba-for-exchange-online/

Gruß
Stephan

Azure AD Connect Version 1.1.189.0

Hallo zusammen,

einige Bugfixes wurde mit der neuen Version von AD Connect behoben. Dies wollt ich euch nicht vorenthalten.

Aktuelle Version: 1.1.189.0

Bugfixes:

  • Azure AD Connect kann jetzt auf einem FIPS-kompatiblen Server installiert werden.
  • Ein Problem, bei dem ein NetBIOS-Name im FQDN im Active Directory Connector nicht aufgelöst werden konnte, wurde behoben.

Informationen wie Ihr AD Connect Updaten könnt findet ihr hier:
https://azure.microsoft.com/de-de/documentation/articles/active-directory-aadconnect-upgrade-previous-version/

Gruß
Stephan

Quelle:

https://azure.microsoft.com/de-de/documentation/articles/active-directory-aadconnect-version-history/#111890

SIDHistory / SIDFiltering – German/English

Hallo zusammen,

vor einigen Tagen war ich mal wieder bei einer AD Migration tätig. Auch hier gab es wieder Verwirrung um die Einstellungen der „SID History“ und des „SID Filtering“.
Da ich nun schon häufiger damit konfrontiert worden bin, möchte ich mit diesem Post ein wenig Licht ins Dunkele bringen.

SID History:

Die SID History ist ein Active Directory Objekt Attribut, welches dafür sorgt, dass während einer Domain Migration zwischen alter und neuer Domäne Zugriffe erfolgen können.

Das Szenario sieht wie folgt aus:
Wir haben eine Domäne A (Quelle) und eine Domäne B (Ziel). Zwischen den beiden Domänen existiert ein Trust. Art der Vertrauenstellung ist an dieser Stelle erstmal uninteressant. Weiter gibt es einen ADMT Server in der Zieldomän und einen Benutzer A aus Domäne A.

Image 8

Beispiel anhand eines Benutzers:
Das ADMT Tool schreibt beim migrieren der Benutzer-Objekte zwischen Domäne A und Domäne B die SID des Benutzers A in das Attribut „SIDHistory“ des neuen Benutzers B.
Wenn sich Benutzer B nun Anmeldet, bekommt er zusätzlich zu seinen Berechtigungen in Domäne B auch alle Berechtigungen der SID aus  Domäne A hinzugefügt.

Somit wird gewährleistet, dass Zugriffe auf Ressourcen in beiden Domänen während einer Migrationsphase gegeben sind.
Kurz gesagt Benutzer B kann auf den Fileserver in Domäne A zugreifen, weil Benutzer A dort ja berechtigt ist und Benutzer B ja zusätzlich alle Berechtigungen von Benutzer A bekommen hat.
Benutzer A und B sollten in diesem Falle natürlich die selbe Person sein. 😉

SID Filtering:

Die SID Filterung ist dafür gedacht fremde SIDs aus anderen Domänen zu filtern und somit das prinzip der SID History nicht zu zu lassen. Dies hat unter gewissen Umständen einige Vorteil. Zum Beispiel wenn eine Domäne komprometiert wurde. Standardmäßig ist für eine Vertrauensstellung die Filterung eingeschaltet.

Damit aber der Zugriff während der Migration gegeben ist sollte man die SID Filterung natürlich abschalten.

External Trust:

Netdom trust DomäneB /domain:DomäneA /quarantine:No /usero:Domänen-Administrator /passwordo:*

Forest Trust:

Netdom trust DomäneB /domain:DomäneA /enableSIDhistory:yes /usero:Domänen-Administrator /passwordo:*

 Achtung:
Beim Forest Trust der von einem deutschen Domain Controller aus erstellt wurde wird der Parameter /enableSIDhistory mit „Ja“ angegeben:

Netdom trust DomäneB /domain:DomäneA /enableSIDhistory:ja /usero:Domänen-Administrator /passwordo:*

Zum überprüfen des Status kann man folgendes eingeben:

Netdom trust DomäneB /domain:DomäneA /quarantine /usero:Domänen-Administrator /passwordo:*

Netdom trust DomäneB /domain:DomäneA /enableSIDhistory /usero:Domänen-Administrator /passwordo:*

Hoffe ich konnte hiermit helfen 🙂

Gruß
Stephan