Deaktivierter Domänenadministrator weiter nutzbar (teilweise)

[daabm 1.344]

Der Domänenadmin sollte meine ich nach Möglichkeit fast alles können.

 

Irrtum. Der soll die Domäne (= das AD) administrieren können. Sonst gar nix. Vor allem hat er auf Membern (Server und Workstations) nix verloren - such mal ein wenig nach "Pass the hash", in Verbindung mit Cached Credentials ist das eine ernst zu nehmende Bedrohung!

 

Deswegen sollte der Zugang dazu möglichst nur mir bekannt sein.

 

Irrtum. Was ist, wenn Dir was passiert? Liegt irgendwo in einem Tresor ein Umschlag mit User und Kennwort? Oder gibt es zwei vertrauenswürdige Instanzen, die jeweils die Hälfte davon kennen? Wenn Du beides mit "Nein" beantwortest, sitzt Deine Firma auf einer tickenden Zeitbombe. BTW: Die Formulierung klingt für mich ein wenig nach "Security by obscurity" :)

 

wenn sie ihr lokales Konto, das ggf. noch Vollzugriff auf eine SQL-Datenbank hat, nicht mehr nutzen könnten.

Irrtum. In einem gut verwalteten AD gibt es außer "Guest" und "Administrator" keine lokalen Konten. Und ein SQL-Server nutzt niemals nur die SQL-Authentifizierung (idealerweise nutzt er sie gar nicht). Das ist zwar möglicherweise die Schuld der Dienstleister, aber Ihr habt es ihnen ermöglicht.

[willy-goergen 0]

Irrtum... Irrtum...  Irrtum.

 

Mein Kennwort liegt an bekannten Stellen aus. Die Frage ist, wie deutlich ich diese Stellen machen sollte. Ich habe an mehreren Stellen den Vorschlag gemacht, dass Sie jeweils ein Teil des Zugriffs kennen sollten und im Notfall kombinieren könnten. Mir wurde gesagt, ich sollte alles so lassen, wie es ist. Die halbe Firma nutzte den alten Domänenadmin quasi nach Bedarf.

 

Zuletzt habe ich mir den alleinigen Zugriff vorbehalten. In so einem Fall lässt sich wenigstens nachvollziehen, wer was gemacht hat. 

 

Ich bin sehr offen für  noch mehr Gründe, warum mein Engagement an meinem jetzigen AP total fehl am Platz ist.

 

Du schneidest für mich gerade ein ziemliches Reizthema an...

bearbeitet 9. Juni 2015 von willy-goergen

[NorbertFe 2.027]

Naja wenns danach geht, scheint für dich so ziemlich jedes Thema, welches hier in deinen Threads angesprochen wird, ein Reizthema zu sein. ;) Ich müßte mal zählen aber deine Threads fangen entweder an mit "ich könnt grad bröckeln" oder hören auf mit "Reizthema". ;)

 

Bye

Norbert

[Daniel -MSFT- 129]

Ich persönlich würde gerade eher den umgekehrten Weg bevorzugen. Bzw. habe ich ihn im Moment ein Stück weit eingeschlagen.

 

Lies meinen Satz nochmal genau. Ich hatte ein "nicht" gezielt eingestreut.

[daabm 1.344]

Ich habe an mehreren Stellen den Vorschlag gemacht, dass Sie jeweils ein Teil des Zugriffs kennen sollten und im Notfall kombinieren könnten. Mir wurde gesagt, ich sollte alles so lassen, wie es ist. Die halbe Firma nutzte den alten Domänenadmin quasi nach Bedarf.

 

 

Du läßt "wünsch Dir was" mit Dir spielen. Das funktioniert nicht - zumindest nicht bei Euch, da Ihr offensichtlich keinen Security-Beauftragten und vermutlich auch keine interne Revision habt. In dem Fall heißt es dann nämlich "So isses"... Soll heißen: Entweder Du hast die Cojones und stellst die Fakten klar. Oder halt nicht.

 

Voraussetzung dafür ist natürlich, daß Du einen klaren Plan und eine strukturierte Administrationsweise hast. Also zurück zum Thema - such nach "Pass the hash" in Verbindung mit Cached Credentials. Domain Admins melden sich auf Domain Controllern an, sonst nirgends. Server-Admins melden sich auf Member Servern an, sonst nirgends. Client Admins melden sich auf Clients an, sonst nirgends.

 

Und als Info aus der Praxis: Auf allen unseren Servern gibt es keine lokalen Benutzer (jepp - nirgends). Domain Admins können sich nur auf Servern anmelden, nicht auf Clients ("nur auf DCs" kommt demnächst). Für alle Serverfunktionen gibt es entsprechende Domänengruppen, die auf dieser Serverfunktion lokaler Admin sind. Für Clients ebenso. Nicht-"Server-Admins" können sich an Servern nicht anmelden (Ausnahme natürlich RDS). Auf Servern ist Cached Credentials = 0, auf Clients (wegen Offline-Anmeldung) = 1.

 

Ich bin sehr offen für  noch mehr Gründe, warum mein Engagement an meinem jetzigen AP total fehl am Platz ist.

 

 

Für Dich kann ich nicht sprechen. Ich hab vor 20 Jahren mein Hobby zum Beruf gemacht und es nie bereut. Engagement war dabei nie fehl am Platz und hat sich langfristig immer ausgezahlt. Du solltest darüber vielleicht noch mal nachdenken...

 

Du schneidest für mich gerade ein ziemliches Reizthema an...

 

Siehe Norbert :( Viele Anteile Deiner Beiträge gehören eigentlich ins OT.

[willy-goergen 0]

Danke für eure Hilfe. Da war ja wieder jede Menge dabei zu dem (für mich) nicht ganz einfachen Thema und einiges, was ich jetzt zu bearbeiten habe.  :)

Ansonsten probiere ich jetzt gleich mal den OT-Anteil zu reduzieren. Ich hoffe, es nimmt mir keiner übel, wenn ich auf bestimmte Sachen/Beiträge dann nicht eingehe.

 

EDIT:

Ich habe gerade ein Problem damit den neuen Domänenadministrator so einzuschränken, dass er sich nur an Domain Controllern anmelden kann. Mein Gedanke war, das direkt im Nutzerkonto mit "Anmelden an..:" zu machen.

 

Wenn ich mich jetzt per Remotedesktop mit dem Administratorkonto an einem der dort eingetragenen Rechner anmelden will, bekomme ich diese Fehlermeldung:

 

 

 

Das Kennwort ist definitiv nicht abgelaufen. Die Anmeldung direkt am Server funktioniert einwandfrei. An dem Fehler hänge ich mittlerweile schon länger. Bisher habe ich die Sache umgangen, indem ich die Anmeldebeschränkungen in der AD Benutzerverwaltung wieder aufgehoben habe. Dann klappt auch die RDP-Anmeldung wieder.

 

EDIT²:

Ein kleines Stück bin ich weiter gekommen. Keine Lösung ist das aber auch nicht. Ich hatte an sämtlichen Servern für RDP "Authentifizierung auf Netzwerkebene" aktiviert.

 

 

 

Wenn ich beliebige Versionen von Remotedesktop zulasse, klappt die Anmeldung mit dem eingeschränkten Admin zumindest, gefolgt von einem Zertifikatfehler.

 

EDIT³:

Zwischenzeitlich hab ich mir das mit den Cached Credientials angesehen und entsprechend konfiguriert. Das ist aus der Welt und funktioniert wie es soll.

Allerdings hat das das Problem mit RDP nicht gelöst. Ich habe mit tsconfig.msc auf einem DC mal ein bisschen mit der Konfiguration gespielt. Wenn ich dort die Sicherheitsstufe auf RDP stelle, klappt die Verbindung mit dem eingeschränkten Konto auch.

 

 

 

Sobald ich aber auf TLS-Verschlüsselung mit Authentifizierung auf Netzwerkebene wechsle, ist der Ofen aus.

Irgendwo seh ich bei der Sache gerade nicht mehr durch. Warum fängt RDP das Spinnen an, wenn ich im Benutzerprofil die Anmeldung auf bestimmte Rechner in der Domäne einschränke?

bearbeitet 9. Juni 2015 von willy-goergen

[daabm 1.344]

Die NLA von RDP authentifiziert Dich nicht erst "auf dem Zielcomputer", sondern schon auf dem TS-Client. Das geht also mit "Anmelden an" nicht. Was Du suchst, sind Sicherheiteinstellungen - Zuweisen von Benutzerrechten: "Lokal anmelden zulassen" und "Lokal anmelden verweigern".

[NorbertFe 2.027]

Wie war das mit dem externen Berater? ;) läuft schon wieder auf "Aktionismus" hinaus.

[willy-goergen 0]

Danke für die Hilfe, das hat super geklappt! :)

 

@Norbert: Den hatte ich irgendwie verdrängt... Weil du das jetzt erwähnt hast, dachte ich gerade, ich befrage spaßeshalber mal meinen externen Berater/Urlaubsvertretung zu dem Thema. Er meinte, sowas sei wohl nicht möglich. Man könne dem Domänenadmin nicht die Anmeldung an Workstations/Memberservern sperren.

 

Das war jetzt denke ich der leichtere Teil. Den schwierigeren Teil, die Festlegung diverser Gruppen im AD, nach Möglichkeit so, dass ich mich später nicht über mich selbst ärgern muss, hab ich jetzt noch vor mir. 

bearbeitet 10. Juni 2015 von willy-goergen

[NorbertFe 2.027]

Konzept ungleich Aktionismus

[willy-goergen 0]

Ich weiß... du hast mal wieder recht. 

 

Für die weiteren Arbeiten am neuen Berechtigungskonzept will ich mich erst mal weiter informieren, bzw. drüber nachdenken.

Habt ihr eventuell eine Buchempfehlung für so etwas? Etwas mit möglichst vielen Fallbeispielen.

 

EDIT: Ich schieb nochmal was nach zu der Buchempfehlung. Optimal wäre, wenn das Buch gut verständlich wäre und praxisnah gehalten ist. Wenn es etwas schwerer zu verstehen ist und viele Beispiele enthalten wären, die zeigen, wie man es machen kann und wie man es lieber nicht machen sollte, wäre das auch ok. Es muss in dem Buch auch nicht nur um die Erstellung von Berechtigungskonzepten für Active Directory gehen.

 

Wenn sich die Empfehlung, sollte ich sie wählen, für mich im Nachhinein als schlecht herausstellt, ist das kein Problem.

bearbeitet 10. Juni 2015 von willy-goergen

[daabm 1.344]

Man könne dem Domänenadmin nicht die Anmeldung an Workstations/Memberservern sperren.

 

Doch,  kann man. Er kann es allerdings rückgängig machen - dafür ist er ja Domänen-Admin. Ein Admin kann sich immer über alle Restriktionen hinwegsetzen. Er muß aber wissen, wie es geht. Und wenn Deine Domain Controller physisch gesichert sind, wird es schwieriger :D

[willy-goergen 0]

Ich betrachte das Thema mal als umfassend gelöst...

Falls jemand noch einen guten Literaturtipp hat, würde ich mich freuen.  :)

 

Vielen Dank euch allen für die guten Antworten!

bearbeitet 10. Juni 2015 von willy-goergen