olc

Hi, standardmäßig wurde auch unter Windows Server 2003 und davor die Reverse Lookup Zone nicht automatisch eingerichtet. Es gibt diesbezüglich bei Windows Server 2008 keine Änderung. Wenn die Reverse Lookup Zone zwingend notwendig wäre, würde sie auch automatisch eingerichtet. ;) Soll heißen: Sicherlich ist Best Practice auch Reverse Lookup Zonen einzurichten. Jedoch sind diese nicht zwingend erforderlich. Das ist das, was Norbert schon sagte. Viele Grüße olc

Hi, wie firefox80 schon sagte, bringt wahrscheinlich jede (bessere) Proxy Lösung solche Filter mit. So auch IPCop + Advanced Proxy. Viele Grüße olc

Hi, schau einmal hier hinein: Appendix B: Windows Behavior Viele Grüße olc

Hier geht es weiter (bzw. war es vorher) ;) : https://www.mcseboard.de/windows-forum-allgemein-28/event-id-3-kerberos-fehler-136404.html Viele Grüße olc

...oder: ShellRunas Viele Grüße olc

Hi, wie die Kollegen schon sagten, gibt es da eine Menge. So auch Download SYDI . Viele Grüße olc

Hallo Pete, ganz so einfach ist es dann doch nicht, daher mein Hinweis auf ein Systemhaus Deiner Wahl. ;) Du kannst die Systeme in der DMZ nicht so einfach gegen die ADAM / AD LDS Instanz authentifizieren - das muß ggf. eine LDAP Applikation erledigen. Deshalb schrieb ich auch, daß Du ggf. einen FTP Server verwenden solltest, der die Berechtigungen und Zugriffe regelt. Ob Du die Authentifizierung dann (nach Anbindung der Applikation) mittels Proxy-Objekt erledigst, ist eine Abwägungsfrage - schließlich öffnest Du damit eine direkte Tür in Dein internes Netzwerk (zu den DCs). Natürlich ist das auch bei einer Synchronisierung der Fall - jedoch kann man dies recht starkk einschränken, was die Zeit etc. betrifft. Ob das tatsächlich ein Sicherheitsgewinn ist, darüber läßt sich sicherlich streiten... ;) Viele Grüße olc

Hi Firefox, vielleicht kannst Du das hier als Grundlage verwenden: $category = "(&(objectclass=computer)(objectcategory=computer))" $AD = [ADSI]"LDAP://OU=DEINE_OU,DC=DOMAIN,DC=TLD" $properties = "samaccountname", "dn" $search = New-Object System.DirectoryServices.DirectorySearcher($AD,$category) $search.PageSize = 1000 foreach ($value in $properties) { $search.PropertiesToLoad.Add($value) } $result = $search.Findall() Danach kannst Du die Ergebnisliste entsprechend weiter verarbeiten. Ansonsten die Quest PowerShell Addons nutzen - dort kannst Du die OUs recht einfach auslesen (Get-QADComputer). Viele Grüße olc

Hallo Mike, danke für Deine Rückmeldung. :) Daß der zweite Administrator die Daten öffnen / neue zugriffsberechtige Benutzer hinzufügen konnte hat nichts mit seinen administrativen Rechten zu tun. Genau das ist der Sinn der Verschlüsselung - es müssen explizit Benutzer angegeben werden. Da helfen auch Administrator-Rechte nichts. Deshalb gibt es den Data Recovery Agent. D.h. in Deinem Szenario: Der Administrator2 muß das DRA Zertifikat und den dazugehörigen privaten Schlüssel im lokalen Zertifikatspeicher haben oder er muß die entsprechenden Rechte auf die Datei schon gehabt haben (z.B. vom verschlüsselden Benutzer zugewiesen. Viele Grüße olc

Hi Norbert, soweit ich weiß nutzt Cirtix (und andere Systeme) auch einen eigenen Client, der dann eine verschlüsselte Verbindung zum Terminalserver aufbaut. Es handelt sich also hierbei auch um ein VPN. Viele Grüße olc

Hi, im Grunde gibt es für solche Szenarien drei Möglichkeiten (neben anderen, jedoch werden die folgenden drei wahrscheinlich am häufigsten eingesetzt): 1. Im Normalfall ist es z.B. bei Exchange / OWA nicht (mehr) empfohlen, die Systeme in die DMZ zu stellen, sondern ins interne oder ein "Dienste"-Netz. Ich weiß nicht, inwieweit sich das mit Exchange 2007 geändert hat, da hier ja mehr Exchange Rollen existieren als nur Front-End und Back-End. Bei Applikationsservern wird oftmals versucht, die "ausliefernden Systeme" in eine DMZ zu stellen (z.B. Webserver, siehe oben), die Datenbank jedoch ins interne Netz bzw. besser in ein "Dienste"-Netz. 2. Wie Norbert schon sagte, bietet der ISA Server z.B. einige Varianten, ein solches Szenario zu ermöglichen. Daher auch mein Hinweis oben. Schau einmal in das folgende Whitepaper, da wird das Thema SharePoint in DMZ plus ISA besprochen: Download details: SharePoint Portal Server 2003 Document: Deploying on an Extranet by Using ISA Server 2000 and ISA Server 2004 3. Terminalservices sind auch eine Variante, jedoch wird hier meist vorher eine VPN-"Einwahl" in das (DMZ-) Netz genutzt, so daß sich das Szenario ein wenig verändert. Viele Grüße olc

Hey Mike, danke für Deine Rückmeldung. Zwar hat Deine letzte Meldung m.E. nichts mit dem Problem Deines letzten Postings zu tun (oder habe ich da etwas falsch verstanden?), aber es ist schön zu hören, daß es nun wie gewünscht funktioniert. ;) Viele Grüße olc

Hi Pete, das haben wir nicht nur "zwichen den Zeilen" geschrieben, sondern ganz klar und deutlich gesagt. ;) Der Webserver gehört in die DMZ, der SQL-Server kann durchaus im geschützten Netzwerk stehen. Soweit ich weiß, setzen viele größere Instalklationen eine solche Konfiguration ein. Das Aktualisieren der Daten muß nicht über Shares mit AD-Anbindung erfolgen. FTP kann hier eine Alternative sein - jedoch ist ohne Anbindung an die AD eine eigene Benutzerverwaltung angesagt. Theoretisch wäre es möglich, in die DMZ z.B. eine ADAM Installation zu packen, die die LDAP Daten der entsprechenden Benutzer aus der AD zieht. Hierfür muß "nur" LDAP Traffic in die DMZ gestattet sein. Die Benutzerauthentifizierung könnte dann gegen das LDAP Verzeichnis gehen. Die Benutzerdaten liegen dann jedoch ebenfalls in der DMZ, was auch wieder nicht gewünscht ist. Hier könnte man jedoch mittels ISA o.ä. über Proxy-Objekte in der ADAM Instanz etwas Sicherheit schaffen. Ein IT-Systemhaus in Deiner Umgebung kann Dir hier vielleicht weiterhelfen und ein Projekt dafür ausarbeiten. Viele Grüße olc

Hi Death, über die Replikation hatten wir doch aber gesprochen oder? ;) Funktioniert hierbei etwas nicht richtig, wird das auch in den Eventlogs der DCs geloggt - das hätte auffallen können / müssen, zumal wir darüber gesprochen haben... ;) Da Du den DC erneut promoten wirst, ist die Meldung zumindest grundsätzlich kein Stolperstein. Zwei Dinge sind dabei jedoch trotzdem relevant: Wenn Du einen RPC Fehler bekommst, kann entweder mit dem DNS oder aber mit der Netzwerkverbindung immer noch etwas nicht stimmen. Das solltest Du prüfen, bevor Du weiter machst. Da die RODCs scheinbar (Deinen Aussagen zur Folge) auch erst recht spät von den Änderungen "erfahren", sind hier unter Umständen auch Replikationsprobleme vorhanden. Bevor Du den DC neu promotest, solltest Du auch hier noch einmal prüfen, ob es hier Änderungsbedarf gibt. Viele Grüße olc

Hi, versuche es einmal mit "NET USE X: /DELETE", wobei "X:" durch das entsprechende Laufwerk zu ersetzen ist. Funktioniert ein erneutes Mapping danach ohne Probleme? Viele Grüße olc

Hi Gunnar, liest sich so, als ob Du das alte DRA Zertifikat zusätzlich zum alten Zertifikat in der GPO behalten hättest. Das solltest Du ändern ;) - solange das abgelaufene DRA Zertifikat in der GPO hängt, wirst Du nicht verschlüsseln können. Das abgelaufene Zertifikat im Userstore des Administrators auf dem DC inkl. des privaten Schlüssels solltest Du sichern, sollte das noch nicht passiert sein. Viele Grüße olc

Hi, nutzt Du eine Domäne? Falls nicht liegen die Dateien auf der Freigabe unverschlüsselt. D.h. beim Kopieren auf das Netzlaufwerk werden sie entschlüsselt. Hintergrund dafür ist, daß der Server mit dem Recht "Trusted for Delegation" ausgestattet sein muß, damit der Benutzer vom Server "impersoniert" werden kann (sorry für den eingedeutschten Ausdruck, mir fällt gerade nichts besseres ein), siehe: Bedeutet (einfach ausgedrückt), daß der Server stellvertretend, also im Namen des Benutzers, die Dateien verschlüsseln kann. Dafür brauchst Du eine Domänenumgebung und die entsprechende Option auf dem Serverobjekt. Viele Grüße olc

Hallo, ich gehe jetzt mal nicht auf alle Punkte ein, weil eine Ursachenanalyse an dieser Stelle (und vor allem: mit den vorhandenen Daten) wahrscheinlich eher schwierig ist. Du hast meines Erachtens im Moment drei Möglichkeiten, das Problem zu lösen: Den DC SERVICE1 neu promoten ("schnell und schmutzig Variante"). Du könntest die DFSR Objekte aus einem Backup autorativ wiederherstellen (würde ich auch nicht unbedingt empfehlen, da in der Zwischenzeit schon Änderungen an der Struktur durchgeführt wurden, die damit verloren wären) Das SYSVOL manuell neu auf dem System hosten. Da ich das jedoch bisher noch nicht gemacht habe, habe ich keine Ahnung, ob das funktioniert. :D Ich vermute einmal, Du kannst mittels dfsradmin den Server (ausgeführt auf SERVICE1) aus der Replikationsgruppe entfernen und danach wieder hinzufügen. Da SYSVOL nicht irgend eine Replikationsgruppe ist, wird man dabei jedoch sicherlich einiges zu beachten haben. Ich teste das bei Gelegenheit einmal und melde mich bei Erfolg. Solltest Du es vorher hinbekommen haben, wäre iene Meldung klasse. Viele Grüße olc

Hi, wie B6n schon schrieb, wird im Normalfall kein DC in die DMZ gestellt. Dieses Szenario sollte man sich wirklich sehr genau überlegen... Trotzdem der Hinweis, daß in der geposteten Portliste neben dem "verschobenen" DNS 53/UDP auch weitere dynamische RPC Ports freigegeben werden müssen, solltest Du die RPC Kommunikation nicht auf einen beschränkten Portbereich gebunden haben. Ohne die Portbindung muß der Portbereich 1024 - 65535/TCP ebenfalls freigegeben werden. Ist beispielsweise LDAP/S im Spiel, kommt noch Port 636 dazu. Viele Grüße olc

Hi Gunnar, Was heißt das "Du hast das Zertifikat für den Administrator dort importiert"? Wohin hast Du es importiert? In die Default Domain Policy oder an anderer Stelle? Viele Grüße olc

Hi, die DSTools (dsquery und dsget) sollten auch Ergebnisse liefern, wenn Du sie auf dem 2003er Memberserver ausführst. Z.B.: "dsquery group | dsget group -samid -sid". Ansonsten einmal mit PsGetSID versuchen: PsGetSid Viele Grüße olc

Hallo, die "schmutzige" (aber funktionierende) Lösung kann in solchen Fällen auch sein: Anlegen eines Shares direkt auf dem gewünschten Ordner, in dem die zu kopierenden Dateien liegen und danach ein Mapping der Freigabe (oder Zugriff über UNC). Du kannst die Daten dann problemlos kopieren. Viele Grüße olc

Hallo Mike, das kannst Du beispielsweise, angemeldet als der entsprechende Benutzer, über die Zertifikate MMC erledigen. Du importierst das Zertifikat dann in den "Personal Store" bzw. die "Eigenen Zertifikate". Dazu mußt Du halt als der Benutzer selbst angemeldet sein. Oder - wie oben kurz angesprochen - Du läßt die Benutzer eine beliebige Datei verschlüsseln. Dabei wird automatisch das benötigte Zertifikat erzeugt und Du kannst es danach auf den gewünschten Ordnern oder Dateien zuordnen. Viele Grüße olc

Hallo Mike, Du mußt für die anderen Benutzer ebenfalls Zertifikate erzeugen (solltest Du keine CA am Laufen haben, aber danach klingt es nicht ;) ). Neue Zertifikate kannst Du erzeugen, indem Du "cipher /R:schlüsselname" ausführst. Danach mußt Du das erzeugte Zertifikat dem gewünschten Benutzer zuordnen. Wenn die anderen Benutzer Dateien auf dem System verschlüsseln, wird beim ersten Verschlüsselungsvorgang automatisch ein Zertifikat dafür angelegt. In diesem Fall würde das cipher Kommando und der Zertifikatimport in den Userstore entfallen können. Das folgende HowTo behandelt zwar schwerpunktmäßig die Data Recovery, jedoch findest Du darin sicherlich auch einige Informationen zu Deinen Fragen: Windows Server How-To Guides: EFS Recovery – oder: Vorsorge ist alles - ServerHowTo.de Viele Grüße olc

Hi Johannes, das ist normal - es fehlt das NTDS Settings Objekt, somit ist das System kein DC mehr. Promotest Du diesen DC erneut, wird dieses Objekt wieder genutzt. Möchtest Du es nicht mehr verwenden, kannst Du das Objekt gefahrlos löschen, siehe auch How to remove data in Active Directory after an unsuccessful domain controller demotion (gilt auch bei regulär demoteten DCs). Viele Grüße olc