blub

In den comments des Artikels habe ich noch diesen PS-Test gefunden

new-object system.security.principal.windowsidentity("username")

probier doch mal, ob sich LLTS updated

Lt. Artikel wird der LastLogonTimestamp aktualisiert, wenn irgendjemand/ etwas einen Accesscheck z.b. auf einem Fileserver durchführt oder die GroupMembership des Accounts prüft. Auch durch bidirektionale Trusts kann der LLTS aktualisiert werden.

Der Account müsste nicht nur gesperrt, sondern sauber entrechtet wird. d.h. aus allen Berechtigungs-Gruppen entfernt wird.

Hi,

Das Phänomen des sich aktualisierenden LastLogonTimestamps bei StaleAccounts kommt vom Service-for-User-to-Self or, “S4u2Self,”

see 

http://blogs.technet.com/b/askpfeplat/archive/2014/04/14/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self.aspx

Das Verhalten hat mich auch schon mal hochgejagt :-), ist aber "by design"

blub

Hallo

 

er hat in der Domäne für sein Konto Anmelderechte für die beiden AD-Server, seinen eigenen Rechner und den Exchange Server.

Ansonsten hat er noch Webmail Zugriff.

d.h. das Konto hat Domain Admin, lokale AdminRechte, Exchange Admin Rechte, wird für Webmail  und sicherlich auch zum Surfen genutzt? Dann fände ich das Verhalten gar nicht so merkwürdig.

Über die Zukunft einiger heute selbstverständlicher Technologien

http://www.networkworld.com/article/2971854/security/10-security-technologies-destined-for-the-dustbin.html?page=1

see No.6 (Antivirus Scanners)

Den Neukauf großer und teurer AV-Produkte würde ich auch unter diesem Gesichtspunkt überlegen.

blub

Um mehr als 1000 Einträge zurückzubekommen, gibt es für LDAP-Abfragen die PageSize-Property (schon seit Beginn des AD!)

https://msdn.microsoft.com/en-us/library/system.directoryservices.directorysearcher.pagesize%28v=vs.80%29.aspx

Wenn eine Anwendung bzw. Programmierer diese Property nicht einsetzt bzw. nicht kennt, dann besteht in erster Linie Schulungsbedarf bei den Entwicklern! 

Um generell LDAP-Anfragen zu optimieren, schau dir mal den Artikel a

http://blogs.technet.com/b/askpfeplat/archive/2015/05/11/how-to-find-expensive-inefficient-and-long-running-ldap-queries-in-active-directory.aspx

cu

blub

die "doofe" Zertifikatsmeldung?

Hallo CC84

wenn die 500 Mitarbeiter sich keine Passwörter merken können, dann werden Sie wahrscheinlich auch Smartcards oder USBsticks sehr oft im Rechner stecken lassen, diese verlieren oder untereinander austauschen. Dann bleibt ja nur eine bioemtrische Lösung übrig.

Möglich wäre z.B. die Fingerprintlösung von digital persona. Der Fingerprint wird hier verschlüsselt in der Domäne gespeichert und kann zusätzlich mit einer mehr oder weniger einfachen PIN (unabhängig vom  Passwort)  als 2.-ten Faktor abgesichert werden. Damit kann sich jeder Mitarbeiter mit seinem Finger und z.B. einer 4-stelligen PIN an jedem Rechner mit Fingerabdruckscanner anmelden. Passwortwechsel sind dann egal.
Billig ist die Lösung sicher nicht. Benötigt werden: ein hochwertiger Scanner http://www.amazon.com/DigitalPersona-U-are-U-4500HD-fingerprint-software/dp/B002S3ZSJU + Softwarelizenz + wahrscheinlich notwendige Implementierung durch ein externes Systemhaus
Ganz grob geschätzt landest du bei mindestens 125€ / User. Wenn du Interesse hast, kann ich dir Kontaktdaten zu einem Systemhaus geben, das uns bei digital persona sehr gut unterstützt hat.

Besonders zu Beachten ist generell der obige Hinweis auf "interlektuelle Defizite mit der IT"  ;)

Hallo,

Vielleicht sagst du deinem "halbwegs technisch bewanderten Chef", dass man auch mit langen, komplexen Passwörtern incl. Handstand und Füßewackeln Windows 2003 und Windows 2008 Server nicht mehr annähernd sicher bekommt. Alleine schon von der Kryptograhie her unterstützen diese Systeme kein TLS 1.2 und sind damit offen!

http://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx

blub

Und 2003 als Sicherheitsrisiko ist natürlich egal... Da braucht man nicht mal das Passwort hacken.

Das Ende der Welt, wie wir sie kennen

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B367#fbid=

https://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/

freut mich :)

Jepp. Bekanntes Problem?

pfx und cer sind verschiedene Codierstandards (pkcs11 und pkcs7). Du kannst das pfx-Zertifkat samt Passwort in dein Windows importieren und anschließend als DER-binary-File (ohne pw) wieder exportieren. Dann hast du ein korrektes *.cer

*.cer - kodierte Zertifikate haben keinen privaten Schlüssel. Hast du vielleicht ein pfx-Zertifikat nach *.cer umbenannt und bringst damit dein System durcheinander?

Hast du vielleicht im IE oben einen Filter gesetzt:

"Beabsichtigter Zweck" - <Alle>

blub

http://lustich.de/community/forum/28762-Bayrisches-Grundgesetz/

-> $10

:)

hast Recht! Und wer Recht hat, zahlt a Mass :)

und noch ein wenig mehr :-)

get-childitem $SrcRoot -recurse -directory |  ?{$_.Name -eq 'def'}  foreach-object {     #-directory geht ab PS3.0
    $Pfad= $(Get-Item $_.Fullname).Parent

nur rein interessenhalber:

Woher habt ihr dieses Ruleset für die Passwörter?

Ihr solltet euch an Standards halten, wie etwa
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m04/m04048.html

https://www.bsi-fuer-buerger.de/BSIFB/DE/MeinPC/Passwoerter/passwoerter_node.html

Heutzutage ist eine PW-MindestLänge von 12 absolutes Minimum, eher 15 oder 16 Zeichen.

blub

Wenn es nur um die Verwaltung dieses eines Servers geht, dann kannst du dir mit makecert ein neues Zertifikat bauen.

https://msdn.microsoft.com/de-de/library/bfsktky3%28v=vs.80%29.aspx

(du brauchst ein Rootzertifikat und ein oder mehrere Zerts für dein(e) Server)

Wer hat dir das jetzige Zertifikat erstellt?

blub

Wenn's in der GUI nicht funktioniert, kann man es, nach Treiberupdate, auch mal mit Kommandlinetools versuchen:

- devcon
- netsh wlan

blub

https://technet.microsoft.com/en-us/library/hh848479%28v=wps.630%29.aspx

hast dir schonmal überlegt für den Aufbau von Testumgebungen in die Cloud zu gehen? z.B. AWS oder Azure? Ich habe meine Testmaschinen nur noch in Azure - genial - und spart Geld.

blub

 bei uns dürfen aber eh alle ITler in die Serverräume.

klar, dann ist der Punkt bei euch irrelevant!

Aber es ist ein großer Schritt hin zum DomainAdmin bzw. zum Angriff z.B. auf Konten

 

Würde ich so nicht unterschreiben. Ob mann nun physisch Zugriff auf den Server hat oder über Virtualisierung ist dann auch egal. Spätestens mit Server 2016 gibt es mit den neuen sicheren VMs dann eine Lösung für die VMs für ganz Sicherheitsbewusste.

z.B. haben wir 15 handverlesene Domainadmins für unsere DCs. Würden die DCs virtualisiert laufen, hätten mit einem Schlag ca. 20 VM-Admins mehr Zugriff auf diese DCs. Das ist schlicht ein potentieller Nachteil von Virtualisierungen, ebenso wie z.B. die Hardwareunabhängigkeit ein klarer Vorteil ist.