phatair

Danke euch beiden. Wir werden dies dann auch so umsetzen. Server Admin Accounts für jeden IT Mitarbeiter, diese Accounts werden dann Gruppen zugeordnet und diese Gruppen wiederum den entsprechenden Servern/Applikationen. Die Workstation Admins sind dann separate Accounts, Domänen Admins gibt es nur für spezielle Mitarbeiter und werden auch nur für solche Tätigkeiten genutzt. Anmelden von Domänen Admins an PCs wird unterbunden. Lokale Admin Passwörter werden über LAPS oder AdmPwd.E gemanaged. Als letzten Schritt werden wir dann noch die Server und Clients trennen (VLAN) und entsprechende Jump Server einführen. Da wir demnächst sowieso unsere komplette Firewall austauschen, werden wir das dort gleich berücksichtigen. Es gibt viel zu tun, aber es wird Zeit diese sehr gewachsene (und auch unsichere) Struktur endlich aufzuräumen

Also für mich bedeutet Service Account = Account unter dem ein Dienst ausgeführt wird. Davon spreche ich nicht. Ich meine Admin Accounts für bestimmte Applikationen z.b. um mich am vmware vsphere Web Client anmelden zu können oder in der Veeam Konsole etwas durchführen zu können. Das würde bedeuten, User1 kann sich mit User1 am Server 1, 2 und 3 anmelden und kann dort auch die Applikationen mit dem Benutzer User1 nutzen. Das würde bedeuten, er kann mit seinem "Server Admin" sowohl auf den Server als auch auf die Applikationen zugreifen, richtig? Die Methode von RolfW wäre, User1 kann sich mit dem Benutzernamen User1 am Server 1, 2 und 3 anmelden. Auf die Applikationen kann er dann aber mit dem User App1-User1 auf Server1, App2-User1 auf Server2 und App3-User1 auf Server3 zugreifen. Das würde bedeuten es gibt einen Server Admin Account, mit diesem kommt er auf die ausgwählten Server. Für jede Applikation gibt es aber dann noch mal einen extra Admin Account. Das wäre natürlich schon eine recht komplexe Vergabe von Admin Accounts. Verstehe ich das richtig?

Eine Frage stellt sich mir noch, vielleicht habt ihr hier auch noch eine Idee. Wir erstellen im 1. Schritt nun für die Admins erstmal 4 Accounts ( normaler User Account, Workstation Admin, Server Admin und für ausgewählte Kollegen einen Domain Admin). Nun gibt es ja aber auch Systeme die z.B. über eine Webseite oder eine eigene Konsole administriert werden. Hier werden dann ja auch Berechtigungen delegiert (z.B. vmware vSphere Client oder Veeam). Nun kann ich den normalen Benutzer oder den Server Admin Account dort verwenden. Was würde aus eurer Sicht mehr Sinn ergeben? Ich hätte jetzt gesagt, alle administrativen Tools werden dann auch über den Server Admin Account genutzt. Oder sollte man dann für jede Applikation noch mal einen eigenen AD User erstellen, der dann die Rechte in der Applikation erhält? Ich glaube die Zeit habe ich im Moment nicht und das wäre dann der nächste oder übernächste Schritt :) Was wären eure Ideen dazu?

Danke euch - ich sehe schon, dass kann ein großes Projekt werden :) Ich werde jetzt erstmal die Verwaltung der Admin Accounts anpassen. Wir werden pro Admin 4 Accounts verwenden (wie von Dukel geschrieben). Das sollte schon mal eine deutliche Verbesserung sein. Dann werden wir die Nutzung des Domain Admins unterbinden und schauen ob wir das über GPOs geregelt bekommen (https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html ) Die lokalen Admin Passwörter werden wir dann über LAPS oder AdmPwd.E verwalten. Danach werde ich mir Gedanken über die PAW/Jump Server machen und prüfen ob und wie wir unsere VLANs anpassen/erweitern müssen. Da bin ich dann mal etwas beschäftigt - aber das sehe ich als wichtig an. Vor allem da wir eher noch mehr IT Mitarbeiter werden. Vielen Dank für eure schnelle Hilfe und die Tips.

OK, soweit verstanden. Damit im "Schadensfall" nur die Clients betroffen sind und nicht die Server, sollte diese Trennung stattfinden. Aber was ist dann mit meinem PC. Ist es in Ordnung z.B. AD Snap-ins vom RSAT auf meinem Client auszuführen ("Als Administrator ausführen" und dann as entsprechenden Admin Server Login zu verwenden) oder sollte man lieber direkt auf den Servern per RDP arbeiten?

Ja, wir sind ein kleines IT Team (3 Leute - 50 Server - 200 AD User) Wir haben schon eine grobe Aufteilung, aber Clients macht bei uns jeder. Auf einige Server müssen wir alle mal schauen, andere wiederum nur ausgewählte Kollegen. Die AD macht eigentlich nur einer. Das dachte ich mir dann schon so, klingt am vernünftigsten aber natürlich auch am "Aufwendigsten". Aber Sicherheit geht immer etwas zu lasten von Komfort und hier muss dann jeder wohl seine Prioritäten legen. Unterschiedlich - die AD Verwaltung (DNS, User, Computer, DHCP, usw.) läuft eigentlich über die Admin PCs. Dort sind die RSAT Tools installiert und wir öffnen diese mit unserem persönlichen Admin um die Arbeiten durchzuführen. Das müsste so ja ok sein, oder ist es besser sich mit seinem persönlichen Server Admin per RDP auf den jeweiligen Server zu schalten und dort die Arbeiten auszuführen? Auf den Servern waren dann meistens Anwendungen offen, für die es keine "Remote Verwaltungskonsolen" gab und man eben direkt auf den Server arbeiten musste. Nichts zwingendes und eben nur Komfort. In Zukunft müsste man das eben erst noch öffnen, wenn man sich mit seinem persönlichen Server Admin Account angemeldet hat. Ich tendiere jetzt zu folgender Lösung 3 Accounts - normaler User, einen AD Admin und einen Server/Client Admin. Bin noch etwas unentschlossen ob wir wirklich die harte Grenze zwischen Server und Clients ziehen müssen. Ich muss mir auch noch den Link von testperson anschauen ( )

So machen wir das auch bei den Clients, nur muss das jetzt noch auf die Server ausgeweitet werden. Dienste sind auch alle mit separaten Accounts versehen (beginnen z.B. immer mit svc-<name des dienstes> Wir haben die personalisierten Admin Accounts berechtigt bestimmte Dinge in den ausgewählten OUs zu machen (z.B. Objekte zu löschen oder PCs aufzunehmen). Das müsste hoffentlich passen.

Das klingt sehr interessant - werde ich mir mal genauer anschauen. Danke für den Tip! Hm...heißt das, jeder der lesenden Zugriff auf das AD hat kann die Passwörter auslesen? AdmPwd.E klingt auch interessant und ist preislich auch fair. Werde ich mir auch mal anschauen. Das Programm scheint sich in die AD einzuklinken - ändert das auch was am AD Schema oder kann das Probleme beim AD Upgrade machen? Ja, wir haben nur eine AD/Domäne. So ähnlich haben wir es eben für die PCs gemacht. Jeder Admin hat einen normalen Account und einen Account der auf den PCs in der lokalen Admin Gruppe ist. Einen generellen Account haben wir nicht, damit es besser nachvollziehbar ist, wer was gemacht hat. Die Frage ist, ob dann für ausgewählte Kollegen ein persönlicher Domänen Admin Account erstellt wird oder wir hier den Standard Domänen Admin verwenden.

Guten Morgen, ich möchte bei uns in der Firma die Verwaltung der Admin Accounts überarbeiten. Im Moment arbeitet die IT Abteilung mit 2 Accounts ( einen normalen Benutzer Account für die tägliche Arbeit und einen Admin Account der nur genutzt wird, wenn erhöhte Berechtigungen verwendet werden). Beides sind AD Accounts. Wir haben uns bei der Verwaltung der Admin Accounts bei den PCs an dem Beitrag vom Mark orientiert (https://www.gruppenrichtlinien.de/artikel/verwaltung-der-lokalen-administratoren/) Auf allen PCs werden per GPO die Mitglieder aus der lokalen Administratoren Gruppe geschmissen und eine "Workstation-Admin" Gruppe hinzugefügt. In dieser sind dann die Admin Accounts der IT Abteilung. Somit können wir mit unseren Admin Accounts alles an den PCs machen, benötigen keinen Domänen Admin und es ist sichergestellt das auch sonst kein anderer Admin vorhanden ist. Auf den Servern sieht es im Moment noch anders aus. Hier arbeiten wir immer mit dem Domänen Admin Account. Das würde ich aber gerne ändern, da auch hier keine Notwendigkeit besteht. Nun könnte ich das genau so durchführen. Wir fügen auf den Servern eine weitere Gruppe (z.B. Server-Admins) der Administratoren Gruppe hinzu. Alle darin enthaltenen Admins können auf den Servern arbeiten. Bisher war es oft so, dass bestimmte Programme offen waren und jeder Admin diese gleich nutzen konnte. Das würde dann natürlich wegfallen, da jeder mit seinem eigenen Account arbeiten würde. Die andere Lösung wäre, man erstellt z.B. einen Server Admin Account und dieser wird auf allen Servern in die Administratoren Gruppe aufgenommen und man arbeitet mit diesem. Die lokalen Administratoren Accounts möchte ich über Microsoft LAPS verwalten. Das Passwort des Domänen Admin Accounts wird dann nach der Änderung geändert und nur noch für notwendige Tätigkeiten genutzt (von ausgewählten IT Kollegen). Wie macht ihr das den mit den Servern und den Admin Accounts? - persönliche Admin Accounts? - einheitlicher Admin Account? - lokalen Admin Account? - andere Lösung? Vielen Dank schon mal für eure Gedanken. Gruß

Hat wunderbar funktioniert. Danke! Wenn man keine eigene CA im LAN hat, ist das wahrscheinlich die einzige Möglichkeit interne Web Verbindungen mit einem Zertifikat zu versehen. Macht es dann Sinn ein Wildcard Zertifikat für lokale Anwendungen zu erstellen oder lasst ihr diese einfach über SelfSigned Zertifikate laufen?

Hallo zusammen, wir haben 2 IIS Server bei uns im LAN laufen. Diese stellen Webdienste zur Verfügung, die ich gerne per SSL absichern möchte. Wir haben noch keine eigene interne CA und ich sehe in den nächsten Monaten auch keine Kapazität das umzusetzen. Meine Idee wäre jetzt gewesen, über eine CA wie Geotrust ein SAN Zertifikat zu kaufen. Wir haben eine öffentliche Homepage und diese Domain ist identisch zu unserer internen Domäne (öffentlich domain.de, intern intern.domain.de). Wenn ich ein SAN Zertifikat auf domain.de ausstelle, kann ich ja dieses Zertifikat für unseren internen IIS verwenden (z.B. server.intern.domain.de). Seht ihr hier irgendwelche Probleme? Ich habe auch mit dem Gedanken gespielt, das Ganze über Lets Encrypt zu machen. Aber hier komme ich nicht weiter und mir fehlt die Zeit mich weiter einzulesen. Wenn das wie oben beschrieben funktionieren sollte, wäre das der schnellere und einfachere Weg (natürlich auch kostenpflichtig). Vielen Dank schon mal für eure Hilfe. Gruß

Hi Dukel, danke für den Tip. Ich habe nun für die Default Web Site eine Umleitung festgelegt. Nach einigen Tests funktioniert es jetzt auch. Ich musste beim Umleitungsverhalten die Option "Anforderungen zu Inhalt in diesem Verzeichnis (nicht in Unterverzeichnissen) umleiten" aktivieren und den Statuscode auf Dauerhaft(301) setzen. Wenn ich den Haken bei der "Anforderungen zu Inhalt in diesem Verzeichnis (nicht in Unterverzeichnissen) umleiten" nicht setze wird die URL mehrmals hinten angehängt und nichts funktioniert. Aus http://Anwendung wird dann http://server/Anwendung/Anwendung/Anwendung/Anwendung usw. Wenn ich die Hilfe zu der Option richtig versehe, wird die Umleitung dann auch für jede Unterordner angewendet. Verstehe ich jetzt irgendwas komplett falsch oder kann man die Konfig so umsetzen?

Hi mwiederkehr, danke dir. Das Problem ist, die Webseite besteht aus 2 Anwendungspools - kann ich da genau so verfahren? Eine neue Webseite erstellen (die benenne ich wie ich möchte) Dieser Webseite beide Anwendungspools anhängen Bindung für die neue Webseite erstellen und den gewünschten Namen verwenden DNS Eintrag erstellen

Hallo zusammen, wir setzen bei uns im internen LAN einen Win Server 2012R2 mit IIS ein. Über diesen wird eine Software für die Fertigung realisiert. Nun ist diese Software im Moment über die URL http://<Server-Name/Anwendungsname> aufrufbar. Ich möchte aber die Webseite über http://<Anwendungsname> erreichbar machen. Irgendwie stehe ich auf dem Schlauch und ich bin auch kein großer IIS Experte. Ich komme einfach nicht dahinter wie ich das ändern kann (muss man hier über die Bindungen im IIS arbeiten?). Ein DNS Eintrag (CNAME) von <Anwendungsname> -> <IP des Servers> funktioniert nicht, da dort nur die IIS Seite erscheint. Ich muss die Webseite zwingenden über <Server-Name>/Anwendungsname aufrufen. Kann mir jemand einen Tipp geben, wie ich es hinbekommen? Im Moment sieht es so aus http://server/meine-Anwendung funktioniert. Ich möchte aber die Seite über http://meine-Anwendung aufrufen können. Vielen Dank schon mal. Gruß

Jep, also es ist so. Auch der Organisator sieht dann im Kalender des Raumpostfaches nur noch den Namen des Organisators. Den Betreff sieht man nur noch im eigenen Kalender. Macht so ja auch nur Sinn - trotzdem gut zu wissen :)

Ich teste das am Montag mal und schreibe das Ergebnis hier rein. Vielleicht interessiert es ja noch jemanden.

Jap, dass ist richtig. Ich bin aber auf dem Heimweg, sitze im Zug und dachte ich Frage einfach mal. Ich würde auch gerne wissen, ob das der richtige Weg ist. Ich mache sonst nicht viel bei uns am Exchange und sichere mich gerne etwas ab bevor ich irgendwelche Befehle eingebe :) Wenn ich am Montag keine Antwort habe, teste ich es selber und Antworte mir hier selber ;)

Hallo zusammen, wir verwenden noch Exchange 2010 SP3 und ich würde gerne in den Raumpostfächern den Betreff ausblenden und den Organisator anzeigen lassen. Nach kurzer Recherche im Internet gebe ich dazu ja folgenden Befehl ein: Set-CalendarProcessing -Identity <RESOURCEMAILBOX> -DeleteSubject $True -AddOrganizerToSubject $True Damit würden dann der Betreff durch den Organisator ersetzt werden. Die Standard Berechtigung auf den Raumpostfächern ist "Standard" -> Frei/Gebucht-Zeit, Betreff, Ort Das müsste dann ja soweit passen. Den Betreff des Termins sieht dann auch der Organisator nur noch in seinem eigenen Kalender, im Kalender des Raumpostfaches sieht er ihn nicht mehr. Richtig? Vielen Dank. Gruß und ein schönes Wochenende!

Ok, ich bin mit den Gedanken wohl noch in 2018 - Sorry. Die Meldung war nicht von Windows, sondern kam von ZenWorks. Wir haben letztes Jahr die Lizenz verlängert und hatten vergessen im System eine Lizenz zu aktualisieren. Hat sich somit erledigt.

Hallo zusammen, wir imagen bei uns alle neuen PCs mit Windows 10. Bisher wurde hier Windows 10 Pro 1703 verwendet. Es handelt sich dabei um eine VL Pro Version. Das Iso wurde aus dem MS VLSC geladen. Wir erstellen für die Iso eine unattended.xml, es wird von der ISO+XML gebootet und das Base Image eingerichtet. Danach mit Sysprep finalisiert und ein Base Image erstellt. Dann wird das ganz mit einem Tool (Novell ZenWorks und Imaging Toolkit) per PXE verteilt. Die Windows Aktivierung findet über einen KMS statt (Server 2012R2) und der KMS Server + Win 10 Client KMS Key wird im Image verteilt. Das hat mit der 1703 Version wunderbar funktioniert. Nun mussten wir auf 1803 updaten und dazu wurde wieder ein neues Image für neue PCs erstellt. Gleiches Vorgehen wie bei der 1703 Version. Das ganze wurde Ende Oktober gestartet und jetzt erhalte ich beim Imagen (und dem ersten Start von Windows) folgende Meldung: Warum das auf einmal? Ich dachte durch das Sysprepen wird der Aktivierungszeitraum auf Anfang gestellt und außerdem gebe ich ja im Image den KMS Server + Key mit. Beim 1703 Image hat das ja auch problemlos funktioniert. Muss ich auf dem KMS Server noch irgendwas nachziehen? Wir haben bestehende 1703 Win 10 PCs auf Win 10 1803 upgedated und diese werden einwandfrei über den KMS aktiviert). Ich wüsste nicht das ich irgendeine Evaluierungsversion genutzt habe. Es war die offizielle Win 10 1803 Pro Iso aus dem VLSC. Für Hilfe wäre ich sehr dankbar. Bin gerade etwas ratlos...

Hallo zusammen, mich würde mal eure Meinung zu folgender "Problematik" interessieren. Im Moment setzen wir per GPO die Word und Excel Einstellungen so, dass vertrauenswürdige Dokumente und Speicherorte deaktiviert sind. Alle Dateien die Makros beinhalten, werden mit deaktivierten Makros gestartet und der User muss über den gelben Button erst zustimmte, dass diese ausgeführt werden. Das muss jedes mal beim öffnen der Dateien gemacht werden, ganz egal ob die Dateien im LAN liegen oder von Extern stammen. Auf Grund der aktuellen Entwicklung von Emotet usw. werden wir jetzt Makros aus unsicheren Quellen (Internet, Mail Anhang, usw) komplett blockieren, so dass diese Makros gar nicht mehr ausgeführt werden können. GPO -> Ausführung von Makros in Office-Dateien aus dem Internet blockieren Weiß jemand, woran Microsoft das fest macht, ob eine Datei aus dem Internet stammt und somit unsicher ist? Nun versuche ich die ganze Richtlinie etwas zu überdenken. Macht es vielleicht Sinn die Netzlaufwerke als vertrauenswürdige Speicherorte zu definieren, damit hier die Makros gleich aktiviert werden (und die User nicht immer erst auf den gelben Button klicken müssen). Oder sollte man den Usern die Möglichkeit geben Dokumente als vertrauenswürdig hinzuzufügen? Mein Gedanke ist, dass es irgendwann zur Routine wird den gelben Button zu drücken, wenn alle Dateien immer und immer wieder diese Aufforderung benötigen. Das ist dann natürlich auch nicht sonderlich hilfreich. Wenn man allerdings vertrauenswürdige Speicherorte angibt, ist hier natürlich gleich alles aktiviert und es gibt gar keine "Warnung". Wie habt ihr das bei euch gelöst? Wäre für Tipps sehr dankbar. Gruß

Genau so läuft es bei uns auch. Die neuesten ADMX Templates verwenden wir im Central Store und bearbeiten die GPOs immer über das entsprechende OS. Genau das hat sich ja in dieser Diskussion für mich geklärt.

Hm... weiß nicht genau was du jetzt meinst. Die GPO Einstellung schreiben meist in HKLM oder HKCU einen Wert z.B. Reg_SZ oder DWORD. Nach deiner Erklärung werden diese Werte, also z.B. ein DWORD, auch geschrieben, wenn die GPO eigentlich nicht für die Windows Version geeignet ist. "Alte Windows" Versionen lesen diesen Wert, in diesem Falle ein DWORD, nicht aus und somit ist diese Einstellung aus der GPO auch nicht wirksam. Neuere Windows Versionen lesen den Wert, also das DWORD, aus und somit ist auch die Einstellung aus der GPO wirksam. Diese Info finde ich ganz hilfreich und ich glaube nicht das ich eine unpassende Vorstellung von Registry-Keys habe. Vielleicht habe ich mich nur falsch ausgedrückt.. Es hätte ja auch sein können, dass dieses DWORD gar nicht in die Registry geschrieben wird, wenn die Windows Version unpassend ist. Danke - dir ebenso ein schönes Wochenende.

Richtig, hatte ich ja erwähnt. Für mich ist es nur gut zu wissen, dass die Registry Keys trotzdem erstellt werden. Wer weiß ob einem dies doch mal irgendwie in die Suppe spuckt und dann ist diese Info Gold wert :)

Hi Nils, danke - so habe ich mir das auch vorgestellt. Ich sehe nur ein Problem (das aber schon sehr konstruiert ist). Wenn dieser Wert in der Registry erstellt wird und man z.B. über eine GPO oder ein anderes Programm wie z.B. SCCM oder ZCM diesen Wert abprüft um davon z.B. auf die Windows Version zu schließen, könnte es zu Problemen kommen. Aber das ist wie gesagt schon sehr konstruiert und wird in der Realität nicht vorkommen. Aber es ist gut zu wissen, dass die Regedit Einträge geschrieben und nicht ignoriert werden, wenn sie nicht für die Windows Version gemacht wurden. Ich werde dann weiterhin nur 2 Win 10 GPOs haben - eine für User Einstellungen und eine für Computer Einstellungen.