Attack44

Hallo,

was meinst Du genau mit "authoritativen Nameserver der jeweiligen Zonen"?

Die Server fragen aktuell verschiedene öffentliche DNS Server ab um externe Dienste aufzulösen zu können, vorher hat es ja gereicht das nur die quad9 Server abgefragt werden um externe Dinge aufzulösen.

Hallo,

ich habe seit kurzem das Phänomen/Problem , dass zwei unserer DCs externe DNS Abfragen oft an nicht definierte externe DNS Server stellen.

Wir haben bei uns in den DNS Servereinstellungen unter Weiterleitungen zwei DNS Server von quad9 hinterlegt die abgefragt werden sollen, alternativ werden dann die Stammhinweise verwendet.

Unsere Firewall ist auch so eingestellt, dass externe DNS Abfragen von den DCs nur an die Server von quad9 und an die Stammserver gehen können, Abfragen an andere externe DNS Server werden blockiert.

Aufgefallen ist das Problem, dass verschiedene Webseiten nicht aufgelöst werden konnten, durch einen Trace in unserer Firewall konnte ich dann sehen, dass die DCs DNS Abfragen an Server stellen die nicht in der Liste vorhanden sind.

Die Server von quad9 werden auch ab und zu und abgefragt aber Großteil geht an "unbekannte" DNS Server...da frage ich mich, woher die DCs die IPs her haben und warum die das machen?

Kann sich einer das Problem erklären? 

Vielen Dank.

Gruß

Andreas

Wir haben von unserer CheckMK Instanz ein Update durchgeführt, daraufhin wurden auch die Agenten neu erstellst.

Und die Installation der neuen Agenten funktioniert über den WPP nun ohne Probleme. :)

Gruß

Andreas

vor 4 Minuten schrieb NorbertFe:

Paar mehr Infos wären schon notwendig. Welche Exchange Version, wieviele Server usw.

Da hast Du vollkommen recht, habe ich ganz vergessen.😅🙈

Es handelt sich hierbei um einen einfachen Exchange 2013 auf einem Windows Server 2012R2.

Hallo,

mir ist letztens in dem Verbindungsstatus von Outlook aufgefallen, dass sich unser Outlook über eine alte URL mit unserem Exchange Server verbindet. Ich habe nur leider keine Ahnung woher Outlook diese Konfiguration dafür hat.

Im Exchange selber bin ich bisher nicht fündig geworden. Über das ExchangeHostNames Skript habe ich auch nicht auffälligs rausfinden können. Hat jemand eine Idee wo ich suchen kann, um diese URL zu ändern?

Gruß

Andreas

Wir verteilen über den WPP verschiedenste Anwendungen, das funktioniert auch alles ohne Probleme, nur der CheckMK Agent macht hier Probleme.

Die Installation schlägt mit "0x80070667" fehl, wenn ich den Agent direkt über die CMD installiere, verläuft die Installation ohne Probleme.

Gruß

Andreas

Hallo,

wir verwenden bei uns den WSUS Package Publisher, darüber möchten wir auch unseren CheckMK Agent verteilen und eigentlich ist das ja kein Problem.

Beim CheckMK Agenten müssen einige Befehlszeilenoptionen für die Installation mitgegeben werden, was beim WPP auch möglich ist, wir müssen aber auch vor dem msi Paket das /i mitgeben was im WPP nicht möglich ist. Hat jemand einen Vorschlag wie man das Problem lösen könnte?

Gruß

Andreas

msiexec /i check_mk_agent.msi /qn

vor 44 Minuten schrieb MurdocX:

Hallo Attack44,

 

Der WSUS verteilt keine Updates, sondern stellt sie nur bereit.

 

Die gibt es. Sie heißt Gruppenrichtlinien. Erstelle einfach eine Gruppenrichtlinie zur Updateinstallation am Wochenende und das Thema ist erledigt.

Verwalten zusätzlicher Windows Update-Einstellungen - Windows Deployment | Microsoft Docs

 

Updates an einem Wochenende auf kritischen Systemen zu installieren wo nicht immer wer sofort greifbar ist halte ich nicht für nicht sinnvoll, zudem auch viele Terminalserver betroffen sind und manche Server in einer bestimmten Reihenfolge neugestartet werden müssen bzw. muss bei manchen Servern nach einem Neustart Nacharbeiten durchgeführt werden damit alles wieder ordnungsgemäß läuft.

Dann bleibt entweder die Variante das mit einem Skript zu lösen oder das was @Sunny61 schreibt, ich muss mir mal noch ein paar Gedanken machen.

Hallo,

ich bin schon länger auf der Suche nach einem Tool/Anwendung/Lösung wo man die Installation von Windows Updates zentral anstoßen und überwachen kann. Wir verteilen bei uns die Windows und Software Updates über unseren WSUS-Server bzw. mit dem Wsus Package Publisher, was im Grunde auch wunderbar funktioniert. Wir haben bei uns Updatezeitfenster wo wir die Updates auf den Servern einspielen können, die Server dann neustarten und ggf. nochmal nach Updates suchen.

Und da war aber aktuell um die 100 Server/VMs in Betrieb haben ist diese ganze Prozedur am Server anmelden, "Jetzt installieren" anklicken, warten das die Installation fertig ist, "Jetzt neustarten" anklicken etwas mühselig. Und deswegen bin ich auf der Suche nach einer komfortablen Lösung die auch gerne etwas kosten kann...nur nicht zu viel. :) Hätte da jemand einen Tipp? Vielen Dank.

Gruß

Andreas

vor 7 Minuten schrieb Gulp:

Bitlocker Feature ist aber installiert?

 

Ich kenne sowas ähnliches nur wenn man in den Windows Einstellunge sucht, und "Bitlocker verwalten" zwar vorgeschlagen, aber eben nicht ausgeführt wird und man halt das Feature nicht installiert hat. Das ist dann aber auch egal ob das ein DC oder Member Server ist, das schaut dann bei beiden gleich aus ......

 

Grüsse

 

Gulp

Ja, dass Bitlocker Feature ist installiert und über Umwege gelange ich auch manchmal wie gesagt in die BitLocker Verwaltung und kann die Platte verschlüsseln.

In den Default GPOs haben wir auch nicht viel drin stehen/verändert. Die BitLocker Einstellungen sind eine separate GPO, ich wollte nur bestimmte Dinge ausschließen, deshalb habe ich ein normale Member Server in der Domain Controller OU um ausschließen das nicht doch eine andere GPO dazwischen schießt.

Wenn ich auf dem DC gleich nach der Anmeldung in der Windows Suche BitLocker eingebe, komme ich in die BitLocker-Laufwerksverschlüsselung und ich kann daraus das Laufwerk verschlüsseln und das ohne Probleme.

Nur in der Systemsteuerung ist es nicht zu finden und das ist auch genau der Server, der oben die Fehlermeldung ausgespuckt hat.

Gruß,

Andreas

vor 6 Minuten schrieb Gulp:

Was zunächst recht klar darauf hindeutet, dass da eine Richtlinie für DC aktiv wird, die die hardwarebasierte Verschlüsselung für Bitlocker vorraussetzt .......

 

Gleiche GPO geht ja nicht, da DC's immer per Default eine eigene GPO haben, die normale Server eben nicht haben:

Default Domain Controllers Policy

 

 

Grüsse

 

Gulp

Richtig, ich habe besagtem Server aber auch die Default Domain Controllers Policy zugewiesen, auch wenn er kein DC ist. Er ist ja wie gesagt in der gleichen OU wie die restlichen DC und bei den GPOs existiert auch keine sonstige Filterung. Der Server Verarbeitung die gleichen GPOs wie auch die aktiven DC.

Gruß,

Andreas

vor 3 Minuten schrieb Gulp:

Hardwarebasierte Verschlüsselung ist ein Feature eines physikalischen Datenträgers (meist werden die mit dem Zusatz SED - Self Encyrpting Device gekennzeichnet), wenn das der Datenträger nicht unterstützt, aber bei der Bitlocker Konfiguration als Vorraussetzung angegeben wird, ist klar warum es nicht will ........ Bitlocker ist eben eine Verschlüsselung auf Softwarebasis, kann aber durchaus auch SED Hardware verwenden.

 

Grüsse

 

Gulp

Es ist schon richtig was Du sagst, wenn ich aber den Domain Controller der die oben zitierte Meldung ausgibt wieder runterstufe funktioniert die Bitlocker-Verschlüsselung wieder (gleiche OU, GPOs und BitLocker-Einstellungen). Und das kann ich mir nicht erklären.

Gruß,

Andreas

Ich habe jetzt z.B. alle BitLocker GPO-Einstellungen die wir hatten auf Nicht konfiguriert zurückgesetzt, leider hat sich an dem Problem nichts geändert, normale Member können BitLocker nutzen und DC/RODC können dies nicht. Es handelt sich hierbei um physische DC mit aktiven TPM-Chip, die TPM-Verwaltung in Windows sagt mir auch, dass TPM einsatzbereit wäre.

Wenn ich BitLocker über die PowerShell aktivieren möchte, erscheint folgende Meldung:

Set-BitLockerVolumeInternal : Das angegebene Laufwerk unterstützt keine hardwarebasierte Verschlüsselung. (Ausnahme von HRESULT: 0x803100B2)

Gruß,

Andreas

Wir haben denke ich eigentlich nicht sonderlich spezielle BitLocker Einstellungen außer das der Wiederherstellungs-Key im AD abgespeichert wird, anbei mal ein Auszug aus den GPO Einstellungen.

Was mich wie gesagt wundert ist, dass wenn ich einen Server habe, dieser nur normaler AD Member ist, aber sich auch in der gleichen OU wie die Domain Controller befindet und genau dieselben GPOs anwendet wie die aktuellen Domain Controller, kann ich BitLocker auf diesen Server nutzen. Stufe ich diesen Server nun hoch, ist BitLocker nicht mehr möglich.

P.S. Nachdem ich den Server hochgestuft hatte und gleich nach der Anmeldung in der Windows Suche BitLocker eingegeben habe, hat er mir noch die BitLocker-Laufwerkverschlüsselung angezeigt, dieser Link hat auch noch funktioniert und ich könnte da theoretisch BitLocker starten. Als angepinntes Fenster komme ich dort noch rein, aber in der Systemsteuerung ist es nicht mehr sichtbar und über die Suche wird mir nur noch BitLocker Verwalten angezeigt, was beim Anklicken nicht reagiert.

Gruß,

Andreas

Ein Einzelfall ist es bei uns leider nicht, es sind alle Domain Controller betroffen, auch neue die wir hinzufügen.

Ich werde mir den Link genauer anschauen und weiter forschen. :)

Gruß,

Andreas

Hallo,

ist es möglich auf einem Windows Server 2016 der ein Domain Controller / RODC ist BitLocker zu aktivieren?

Wir haben hier aktuell das Phänomen, dass auf DC/RODC kein BitLocker funktioniert, in der Systemsteuerung ist der Menüpunkt nicht mehr sichtbar und in der Windows Suche passiert beim Anklicken der BitLocker Verschlüsselung auch nichts mehr.

Bevor der Server hochgestuft wurde, war eine Bitlocker Verschlüsselung möglich. Zum Test hatten wir einen normalen Member Server in die Domain Controller OU verschoben, damit dieser die gleichen GPOs verarbeitet um zu prüfen ob es evtl. an einer GPO liegen könnte, das war leider nicht der Fall.

Selbst bei einem Server wo die Platten mit BitLocker schon verschlüsselt waren, war nach der hochstufung auf einen RODC die BitLocker Verschlüsselung wieder deaktiviert. Ist das von MS nicht gewollt, dass DC/RODC BitLocker nutzen, ich habe dazu bisher nichts gefunden?

Gruß

Hallo,

Danke für die Hilfestellung, werde ich mal demnächst angehen.

Als quick and dirty Variante habe ich in der GPO vorrübergehend die Remoteshell immer wieder aktiviert. :)

Gruß

Andreas

Hallo,

bei uns ist aus Sicherheitsgründen die Remote Shell deaktiviert, das hat aber zur Folge, dass man u.a. am lokalen Server im Server-Manager keine Rollen installieren/deinstallieren kann.

Gibt es eine Möglichkeit, so dass im Server-Manager den lokalen Server noch immer vollständig verwalten kann, auch wenn die Remote Shell dafür deaktiviert ist oder muss dafür die GPO ein wenig angepasst werden, damit die Remote Shell "lokal" wieder funktioniert?

Gruß

Andreas

vor 14 Stunden schrieb NorbertFe:

Auf nem "normalen" 2016 ist ja die verstärkte Sicherheit für den IE standardmässig aktiv. Vielleicht liegts daran.

Daran habe ich gar nicht mehr gedacht, dass es diese Option gibt, nachdem ich sie ausgestellt habe, hat die Anmeldung über WIA funktioniert. Vielen Dank. :)

Gruß

Andreas

//abgetrennt von: https://www.mcseboard.de/topic/218984-ad-fs-windows-integrierte-authentifizierung/

Ich muss den Thread hier nochmal ausgraben, bisher läuft das ADFS - WIA ohne Probleme und tut seinen Dienst zuverlässig.

Bisher nutzen wir die WIA auf Windows 10 Clients und 2k16 Terminalservern, nun ist uns aber aufgefallen, dass die WIA nicht richtig auf "normalen" 2k16 Servern funktioniert, es erscheint immer eine Passwortabfrage.

Bei der Untersuchung woran es evtl. liegen könnte ob vielleicht eine GPO fehlt, ist uns aufgefallen, dass in den Internetoptionen -> Sicherheit -> Lokales Intranet -> Sites nichts angezeigt wird, obwohl die GPO angewendet wird.

In der Registry sind aber alle Seiten richtig eingetragen/gesetzt "nur" über die Oberfläche ist nichts zu sehen. Bei den Windows 10 Clients und den Terminalservern ist hingegen in der Liste etwas eingetragen. Aufgefallen ist uns auch, das wo die Liste leer ist, auch ein Optionsmenü nicht mehr angezeigt wird. Hat zufällig jemand einen Tipp woran das Problem liegen könnte?

Liste Leer und Optionsmenü fehlt

(Lokales Intranet -> Sites -> Erweiter -> Liste)

Über Sites kommt das Optionsmenü und in der Liste ist etwas eingetragen.
(Lokales Intranet -> Sites -> Erweiter -> Liste)

Gruß

Andreas

Ich konnte das Problem jetzt lösen, ich haben den AD FS Server nochmal neu aufgesetzt, dieses mal ein Managed Service Account verwendet und der Farm einen eigenen Namen gegeben und dafür ein Zertifikat gebaut im Anschluss habe ich die User-Agents angepasst und siehe da es funktioniert. Als Vorlage zur Installation/Konfiguration habe diese Anleitung genutzt.

Andreas

Die Testumgebung ist für neue Dinge da die wir schnell/grob ausprobieren möchten bzw. für Dinge mit denen wir noch nicht so viele Berührungspunkte hatten. Die meisten GPOs sind von der produktiven Domain übernommen worden, so dass wir ungefähr die gleiche Ausgangslage haben.

Ich bin jetzt einen Schritt weitergekommen, im AuthnContext war ein "Fehler" drin was ich erst jetzt gesehen habe, dort war als Authentifizierungsmethode eingestellt, dass man sich nur mit Passwort anmelden darf. Zum AuthnContext habe ich nun WIA hinzugefügt, worauf im SRVZENTADFS im Log keine Fehler mehr auftauchen.

<samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="__authnContextComparison__">
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    urn:federation:authentication:windows
  </saml:AuthnContextClassRef>
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

Nur ist das Problem damit nicht ganz gelöst, wenn er jetzt versucht sich über die WIA zu authentifizieren, erhalte ich in jedem Browser ein Login Promt und fordert einem zum Anmelden auf.

Ich habe mir die Internetzonen nochmal angeschaut und keine Fehler gefunden bzw. ich habe auch zum Test in den anderen Zonen (Internet, Lokales Intranet und Vertrauenswürdige Sites) eingestellt, dass er sich automatisch mit aktuellem Benutzernamen und Passwort anmelden soll.

AuthnRequest Template

Hier mal ein Auszug vom AuthnRequest, ob Du da vielleicht etwas siehst was angepasst werden könnte? Ich weiß aktuell nicht genau wo der Fehler herkommt, ob es am ADFS/GPO liegt oder an der Webanwendung, die den Request schickt. Weil hier hat jemand das Problem gelöst bekommen, nur leider funktioniert das bei mir nicht, ist ja auch schon ein paar Tage alt.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="__newId__" Version="2.0" IssueInstant="__instant__" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="__callbackUrl__" Destination="__entryPoint__">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">__issuer__</saml:Issuer>
  __identifierFormatTag__
  __authnContextTag__
</samlp:AuthnRequest>

__newId__: Randomly generated id string

__instant__: Current timestamp

__callbackUrl__: The Rocket.Chat callback URL.

__entryPoint__: The value of the Custom Entry Point setting.

__issuer__: The value of the Custom Issuer setting.

__identifierFormatTag__: The contents of the NameID Policy Template if a valid Identifier Format is configured.

__identifierFormat__: The value of the Identifier Format setting.

__authnContextTag__: The contents of the AuthnContext Template if a valid Custom Authn Context is configured.

__authnContextComparison__: The value of the Authn Context Comparison setting.

__authnContext__: The value of the Custom Authn Context setting.

vor 56 Minuten schrieb NorbertFe:

OK, wie lautet der Zugriffsname? DC0 wirds ja eher nicht mehr sein. Welchen SPN hast du gesetzt? Unter welchem Konto führst die Services aus?

Teste erstmal immer mit dem IE nachdem du den Zugriffsnamen in die lokale Intranetzone aufgenommen hast. Ansonsten was steht in den Ereignisprotokollen des ADFS Servers?

 

Der Server heißt srvzentadfs.domain.local, so sehen dazu die SPN's aus:

 HTTP/SRVZENTADFS
 HTTP/SRVZENTADFS.domain.local/domain.local
 HTTP/SRVZENTADFS.domain.local

Die Internetoptionen habe ich entsprechend angepasst, getestet habe ich es mit dem IE, Firefox, Chrome und Edge. Die UserAgents habe ich von oben übernommen. Der Dienst wird in der Testumgebung als Domain Admin ausgeführt.

P.S. Bei ADFS 4.0 kann man nichts über die IIS einstellen/anpassen?

Guten Morgen,

ich habe jetzt auf einem separaten Server den AD FS laufen, alles so konfiguriert bzw. entsprechenden dem Namen anpasst wie es schon beim alten Server war.

Aktuell hat sich das Fehlerbild nicht verändert.