olc

Genau, der miisclient ist nur etwas beschnitten im Vergleich zu früher. BTW: wenn Du AAD Premium lizenziert, ist der Microsoft Identity Manager (MIM, ehrm. FIM) damit inklusive. Damit kannst Du dann komplexe IdM Szenarien abbilden. Viele Grüße olc

Hi Stefan, ich vermute Du meinst den miisclient? FIM war noch nie Teil der Sync Tools, nur die Filter-Komponente. Der miisclient ist abgespeckt dabei. Dafür kannst Du den MIM Connector für komplexere Szenarien verwenden. Was genau möchtest Du denn erreichen? Viele Grüße olc

Hi Stefan, korrekt, AADConnect löst die alten Tools ab. Neue Funktionen sind unter anderem die leichtere Integration von ADFS durch AADConnect, neue Filtermöglichkeiten ohne in die Tiefe der miis-Menüs zu gehen usw. Kurz gesagt: die alten Tools werden zusammengeführt und nicht weiter entwickelt. An AADConnect kommst Du also nicht mehr vorbei. Eine Migration ist möglich, schau einmal hier hinein: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-dirsync-upgrade-get-started/ Viele Grüße olc

Hi, Zusatzpunkte gibt es, wenn das dsrm Kennwort auf allen DCs zyklisch geändert wird. ;) https://blogs.technet.microsoft.com/askds/2009/03/11/ds-restore-mode-password-maintenance/ Viele Grüße olc

MIM Modern UI App, wobei ein MIM und MIM Certificate Manager deployment ein dickes Brett ist. Ob das für Dich relevant ist, kann ich anhand der verfübaren Daten nicht sagen. https://technet.microsoft.com/de-de/library/mt134415.aspx Viele Grüße olc

Hi, hast Du zwei Accounts hier im Forum? Das hab ich verstanden. :) Meine Antwort bleibt jedoch: eine sinnvolle Antwort gibt es nur mit sinnvollen Anforderungen. Daher habe ich oben auch ein, zwei Varianten beschrieben, die das Szenario verändern und unterschiedliche Anforderungen spiegeln. Das hilft hoffentlich auch ein wenig weiter im Gedankenspiel? Die vSC ist an das Gerät gebunden (TPM). Ein Kennwort kann überall verwendet werden, also auch bei Remote Zugriffen. 2-Faktoren eben: etwas, was Du hast (oder was Du bist) und etwas, was Du weißt. Viele Grüße olc

Hi Stefan, je nach Benutzer kann die Trennung vom Gerät gut oder schlecht sein. :) Im Ernst: meiner Erfahrung nach hat es Sinn, Sicherheitstechnik so einfach wie möglich zu gestalten, damit es von den Benutzern angenommen wird. Bei vSC ist das m.E. der Fall. Sofern schon eine SC Infrastruktur vorhanden ist, kann auch eine Trennung der Sicherheitslevel pro Dienst sinnvoll sein. Etwa vSC für alle "normalen" Authentifizierungen (gegen Applikationen, Webinterfaces usw.) und eine normale SC für Signaturen, Server Zugriffe usw. Gerade wenn die SC nicht nur IT-technisch relevant ist, sondern auch Zutrittssysteme steuert usw., kann der business case sehr verschieden aussehen. Daher meine Rückfrage zu Deinen Anforderungen. Je genauer Du weißt, wohin Du mittelfristig möchtest, umso besser lassen sich die verschiedenen Modelle eruieren, anpassen, vermischen usw. Viele Grüße olc

Hi, wie meinst Du 'nur den Laptop und die PIN'? Das ist der Sinn von 2-Faktor Authentifizierung. Nicht anders bei SmartCards o.ä. Sicherheit ist im Kontext Deines angestrebten Sicherheitsniveaus zu bewerten. Grundsätzlich ist vSC mit TPM durchaus als 'sicher' zu bewerten, siehe dazu jedoch den ersten Satz dieses Absatzes. Wie lauten Deine Anforderungen? Viele Grüße olc

Haste schon Recht :) - wobei ich das schon einmal durchrechnen würde. Ausschließlich online ist es wenig komplex, erst der MIM ist aufwändiger. Ob die investierten Euros in eine lokale Lösung besser investiert sind? Insbesondere, wenn Du dann weitere Funktionen von AAD nutzen kannst? Kommt drauf an.

Hi, mit Azure AD Premium hast Du auch die Möglichkeit ein Self-Service Password Reset Portal zur Verfügung zu stellen. Hat den Charme, dass es mobil auf allen Endgeräten der Benutzer aufgerufen werden kann. Wenn Du das möchtest. ;) Alternativ kannst Du auch lokal/on-premises den MIM dafür einsetzen - ist bei Azure AD Premium dabei. Viele Grüße olc

Hi, die Frage ist, was Du für Anforderungen hast. Das klassische AD hat nur wenig mit Azure AD zu tun. Wenn Du aber "alles neu" machen möchtest wie oben beschrieben, kannst Du Deine Anforderungen ja auch "neu denken". ;) Die Azure AD Domain Services sind aus meiner Perspektive eher eine Brückentechnologie zum Übergang - hier kannst Du NTLM, Kerberos, LDAP, RPC usw. nutzen. Grundsätzlich gibt es zumindest seitens Microsoft kein anderes AD "SaaS" als die AAD Domain Services, aber Du kannst natürlich auch DCs als IaaS auf Azure betreiben. Wie gesagt, definiere genau Deine Anforderungen und danach hat es Sinn zu schauen, was passt. Viele Grüße olc

Das Problem ist, dass das Kennwort manuell durch den TO geändert wurde. Da nicht klar ist, gegen welchen DC die Änderung durchgeführt wurde hat es durchaus Sinn, es noch einmal richtig zu machen. :) Viele Grüße olc

Hi, hast Du vor dem Rücksetzen des Kennworts den KDC Dienst gestoppt auf dem fehlerhaften DC und war der Zielserver für die Kennwortrücksetzung der "funktionierende" DC? Falls nicht: 1. auf fehlerhaften DC KDC Dienst stoppen und deaktivieren. 2. Compterkonto reset des fehlerhaften DCs gegen den funktionierenden DC. 3. Neustart des fehlerhaften DCs. 4. Replikation prüfen. 5. KDC Dienst wieder auf automatischen Start setzen auf dem nun hoffentlich wieder replizierenden DC. Viele Grüße olc

Hi andrew, schau einmal hier hinein - https://technet.microsoft.com/en-US/library/cc770413(v=ws.10).aspx. Im Eventlog des OCSP Responders solltest Du alle relevanten Infos finden. Davon ab bin ich mir nicht sicher, ob certutil die Daten korrekt anzeigt. Probier es bitte auch einmal mit "pkiview.msc", zum Beispiel direkt von Deiner CA aus. Viele Grüße olc

Hi, bevor Du Dich auf einen "Timeout" des Scripts festlegst, schau erst einmal ob es noch andere Gründe geben könnte. Hast Du die Möglichkeit ein Logging in die Batch Datei einzubauen, welches in eine Textdatei schreibt (bzw. ggf. auch mehrere, je nachdem welche Infos Du abfangen möchtest)? Vielleicht bringt das ja noch weitere Einblicke. Viele Grüße olc