blub

was du unter "debug-logfiles" verstehst, solltest du dann auch dazu schreiben. Ich habe mir mal dein Logfile angesehen: Diese Zeilen wiederholen sich laufend: wenn du dann hier liest: https://technet.microsoft.com/en-us/library/cc773013.aspx -> NTP Security würde ich auf die Schnelle sagen, dass es zwischen Client und Zeitserver "192.168.200.52" ein Kerberosproblem gibt.

so schlecht scheint der Jobmarkt momentan nicht zu sein: http://www.silicon.de/41629989/automobilindustrie-lockt-it-experten-mit-hohen-gehaeltern/ mit Studium (Bachelor, Master, Doktor) bist du in der IT m.E. niemals "überqualifiziert". Du kannst dich damit allerdings auf qualifiziertere Stellen bewerben. Der klassische, nur mittelmäßig qualifizierte Click-Next bzw. File- und PrintAdmin wird aussterben.

Ist mir grad zufällig über den Bildschirm gelaufen https://support.microsoft.com/en-us/kb/816043 vielleicht gibt es einen Hinweis auf betroffenen Maschinen

auja, das stimmt leider

warst du schon mal beim Anwalt? Wenn eine Stelle "über" ist, dann muss die PersonalAuswahl auch unter sozialen Gesichtspunkten erfolgen (Betriebszugehörigkeit, Lebensalter, unterhaltspflichtige Kinder). Deine zuständige Gewerkschaft könnte dir auch helfen bzw. bei Beitritt die Anwaltskosten übernehmen. Sobald die Kündigung im Briefkasten liegt, laufen einige wichtige Fristen los. Sofern du eine Kündigung nicht einfach hinnehmen willst, spätestens dann keine Zeit mehr verlieren!

Falls du schon mit Server 2016 üben möchtest, da gibt es im Hyper V "Production Checkpoints" z.B. für replizierende DCs https://redmondmag.com/articles/2016/07/01/hyperv.aspx -> Backup and Checkpoint https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview (download) blub

im Prinzip nochmal dasselbe: $datum = "13.04.2015 16:04:05" $Culture = New-Object System.Globalization.CultureInfo("de-DE") $Date = [DateTime]::parseexact($Datum,"dd.mm.yyyy HH:MM:ss",$Culture)

Security ist eh nur was für Feiglinge ;) "DisableStrictNameChecking" kommt noch aus Windows2000 Zeiten. Damals waren solche Setting noch halbwegs vertretbar! Heute würde ich nicht mehr so locker, flockig derartige Features disablen wie damals.

Danke! Der Link kam mir gerade recht!

und wenn der Searchaccount bei jedem Filezugriff sich erneut mit NTLM gegen das AD authentifiziert, dann dauert das nachvollziehbar länger, als wenn Kerberos das mit einem einzigen Ticket abfackelt. Vielleicht hilft es geschwindigkeitstechnisch die Authentifizierung im SMB2.0 abzuschalten. (GPO: Security Options -> Microsoft Network Client: Digitally sign...). Allerdings verliert man dadurch Security.

a-tens) direkt FQDN und Kerberos: wunderbar b-tens) CNAME und Kerberos: geht konzeptionell nicht. Das ist so! Ich schätze, dass er bei b-tens) eine Fallbackvariante findet, die dann zumindest bei der Suche viel langsamer arbeitet. Ich bin aber absolut kein Fileserverspezialist. Es kann durchaus sein, dass es funktionierende Workarounds gibt!

Hallo Gemeindemitglied :-) Lösung habe ich keine, aber zumindest den vermutlichen Grund: http://blogs.msdn.com/b/gregmcb/archive/2008/03/08/kerberos-fails-when-using-cname.aspx Kerberosauthentifizierung und CNAME passen nicht zusammen! blub

Hi, Kannst du das Skript mal versuchen als Task zu starten? GPO -> User Configuration -> Preferences -> Scheduled Tasks New -> Scheduled Task -> ... General -> Action: Create ->.... Triggers: At logon, Delay: 30 Seconds blub

hast du auf den advanced permissions am File mal nachgesehen. Das Read besteht ja aus mehreren Unterrechten (Read attributes, etc.). Jedes Unterrecht liefert möglciherweise ein eingenes Event. Ist jetzt nur eine fixe Vermutung, blub

Habt ihr keine Auszubildenden oder Werkstudenten? Die sind meist recht fit was ActiveDirectory, LDAP, Scripting angeht bzw. können sich sich schnell in die Materie einarbeiten. Die Aufgabe wäre dafür absolut geeignet!

Offenbar vermutet ihr einen kriminellen Vorgang mit finanziellen Schäden. Aus deinem eigenen Interesse lass da einen Profi (Systemhaus) ran und halte dich mit Vermutungen und Tipps an deinen Freund zurück! Du schreibst ja selbst, dass du nicht mehr "im Bereich ganz aktuell bist".

Hast du schon versucht, eine aktuelle mso-Datei einzuspielen? https://support.microsoft.com/en-us/kb/2987489

Hast du einen Provider eingetragen, der SHA256 kann? z.B. https://blogs.technet.microsoft.com/pki/2013/09/19/upgrade-certification-authority-to-sha256/ Es gibt aber noch mehr Provider, die SHA2 können.

Ich kann dir meine Onlinelinks geben, unter denen es, jedenfalls meiner Meinung nach, ebenfalls hervorragende Papers gibt www.faqs.org/faqs/cryptography-faq (!) www.schneier.com/paper-pki.html www.verisign.com/enterprise/library www.entrust.com/resourcecenter Eine schöne Aufgabe für einen Azubi, sich da durchzuwühlen Sofern jemand weitere gute Links zum Thema PKI/ Crypto kennt oder findet, immer her damit!

"Nördlich der Alpen" -and "Südlich der Donau" bin ich mir fast(!) sicher :-)

Es gibt zumindest eine Policy Computer Configuration -> Security Settings -> Wireless Network -> create Policy -> Add -> Infrastructure -> Security unter Authentication gibt es alle möglichen Methoden: - WPA Enterprise - WPA2 Personal - WPA2 Enterprise Ich habe diese GPO selbst noch nie probiert!

Frag deinen Kumpel, ob er CAP (Central Access Policies) kennt und damit Berechtigungen konfiguriert hat. Die zugehörige Lasche im Explorer ist nicht immer zu sehen. Neben Shareberechtigungen, NTFS sind Central Policies quasi noch ein drittes Berechtigungstor. Am besten "View effective access" von einer Datei ansehen. btw: MIC (Mandatory Integrity Control) wäre ein viertes Tor. Aber das wird es wohl hier nicht sein, außer der User wird dauernd nach Adminrechten gefragt. Dann wäre das Userlevel im Vergleich zum Filelevel zu niedrig. (Nachtrag: gerade nochmal getestet: bei Kopiervorgängen spielt MIC keine Rolle, sondern nur beim Löschen von Dateien oder Ausführen von *.exe etc.)

Ahh, du meinst: Aber ja: "die üblichen Windows-Admins" ..... :D Boardmitglieder sind selbstverständlich nicht gemeint!

Eine Idee aus ganz alten Zeiten: Druckertreiber Mach mal einen anderen Drucker zum Default Printer

viele Maschinen sind wahrscheinlich auch nicht ordentlich gepatched https://support.microsoft.com/en-us/kb/3080079 dann fliegen die Credentials mit TLS1.0 quasi im Klartext durch die Netze Aber ja: "die üblichen Windows-Server" .....