magheinz

Jap, ich wollte es nur als Info ergänzen. Die meisten Konzepte von MS sind halt für riesige Umgebungen gedacht. Wenn man die dann auf KMUs runterbricht muss man halt schauen ob man etwas anpassen will.

richtig, das ist pro User. Wird der token zu groß scheitert die Anmeldung. Im eventlog steht dann glaube ich sowas wie: "zu viele Gruppenmitgliedschaften". Man kann das einfach ausrechnen. In der KB ist irgendwo eine Formel. Oder auch hier: https://www.msxfaq.de/windows/kerberos/kerberosticketsize.htm#groesse_berechnen Im übrigen ist das ein Grund warum man AGDLP macht. Im Forst sind nur die Gruppen der lokalen Domäne im Token. Würde man die Permission über globale Gruppen verwalten wären immer alle im token.

Muss es revisionsicher sein? Falls nein gibt es benno auch als openbenno!

Man kann die Token-max-size vergrößern. Und ja, mit jeder Gruppemitgliedschaft wird der token größer und erreicht irgendwann das maximum. Das hat mit der Anzahl der Mitarbeiter nichts zu tun.

Von wie vielen accesspoint reden wir hier? In Variante 1 bräuchte man ja einen zweiten Controller!

Bei uns ist RDP für die jeweiligen Admins offen. Die VMwareconsole ist aber natürlich auch möglich und die Windowsrollen werden per RSAT vom admin-server aus verwaltet.

.Wenn die domain User sich nicht auf den Servern einloggen sollen, dann würde ich ihnen auch technisch dieses Recht entziehen. Ich stehe da auf dem Standpunkt, dass Regeln die man technisch nicht durchsetzen kann sinnlos sind. Ansonsten: niemals manuel eintragen, immer per GPO/GPP. Ich würde mich da streng an AGDLP halten, also eine Domainlokale Serveradmin-Gruppe pro Server. Diese dann per GPP den lokalen Admins hinzufügen. Dann eine globale Gruppe Serveradmins wenn jeder admin jeden Server administrieren soll, ansonsten halt mehrere. Dann diese bei den jeweiligen domain lokalen zum Mitglied machen. Was sind denn für dich hier die jump-server? Wir hier haben z. B. Einen Terminalserver auf dem alle admin tools etc installiert sind. Von dem aus kommt man in jedes VLAN.

Ich dachte man macht AGDLP? Jetzt alow AGLP oder sogar AGP?

Bei den VLANs musst du halt schauen nach welchen Kriterien du separieren willst: geografisch(Liegenschaft, Gebäude, Etage, Raum etc) , funktional(Pers. Abt., fertigung, Einkauf etc) , nach Gerätetyp etc. Man kann das auch alles mischen. Mach dir auf jeden Fall vorher einen vernünftigen Plan, überlege welchen Sinn die VLANs haben sollen etc. Soll das alles der Sicherheit dienen soll, mach dir gleich noch Gedanken über 802.1x, TACACS etc

Sorry, aber sich über juristische Themen zu unterhalten ist was anderes als eine juristische Beratung.

Das googlesuchwort dürfte "arbeitnehmerhaftung" sein. Das Thema hat durchaus eine gewisse Komplexität. Im allgemeinen haftet man für alles was mehr als leichte Fahrlässigkeit anteilig oder voll. Tarifverträge können das einschränken(TVöD, Bat z. B.)

Das klingt für mich alles wie "von hinten durch die Brust ins Auge". Redundanter, verfügbarer Storage kosten doch heute nicht mehr die Welt. Solche Dinge sollten automatisch passieren. Die Fehlerquellen eine Schicht oder mehrere weiter oben wären mir viel zu unsicher.

Kannst du nicht das Storagesystemen verfügbar halten? Irgendetwas geclustertes sollte doch möglich sein. Mit Freenas wäre das sogar lizenzkostenfrei möglich.

Prinzipiell geht das mit ausfallsicherem Storage. Unsere Ordnerumleitungen liegen auf einer netapp. Die wiederum mirrord auf eine zweite.

Es ist aber nunmal Stand der Technik dass die biometrischen Scanner mit relativ wenig Aufwand überwunden werden könne. Wenn ich mich jetzt noch recht erinner wird hier konkret doch sogar eine kriminelle Energie vorausgesetzt. Chipkarte + Pin + Biometrie sind ja schon drei Faktoren! Ich würde ja erst mal anfangen und z.B. von den Mitarbeiter welche mit den sensiblen Informationen in Berührung kommen Führungszeugnisse verlangen. Ist der Bestand der Firma in Gefahr wäre eine Sicherheitsüberprüfung möglich. Die beste Technik hilft oft wenig wenn die Mitarbeiter wirklich mit krimineller Energie arbeiten. Dann ist eine Sensibilisierung der Kollegen sinnvoll. Das beste Passwort nützt nix wenn ein Kollege das am Telefon z.B. der IT-Abteilung verrät.

Kann ich bestätigen, wobei wir von denen bisher nur ein paar Notebooks hatten. Dafür vollkommen problemfrei. Im Fall der Fälle kam immer am nächsten Tag ein Techniker und hat den Defekt repariert, auch wenn es offensichtlich ein verlorener Kampf gegen eine Tasse Kaffee war.

SUN hat sich ja wie IBM auch erledigt. eine Zeit lang baut Fujitsu noch die Hardware, aber wer kauft schon abgekündigte Hardware.

Bin auch für 2 Faktoren. Allerdings würde ich die Biometrie weglassen. Biometrie hat für mich viel zu viele Nachteile. Da braucht man ja kein Glas für eine gute Kamera mit einem Teleobjektiv genügen. Mehrfach demonstriert auf CCC-Veranstaltungen.

Das ist halt unsere Erfahrung...

Wir hatten Bladeserver welche mehr als ein halbes Jahr nicht liefen weil IBM die nicht stabil bekommen hatte. Bei jedem Supportflall müssten wir die Verträge einschicken da IBM nicht wusste welche Geräte noch im Support waren und welche nicht. Die Bladeserver wurden schlussendlich komplett getauscht was dann aber Lenovo veranlassen müsste. IBM wollte munter weiter Teile tauschen obwohl schon nichts mehr original war. Die Techniker erklärten uns damals dass IBM/Lenovo kein Interesse mehr an Kunden in Berlin und im Norden von Deutschland hätte. Alles würde um Süden zentralisiert werden und z. B. Berliner Stellen nicht bachbesetzt. Das war damals nicht nur bei uns so. Das Bundesbeschaffungsamt drohte damals IBM mit der Auflösung der Rahmenverträge. Auch die uns bekannten Systemhäuser sind auf Grund schlechter Erfahrungen weg von IBM/Lenovo als Server und verkaufen heute andere Hersteller. Wir sind dann von IBM/Lenovk weg zu cisco geflüchtet und waren echt überrascht wie durchdacht Hardware sein kann. Auch der Service läuft dort rund.

1. Anforderungen definieren 2. Budget klären 3. Markt analysieren. Ich z.b. mag die 800er von cisco ganz gerne.

Oder du hast jetzt eine Anforderung bekommen, die mit der vorhandenen Fritzbox nicht sauber, Oder sogar gar nicht, umsetzbar ist.

Vernünftige Relays sind ok. Die sollten auch gleich filtern. LBs die die Meldungen nicht vernünftig auswerten sehe ich immer wieder. Wenn es um große Farmen mit einer f5 oder so davor handelt, dann sieht die Sache natürlich anders aus. Wer aber nur zwei Server in einer DAG betreibt welche auch noch direkt im internet hängen, der kann sich das Geld sparen. LBs für die anderen Protokolle kann man mit opensource betreiben.

LB macht ja auch für IMAP, POP3, HTTPS etc Sinn. Für SMTP, vor allem für die MXe, aber eben im Regelfall nicht. Hier kann man das Loadbalancen direkt dem Absender überlassen. Durch die Priorisierung im DNS kann man schon Ausfallsicherheit und Lastverteilung abdecken. Man benötig LBs die nicht nur stumpf verteilen sondern z.B. auch SMTP-Fehler auswerten. Ein einliefernder SMTP-Server z.B. kann mit einem Fehler wie 452, 450 etc etwas anfangen. Die meisten LBs werten das nicht aus und verbinden fleissig weiter an diesen SMTP-Server. Und selbst wenn der LB das kann? Wozu sollte man das Geld ausgeben wenn das Protokoll schon alles notwendige abdeckt? Gerade wer viele E-Mails empfängt wird merken, dass die meisten Absender schon auf die MXe verteilen. LBs für alle anderen E-Mailprotokolle sind dagegen sinnvoll da man die Priorisierung leider im DNS für alle anderen Records vergessen hat. Üblicherweise stehen die Echangeserver ja nicht nur hinter einem LB, sondern auch hinter einem Filter, Firewall etc.

Z.B. wenn es um Geo-Loadbalaning geht oder ein Filter vor dem Exchange hängt der nicht den MX abfragt oder man LB- Algorithmen nutzen möchte, welche über die Priorisierung hinausgehen, welche auch immer. Auch bei einer DAG habe ich ja zwei unabhängig funktionierende SMTP-Server. Die DAG-Funktionalität ist ja nur für die Postfachdatenbank zuständig. Wieso hier also ein LB?