Christoph35

Ach so, sorry :o mein Artikel war ja nur für den Fall, dass der Fehler nach DC Reboots auftritt. Bei dir ist es wohl was anderes. Muss noch mal forschen ... Christoph

Hi, der Fehler besagt, dass ein Dienst (meist w32time) versucht, sich zu authentifizieren, bevor die AD-Dienste bereit stehen. Kann in der Regel ignoriert werden. Siehe auch: http://support.microsoft.com/kb/823712/ Christoph

Kannst Du mal die genauen Settings der Publishing Rule hier posten? und die Einstellungen des Web-Listeners? Domains kannst Du ja abwandeln. Christoph

Ja, denke schon, wenn sonst keine Berechtigungen für das Konto eingetragen sind. Christoph

Hi, um die oberste Ebene zu finden, von der aus nicht mehr ererbt wird, musst du adsiedit.msc aus den Support-Tools installiert haben. Dann klick Dich durch über Configuration/CN=Configuration.../CN=Services/CN=Microsoft Exchange. Rufe von dem Ordner die Eigenschaften auf, schau dir den Security Tab an und klicke auf Erweitert. Dort wirst Du sehen, dass da für den Exchange Full Admin, mit dem du installiert hast, Exchange Services, Exchange Domain Servers und Authenticated Users keine Ererbung mehr eingetragen ist. Christoph

Soweit ist das alles korrekt. auch noch ok, wenn du mit "die domain" den externen Namen der Website meinst Hier liegt der Fehler, denke ich. Bei MSISAFAQ.DE steht auch nicht, dass du die IP als Ziel eingeben sollst, sondern den FQDN der öffentlich erreichbar ist, und auf den das Zertifikat ausgestellt ist. Folgendes Zitat steht etwa zu Anfang der 2. Hälfte des von Dir verlinkten Artikels: Genauso steht es auch bei Shinder. Du hast in der Hosts Datei auf dem ISA ja die IP für den Web-Server eingetragen, also 10.1.14.6. Dann kannst Du als Ziel im To-Tab auch den FQDN angeben. Jetzt musst Du nur noch schauen, weshalb die Regel nicht greift. Es muss alles passen: quelle: anywhere, ziel: muss der externe fqdn sein (test.blabla.net). Protokoll muss stimmen (HTTPS). User Set muss stimmen (all users). Ich geh jetzt einfach mal davon aus, weil es ja via HTTP geht, dass Netzwerkregeln etc. stimmen. Christoph

... und bei Workstation oder GSX nimmst Du Host Only oder einen Custom Switch (VMNet 2-7 oder 9). Christoph

Ok, ich habe das Buch von Shinder grad vor mir und habe das mal im Abschnitt zum "Secure Web Server Publishing" nachgeschlagen. Ich zitiere mal aus dem Werk, in englisch ... Deshalb habe ich weiter oben in Punkt 4 darauf hingewiesen, dass der Public Name gleich dem Namen sein muss, der beim Beantragen des Zertifikats für die Website verwendet wurde. Also: Zertifikat für http://www.domain.com'>http://www.domain.com beantragt heisst dann, dass als Public Name für die Website ebenfalls http://www.domain.com genutzt werden muss, und dass DNS entsprechend konfiguriert ist. /edit: DNS Thematik: ich habe in meiner Testdomain einen Webserver testsps.ad.testdomain.local, für den ich ein Zertifikat auf den Namen "sps.testdomain.local" beantragt habe. Dieses Zertifikat habe ich exportiert und auf dem ISA importiert und für den Weblistener verwandt. Weiterhin habe ich eine Secure Web Publishing Rule erstellt, in der ich sps.testdomain.local als den Namen eingetragen habe, unter dem der testsps.ad.testdomain.local veröffentlich werden soll. Dann bin ich hingegangen und habe auf dem externen DNS Server (BIND) einen A-record für sps.testdomain.local erstellt, der auf die externe Adresse des ISAs verweist. E voilà, das funktioniert! Das ganze war, wie oben für ein SSL to HTTP Bridging scenario, in dem Client->ISA ssl verschlüsselt ist, und isa->webserver unverschlüsselt, sowie es in Deinem 1. Posting gefordert war. Christoph

Hmm, ich hatte auch nichts gefunden. Meintest du vielleicht die Cached Logons? ;) Christoph

Den Artikel kannte ich noch nicht, danke für den Link. Ich meine ich hätte irgendwann mal gehört, dass der Wert 10 hartcodiert sei. So kann man sich täuschen :o Christoph

Ich interpretiere den angesprochenen Absatz aus dem von dir verlinkten Artikel so, dass alle User/Gruppen, die in der DC Policy aufgelistet sind, aber nicht per Delegierung berechtigt worden sind, max. 10 Computerkonten hinzufügen können. User die per Delegierung berechtigt worden sind UND in der Policy gelistet sind, werden von dem Limit nicht betroffen sein. User, die nur per Delegierung berechtigt sind, haben ebenfalls kein Limit. Christoph

Hi, folgendes solltest Du in eine Text Datei einfügen, und die dann als .reg-Datei abspeichern: -- snip -- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "WUServer"="http://<name oder ip des update servers>" "WUStatusServer"="http://"<name oder ip des update servers>" "ElevateNonAdmins"=dword:00000000 "TargetGroupEnabled"=dword:00000001 (0 falls keine Target Groups verwendet werden) "TargetGroup"="<name einer testgruppe falls gewünscht>" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAUShutdownOption"=dword:00000000 "AutoInstallMinorUpdates"=dword:00000000 "RebootWarningTimeoutEnabled"=dword:00000000 "UseWUServer"=dword:00000001 "RebootRelaunchTimeoutEnabled"=dword:00000000 "DetectionFrequencyEnabled"=dword:00000000 "NoAutoUpdate"=dword:00000000 "AUOptions"=dword:00000003 (4 für AutoDownload, Auto Install) "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:00000003 (uhrzeit, hier: 3 Uhr morgens) "NoAutoRebootWithLoggedOnUsers"=dword:00000001 "NoAUAsDefaultShutdownOption"=dword:00000000 "RescheduleWaitTimeEnabled"=dword:00000001 "RescheduleWaitTime"=dword:0000000a (standard ist hier 5 ) -- snap -- Die Reg Datei dann doppelklicken um sie in die Registry zu importieren. Target Groups kannst Du verwenden, um Updates auf bestimmten Clients zum Testen auszurollen. Die kannst Du auch in WSUS definieren (über den Link Create Computer Group). Eine genaue Beschreibung der Registry Settings gibts unter: http://technet2.microsoft.com/WindowsServer/en/Library/75ee9da8-0ffd-400c-b722-aeafdb68ceb31033.mspx Christoph

Gerne geschehen. Denk aber dran, dass diese User, die Du in der Richtlinie auf dem DC ermächtigt hast, nur 10 Computerkonten hinzufügen können (das ist hart codiert), und dass diese Beschränkung für User, denen die Berechtigung Computerkonten zu erstell en via Delegierung erteilt worden ist, nicht gilt. Gruß Christoph

Jetzt ist doch von HTTPS nach HTTPS die Rede? In dem Fall lässt Du Schritt 3 aus, und behältst das Zertifikat auf dem Webserver. Ausserdem braucht der ISA-Server ein Userzertifikat, mit dem er sich gegenüber dem Webserver authentifizieren kann. Müsste aber auch in dem von mir bereits verlinkten Artikel zu finden sein. Wenn Du mal gute Literatur brauchst zum ISA 2004 und dich Englisch nicht schreckt, empfehle ich Dir die ISA 2004 Bibel von Tom Shinder. Da steht das sehr gut drin erklärt: http://www.amazon.de/exec/obidos/ASIN/1931836191/qid=1141253398/sr=1-2/ref=sr_1_10_2/302-6140652-9022408 Christoph

Hi, ich habe das grad mal getestet. Folgendermaßen habe ich es hinbekommen: 1. SSL (Webserver) Zertifikat vom Webserver aus beantragen, auf dem Webserver zunächst mal installieren (in den Computer Zertifikatsspeicher). Beim Beantragen darauf achten, dass du angibst, dass das Zertifikat in den Computerspeicher kommen soll, und dass es exportierbar ist! 2. Zertifikat exportieren und auf dem ISA Server importieren, wieder im Computer-Zert.-Speicher ablegen. 3. Zertifikat auf dem Webserver löschen. 4. Secure Web Publishing Regel erstellen. Für den Public Name den gleichen Namen eingeben, den du beim Beantragen des Zerts. gewählt hast. SSL-to-HTTP Bridging auswählen. 5. Web Listener erstellen, HTTP löschen, SSL auswählen. Das importierte Zertifikat auswählen. 6. Ggf. musst Du mit Link-Translation arbeiten. 7. DNS muss korrekt konfiguriert sein, d.h. der A record für die Website muß auf das externe Interface des ISA verweisen (split DNS, falls nötig). So, ich hoffe, ich habe nichts vergessen, sonst melde ich mich nochmal. Info zum Thema gibts auch unter http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/digitalcertificates.mspx /edit: Eine Anmerkung sei mir noch erlaubt: SSL to HTTP Bridging wird im allgemeinen nicht verwendet, da Anwender i.d.R. Wert auf End-to-End Verschlüsselung legen, die bei SSL to HTTP Bridging nicht gegeben ist. Christoph

Hallo, dieser Link sollte Dich weiterbringen: http://support.microsoft.com/kb/325023/ Christoph

Kannst Du mal genauer beschreiben, wo es hakt und was nicht funktioniert? Wie hast Du die Publishing Rule definiert, wie den Listener? Christoph

Jep, VMs sind ne feine Sache :D Christoph

So genau gewußt habe ich es nicht. Deshalb habe ich das ja probiert ;) Wir haben bei uns in der Firma das Recht, computerkonten zu erstellen, ans Helpdesk delegiert, aber die DC Policy nicht angefasst. Deshalb wusste ich zwar, dass es über die Delegierung geht, und dass man damit mehr als 10 Computerkonten erstellen kann. Aber ich war mir nicht 100% sicher, ob das auch geht, wenn für das Benutzerrecht "Hinzufügen von Computerkonten zur Domäne" in der DC Policy nicht "Authentifizierte Benutzer" eingetragen ist. Christoph

Damit wäre die Sache ja geklärt. :) Mal schauen, für welche Alternative nadinsche sich entschieden hat. Christoph

Hi, ja, genauso habe ich das gemacht. Das Computerkonto für die Workstation war vor dem Join nicht erstellt. Christoph

Und schon getestet: ja, es geht, auch wenn er nicht unter "Add Workstations to Domain" aufgeführt ist, aber in dem Computers Container das Recht hat, Objekte zu erstellen, kann er eine Workstation hinzufügen. Ich habe dann mal die Security Settings des neuen Computer-Objekts gecheckt: owner war der User, der den computer in die Domain aufgenommen hat. Christoph

So würde ich den ersten Satz meines Zitats jedenfalls verstehen. Aber kann schon sein, dass es nur in verbindung mit der Policy funktioniert... Müsste man mal testen... Christoph

@IT-Home: Darauf habe zumindest ich mich mit meiner Anmerkung bezogen... /edit: noch ne Anmerkung: wenn Du das Recht für die Erstellung von Computerkonten per Delegierung vergibst, und das ganze über eine neue OU für Computerkonten, musst Du vorher noch mit "redircmp" arbeiten, damit neue computerkonten automatisch in der erstellten OU erzeugt werden, siehe hier. Christoph

Jo, stimmt, habs grad noch mal schnell nachgeschaut... Ich hatte nicht daran gedacht, dass das in der Controllers Policy schon belegt ist... Nichtsdestotrotz kann nadinsche natürlich mit einer Delegierung des Rechts auf den Computers Container oder eine neue OU für Computerkonten diese Einstellung überschreiben. Dann können auch mehr als 10 Computerkonten hinzugefügt werden. Christoph