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

 

 

Advertisements

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

Windows Server 2016 / Neuigkeiten

Hallo zusammen,

in den letzten Tagen gab es einige Neuigkeiten im Microsoft Server Umfeld. Diese wollte ich euch nicht vorenthalten.

Windows Server 2016

Die mit am meißt erwarteste Neuigkeit ist wohl der release Termin von Windows Server 2016. Dieser wird von Microsoft auf der diesjährigen Microsoft Ignite bekannt gegeben. Die Ignite findet vom 26.09 – 30.09.2016 in Atlanta, USA statt.

https://blogs.technet.microsoft.com/windowsserver/2016/07/12/windows-server-2016-new-current-branch-for-business-servicing-option/

Wie ihr sicherlich schon wisst, wird es bei Server 2016 eine weitere Installation-Option geben. Der Nano-Server.

  • Server with Desktop Experience
  • Server Core
  • Nano Server (neu)

Der Nano-Server ist eine sehr stark verkleinerte Version von Windows Server ohne GUI. Zudem gibt es hier nur wenige Rollen/Feature für diese Art von Windows Server. Es gibt aber jetzt schon sehr tolle Einsatzmöglichkeiten für diesen Server. Zum Beispiel als Hyper-V Host. Ich werde in Zukunft nochmal einen gesonderten Blog Artikel hierzu schreiben.

Weiter gibt es ein paar interessante Informationen zum Update verhalten von Server 2016.Speziell geht es hier um die von Windows 10 schon bekannte Current Branche bzw. Long Time Service Branch (LTSB) Themen.

Mein Kollege Eric Berg hat dies gut zusammengegefasst. Daher hier der Link zu seinem Blog-Artikel:

http://ericberg.de/windows-server-2016-nun-doch-ltsb-und-current-branch/

Wünsche euch ein schönes Wochenende.

Gruß
Stephan

 

 

 

Azure Site Recovery (ARM) – Teil 3

Hallo zusammen,

wir befinden uns in Teil 3 meiner Blogserie zum Thema Azure Site Recovery. In Teil 1 & 2 haben ich euch bereits gezeigt wie man seine Hyper-V Umgebung mit Microsoft Azure Site Recovery verbindet und eine VM absichert.

In Teil 3 soll es nun um Recovery Plans gehen.

Hier nochmal die ersten Teile zum nachlesen.

Azure Site Recovery (ARM) – Teil 1

Azure Site Recovery (ARM) – Teil 2

Recovery Plans

Recovery Plans sind eine Art Ablaufprozess der angestartet werden kann, wenn es zum Ausfall auf On-Premise Seite kommt. In einem Recovery Plan wird festgelegt welche VMs wie behandelt werden. Ebenfalls kann man eine Start-Reihenfolge festlegen. Damit zum Beispiel ein Domain Controller vor dem Exchange Server startet.

Die Einrichtung ist recht einfach und überschaubar. Im Azure Portal wählen wir „Recovery Service Vaults“ aus und wählen unseren Tresor aus.

1

Über Site Recovery -> Step3: Manage Recovery Plans können wir einen Plan anlegen.

2

Name: Sprechender Name für den Plan
Source: Meine Hyper-V SiteTarget: Microsoft Azure
Deployment: Ressource Manager

Select Items: Hier können wir auswählen welche Maschinen in diesem Planen verarbeitet werden sollen. Danach mit OK bestätigen.

3

Über Customize kann ich nun noch einige Einstellungen mitgeben:

Welche Maschine wann heruntergefahren werden soll.
Zusätzlich kann ich Gruppen definieren für Start-Reihenfolgen. Es ist auch möglich vorher oder nacher Scripte laufen zu lassen. Zum Beispiel mit Azure Automation.

Im Fehlerfalle brauche ich dann nur diesen Plan zu Starten (Planned/ Unplanned). Anschließend wird die Umgebung nach meinen Vorgaben in Azure hochgefahren.

Wie ein Failover generell mit Azure Site Recovery funktioniert werde ich in Teil 4 erläutern. Bis dahin viel Spaß beim ausprobieren.

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