blub

Die Jobbeschreibung hört sich nach telefonischner Störungsannahme an. Man sucht jemand, der bestimmte IT-Begriffe schonmal gehört hat, verbindlich mit Kunden umgehen kann und ein Ticketsystem bedienen kann, aber auch nicht mehr.

Für Securitysettings nutzen wir das Snap-In "security configuration and analysis" sowie die inf-Dateien 1000-fach für Clients und Server, solange diese (noch) nicht in der Domäne hängen. Mit jeder GPO-Änderung in der Domäne wird auch das Template angepasst. Registrysettings kann man auch in den Securitysettings bzw. der inf-Datei setzen. Blub

Das machst du schon richtig. Viel Lesen (bzw. Videos schauen) und immer wieder die neuen Informationen reflektieren und hier andere Leute nach ihrer Meinung fragen. Blub

Mit dem Userpasswort kannst du ein TGT - Ticket des Userobjects erstellen. Mit dem Computerpasswort wird das Sessionticket für den Computer erstellt. Mit dem Computerpasswort ist es moeglich, ein modifiziertes Sessionticket zu erstellen und sich als Administrator des Computers anzumelden (ohne Kenntnis eines Admin-PWs natuerlich) Die SID ist quasi der interne, eigentliche Name der Objekte. Das Passwort eines Objects zu resetten, kann manchmal notwendig sein. Ein Object zu löschen, um es gleich wieder identisch neu anzulegen, wuesste ich jetzt keine Notwendigkeit. Es hoert sich so an, als ob dein Videotrainer nicht so ganz die Bedeutung von SID und Computerpasswort verstanden hat. Blub

Aus Neugierde nachgefragt: Bei welchem Fehlerbild soll lt. Video ein unjoin/ join helfen?

Das ist dann ja relativ überschaubar :-)

Der betreffende DC und die Uhrzeit der Sperre helfen doch schonmal, um das Event im Security Log zu finden. Oder hast du einen anderen Weg, das passende Event zu finden?

LockoutStatus.exe Das Tool ist hilfreich, um raus zu finden, von welchem Client aus der User gesperrt wird. https://www.microsoft.com/en-us/download/details.aspx?id=15201

Ich weiss nicht genau was du unter "Problem mit Secure Channel" meinst. Wenn man beispielsweise einen Attacker mit Admin-Rechten im Active Directory vermutet, kann es als eine Response Maßnahme von vielen sinnvoll sein, auch alle Computerpasswörter zeitnah zu resetten. https://technet.microsoft.com/en-us/library/hh849751.aspx , aber nicht per GUI Standardmßig wird das Computerpasswort alle 30 Tage automatisch neu gesetzt. Diesen Wert sollte man daher zumindest nicht noch weiter erhöhen. Oder meinst du den Secure Channel für Netlogon? Dann https://technet.microsoft.com/en-us/library/cc731935(v=ws.11).aspx -> nltest /sc_reset Damit kann man Clients dazu bewegen, sich ohne Reboot einen neuen DC auszusuchen. Wenn ein Rechner so verhaut ist, dass angeblich nur noch ein unjoin hilft, dann würde ich ihn nicht ohne Neuinstalltion wieder in die Domäne joinen.

Die Events werden von Rechnern erzeugt, auf denen User (Administratoren) sich angemeldet und nicht sauber abgemeldet haben. Wenn diese User dann ihr PW aendern, gibts die Events. War zumindest mal bei mir die Ursache. Btw: denk dringend drüber nach den 2003er zu tauschen. 2008R2 ist mindestens zu empfehlen. Ärger ist sonst programmiert.

Sind die 1030/ 1058 Events jetzt weg?

zur Frage im letzten Satz: kommt extrem darauf an, ob du bzw. deine Clients LLMNR nutzen. Bei uns ist es deaktiviert, was dir aber nicht weiter hilft. Wireshark könnte dir helfen, auch bei deinem eigentlichen Problem.

Du benötigst offenbar diese Methode https://msdn.microsoft.com/en-us/library/office/ff837618.aspx Google nach "XlInsertShiftDirection Powershell" ggf. auch nach "XlInsertShiftDirection VBA" "XlInsertShiftDirection C#" Wenn du kein passendes Powershell Beispiel findest, kannst du versuchen, passende VBA oder C# - Beispiele mit Hilfe der MSDN und der Record-Function des Excel-Makroeditors zu konvertieren. Das ist meist eine zeitaufwändige Frickelei! Wenn auch nicht dein spezielles Problem hier gelöst wird, hier sind eine Reihe von Excel COM-Beispielen zusammen gestellt: http://www.powershellpraxis.de/index.php/excel-com Alles nur schon ein bischen älter. blub

Vermutung: Du versuchst ein Array in eine einfache skalare Variable zu speichern. Das ist selbst noc h mit Powershell fehleranfällig.

Das Forum und auch ich erheben den Anspruch auf Professionalität. Und nicht die Vorstellungen offenbar ahnungsloser Personen unreflektiert stehen zu lassen. Weiteres Geschwurbel dazu ist nicht nötig.

Den Built-In Admin gar nicht benutzen und mit 25+x stelligem Passwort ausstatten.

Du solltest dann nur den Unterschied zwischen "ein Risiko akzeptieren" und "ein Risiko ignorieren" kennen. Bei "Akzeptieren" trägt bei Ausfällen dein Chef die Verantwortung, bei "Ignorieren" Du. Blub

Edgar, gegen deine Logik komme ich mal wieder nicht an.

Ein DC ist nunmal das Herz deiner IT. In dieses Herz musst du dann irgendwelche Printertreiber, die dir im Laufe der Zeit ueber den Zaun geworfen werden, installieren. Installiere u.a. schon deswegen keinen Printserver auf einem DC!

Ansich gibt es die Powershell-Session-Configurations schon mehrere Jahre. https://technet.microsoft.com/de-de/library/dd819508.aspx Mit "JEA" hat das Kind nur einen neuen, griffigeren Namen bekommen, zusammen mit noch ein paar Features dazu. Ich sehe JEA nicht als Werkzeug an, um die Security auch in Enterprise Umgebungen merklich zu erhöhen. Es wird natürlich spezielle Anwendungsfälle geben, die von JEA mehr profitieren JIT finde ich dagegen wertvoll und schon lange überfällig. Damit geht Microsoft den Weg, den Großrechner schon 20 Jahre (oder sogar länger ??) beschreiben. Administrationsrechte werden damit nur noch zeitlich begrenzt per Workflow-Prozess vergeben. Damit eliminiert Microsoft endlich eine Hauptschwachstelle von AD-Windows, dass Domainadministratoren jederzeit und überall alles dürfen.

Die "beschnittenen" Administratoren müssen zumindest mit den übrig gebliebenen Befehlen der Powershell umgehen können, um ihre Aufgaben zu erledigen. Das alleine wird schon schwierig zu erreichen. Aber nein, außer wagen Gedanken dazu haben wir noch nichts. Aber JIT (just in Time Administration) haben wir schon im Einsatz:-). Das bringt auch schon viel.

SBS habe ich noch nie selbst gesehen. Aber zumindest auf klassischen Servern soll ein DC keine weiteren Rollen bekommen. Sowohl aus operational, wie auch aus security Gründen. Blub

Das hängt vom confidentiality Level der Daten ab. Bei Level 1 sind selbst angewendete Tools oder Azubis mit einer Keule sicher Ok. Zum Beispiel bei VS-NFD Daten oder noch höher muss dagegen ein minutioses Protokoll eines zertifizierten Dienstleisters erstellt werden. Dazwischen ist viel Platz. Dein Chef muss dir sagen, wie er die Daten auf den Datenträgern einschätzt. Daraus ergibt sich die Anforderung an die Vernichtung, nicht umgekehrt!

Hört sich so an (auch aus den anderen Threads heraus), als ob der Scanner versucht, über SMB over Netbios (Port 139) mit dem Software-Server zu kommunizieren, mit den anderen Servern aber über 443 (SMB over TCP). Ersteres wurde durch den Patch offenbar (sinnvollerweise) abgedreht. Nimm einen Wireshark und verifizier das mal. Danach kann man da die Ursache suchen, warum der Scanner zu dem einen Server nicht über 443 geht. Und solange dir jemand nicht genau sagen kann, was er mit einer Umkonfiguration erreichen will, lass bitte die SMB-Protokolle, so wie sie sind! Blub

Hast du statt einer Exchange mal eine Cloudspezialisierung überlegt? Meine(!) Einschätzung ist, dass der Bedarf an Exchange-Spezialisten durch office365 eher sinkt, der Bedarf an Cloud-Spezialisten hingegen stetig steigt. Ein komplettes OnlineTraining zur Azure-Cloud kannst du dir hier anschauen; http://www.cloudranger.net/azure-training/ Entscheidend sollte aber sein, wovon du dich mehr angesprochen fühlst! Ansonsten: Versuch immer die aktuellste Version einer Software zu erlernen. blub