All Posts by Kristina Dostall

About the Author

Apr 20

Intune: Fragen, Fehler und Irrtümer

Troubleshooting in Intune ist oft gar nicht so leicht und gerade am Anfang weiß man oft nicht, wo man überhaupt nach Fehlermeldungen suchen soll… am Gerät? In Intune? IN Azure? Ist es überhaupt schon synchronisiert?

Ein gutes Beispiel dafür ist einer der ersten Fehler, in die man überhaupt laufen kann:

1. Das Gerät ist registriert, aber es gibt keine Daten, Richtlinien werden nicht angewendet:

Der Benutzer registriert sein Gerät in Intune, es erscheint kein Fehler, und dennoch: keine Einstellung von Intune greift, das Gerät wird nie gesynched oder bewertet. In Azure AD bzw. Intune erscheint das Gerät normal, ohne weitere Informationen oder Fehler.

Problem: der Benutzer hat keine Lizenz zugeordnet.

Workaround: Lizenz zuteilen

Lösung: man kann einerseits Lizenzen anhand einer AAD Gruppenzugehörigkeit zuweisen sowie in Intune mit Conditional Access das Enrollment für Benutzer ohne Lizenz blockieren.

2. Die Richtlinie wurde geändert, aber es gibt am Gerät keine Änderung:

Problem: Änderungen und Updates zu App Protection Richtlinien können bis zu 8 Stunden brauchen um wirksam zu werden.

Workaround: Der Benutzer kann sich aus der App ausloggen und wieder einloggen um einen Sync zu erzwingen.

3. Kann man Geräte gruppieren, um Richtlinien anzuwenden?

In Intune liegt der Fokus auf dem Benutzer und man kann diesen durch Gruppenzugehörigkeit steuern. Manchmal ist das aber nicht ausreichend, wenn zum Beispiel ein Benutzer mehrere Geräte hat und diese für unterschiedliche Rollen konfiguriert werden sollen.

Problem: Gruppierung der Geräte ist nicht vorgesehen

Workaround: man kann unterschiedliche Kategorie Tags erstellen und dynamische Gruppen, basierend auf diesen Tags. Wenn man dann das Gerät registriert, muss man manuell den richtigen Kategorie Tag zuweisen, um unterschiedliche Profile pushen zu können.

4. Warum wird mein Netzwerkdrucker nicht von Intune verwaltet?

Obwohl der Netzwerkdrucker in Intune angelegt ist, wird er nicht auf den Clients eingerichtet.

Problem: Der Printserver muss mindestens ein Server 2012 sein, damit die Drucker über Intune zugeteilt werden können.

5. Die Sicherheits Richtlinien im Azure Portal können nicht konfiguriert werden.

Problem: fehlende Berechtigung

Lösung: folgende Rollen haben Zugriff im Azure Portal: Globaler Administator, Owner oder Contributor

6. Benutzer fehlen in App Protection Policy Reports

Im Report in der Admin Console werden neu hinzugefügte Benutzer nicht angezeigt

Problem: es kann bis zu 24 Stunden dauern, bis ein Report zu einem neu hinzugefügten Benutzer erstellt wird.

7. Fehlermeldung: “Device already has an email profile installed”

Wenn Benutzer bereits ein Emailprofil eingerichtet haben bevor sie das Gerät in Intune einbinden (oder Office 365 MDM), gibt es Probleme beim automatischen Einbinden über das Intune Profil:

  • In iOS wird das doppelte Emailprofil anhand des Hostnamens und der Emailadresse erkannt. Das vom Benutzer erstellte Emailprofil blockiert die Verteilung  des durch Intune verwalteten Profils. Das ist ein weit verbreitetes Problem, weil iOS Benutzer meist erst das Emailprofil erstellen und dann erst Intune ausrollen. Die Company Portal App gibt in dem Fall die Meldung zurück, dass der Benutzer nicht compliant ist und fordert den Benutzer auf, das Emailprofil zu entfernen
  • Auch in Windows wird das bereits vorhandene Emailprofil anhand des Hostnamens und der Emailadresse erkannt. Intune überschreibt das bereits existierende, vom Benutzer angelegte, Profil.
  • Samsung Knox Standard reagiert wie Windows, identifiziert das Profil aber nicht anhand des Hostnamens. Zusätzlich wird jede spätere Änderung durch den Benutzer jedes Mal wieder vom Intune Profil überschrieben.

Mehr zum Thema Intune, Bitlocker und GPO´s finden Sie demnächst auf diesem Blog!

Mrz 02

Intune Conditional Access – sicher zugreifen auf Office 365

Ist Office 365 denn nicht ohnehin abgesichert? Wozu zusätzlich Conditional Access und MFA?

Früher wurden richtige Festungen gebaut, mit VPN und Firewalls gesichert, aber in Zeiten der Cloud bringen diese klassischen Sicherheitsmechnismen nicht mehr die nötige Absicherung, da ja auch die Daten und Apps nicht mehr vor Ort liegen.

Jedes Unternehmen, das seine Mails oder andere Daten in die Office 365 Cloud bringt, sollte diese auch mit Enterprise Mobility + Security schützen.

Der Conditional Access, zu Deutsch „bedingter Zugriff“, ist eine Maßnahme zum Schutz unternehmensinterner Dienste oder Ressourcen durch die Steuerung des Zugriffs auf diese. Die Authentifizierung wird abhängig vom Dienst, der erreicht werden soll, um zusätzliche Schritte erweitert. So lassen sich Conditional Access-Richtlinien vereinfacht als „wenn, dann…“-Aussagen beschreiben.

Folgende Kriterien könnten in eine solche Bedingung einfließen:

  • Die Identität, mit der man sich anmelden möchte.
  • Der Standort, von dem die Anmeldung durchgeführt wird.
  • Das Gerät und dessen Zustand.
  • Die Anwendung, durch die man sich anmeldet.

Eine Richtlinie mit Bedingung könnte so aussehen: „Wenn ein Nutzer auf SharePoint Online zugreifen möchte, dann muss dieser eine Multi-Faktor-Authentifizierung durchführen, falls die Anmeldung nicht vom Firmenstandort (also von der eigenen öffentlichen IP-Adresse) durchgeführt wird.“

Diese Konfiguration würde bewirken, dass Benutzern, welche den Internetanschluss im Unternehmen nutzen, keine MFA-Aufforderung gesendet wird. Lediglich Anmeldungen von anderen öffentlichen IP-Adressen benötigen einen zweiten Faktor zur erfolgreichen Authentifizierung.

Azure Premium Plan 1 wird benötigt, um alle Conditional Access Features verwenden zu können.

Mit Azure Premium Plan 2 kann man zusätzlich noch Risk-Based Conditional Access verwenden. Das bedeutet, dass das aktuelle Anmelderisiko des jeweiligen Nutzers bewertet wird.

Das Anmelderisiko wird für jeden Nutzer bei jeder Anmeldung berechnet – gestützt durch Machine Learning als Teil von Azure Identity Protection. Das System lernt bei jeder Authentifizierung dazu. „Von wo agiert der Nutzer normalerweise?“ oder „welche Dienste nutzt er normalerweise?“ – aus diesem Nutzungsverhalten wird ein typisches Muster erstellt. Weicht eine Anmeldung von dieser gelernten Norm ab, ist das Risiko für diese Anmeldung dementsprechend höher.

  •   verdächtige IP-Adressen, von denen wiederholt fehlgeschlagene Anmeldungen durchgeführt wurden
  • unbekannte Standorte, von denen normalerweise keine Anmeldung erfolgt
  • „Impossible Travel“, also mehrere Anmeldungen von verschiedenen Orten, die aufgrund der Entfernung zwischen den Orten nicht möglich sind

Führt man all das zusammen, könnte so eine beispielhafte Richtlinie aussehen: „Wenn sich ein Nutzer innerhalb kurzer Zeit von zwei weit entfernten Standorten anmeldet, dann blockiere den Zugriff und gib diesen erst frei, sobald eine Anmeldung von einem bekannten Standort inklusive MFA durchgeführt wird.

Um den Einstieg in Conditional Access zu erleichtern und die Anwender mit den Auswirkungen vertraut zu machen, ist es natürlich möglich, den bedingten Zugriff ohne Risikobasierung einzuführen und im Anschluss auf Risk-based Access Control aufzustocken, sollten diese Features gewünscht sein. Ein weiterer Vorteil: Conditional Access ist bereits in Azure AD Premium P1 enthalten, während die Risikobewertung eine P2-Lizenz voraussetzt.

Um auf das Bild vom Anfang zurückzukommen: Conditional Access ist also keine starre Mauer um die schützenswerten Daten, sondern das Security-Team, das immer und überall die Personen und deren Ausweise kontrolliert.

Jun 03

Intune Win32-App-Verwaltung

Intune Win32-App-Verwaltung

Microsoft Intune ist das Tool, dass den Spagat zwischen privaten Devices und Companydevices oder zwischen Anforderungen der Benutzer und Unternehmensrichtlinien schafft. Geräte können aber nicht nur verwaltet werden, ein weiterer wichtiger Punkt ist die Verteilung von Apps.

In diesem Bereich gibt es nun lange erwartete Änderungen für die Verteilung von Apps in Windows: Bislang gab es Beschränkungen bei der Softwareverteilung auf MSI, die Verteilung komplexer Software war mit Intune Standalone nicht möglich.

Während es für Kunden mit Cloudverbindung zuvor schon möglich war, den Configuration Manager für die Verwaltung von Win32-Anwendungen zu verwenden, verfügen Kunden, die ausschließlich Intune verwenden, jetzt auch über umfangreichere Verwaltungsfunktionen für ihre Win32-Branchenanwendungen (LOB, Line-of-Business).

Damit ist es nun auch mit Intune Standalone möglich, EXE, mehrere MSIs, MST, MSP oder Batchfiles zu verteilen. Microsoft stellt dazu ein Tool: „Win 32 App Conversion Tool“ bereit.

Wie funktioniert es?

Mit dem Win 32 App Conversion Tool wird ein .IntuneWinFile erstellt, in dem alle Sourcefiles, die Installationsdatei und der Zielordner angegeben werden. Aus diesen Informationen und Files wird das .IntuneWinFile erstellt und im Zielordner gespeichert. In Intune erstellt man eine Win 32 App, verweist auf das neu erstellte .IntuneWinFile und beim Speichern wird es in Intune hochgeladen.

Verteilt wird diese App dann durch Zuweisung wie man es schon von den vorhandenen Bereitstellungsmöglichkeiten kennt.

Die Voraussetzungen für Win32 App Management sind einfach:

  • Windows 10 (Enterprise, Pro, Education) mindestes Version 1607
  • Der Client muss Azure AD / Hybrid Domain Joined und Intune enrolled sein

Zukünftig soll es auch möglich werden Tasksequenzen mit Intune verteilen.

Ausführliche Informationen zum Win 32 App Management findet man hier:

https://docs.microsoft.com/de-de/intune/apps-win32-app-management

Informationen zum Microsoft Win32 Content Prep Tool

https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool