-
Gesamte Inhalte
3.624 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Christoph35
-
-
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
-
hallo christoph
ich hab einen öffentlichen dns eintrag für die domain test.blabla.net eingerichtet. der a-eintrag zeigt auch auf die öffentliche IP. es kann also kein dns-problem sein, es funktioniert ja auch über http von außen.
das zertifikat ist auf den fqdn ausgestellt test.blabla.net ausgestllt und kommt von meiner internen ca. das root ca liegt ebenfalls im zerifikatsspeicher am isa. die hakerl bei der certificate revokation sind auf ja/ja/nein gesetzt, was ja auch richtig sein sollte.
in der rule, die test.blabla.net heißt, wird unter "public name" auf test.blabla.net gehorcht.
Soweit ist das alles korrekt.
jetzt ein ABER: die domain ist auch in der hosts datei hinerlegt, die auf den internen server 10.1.14.6 zeigt.
auch noch ok, wenn du mit "die domain" den externen Namen der Website meinst
die IP ist auch im To-Tab eingetragen, weil der isa sonst ja im kreis läuft ja funktioniert ... :(
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:
In diesem Schritt müssen Sie Angaben drarüber machen, an welchen Webserver die Anfrage weitergeleitet wird. Normal würden Sie hier denwirklichen FQDN des Webservers eintragen, da Sie normal ein Zertifikat auf dem Webserver importiert haben, das für diesen ausgestellt ist,
ansonsten würde die SSL-Verbindung fehlschlagen. Auf dem Webserver haben Sie aber das Webserverzertifikat für shop.meinefirma.de importiert, somit müssen Sie auch diesen FQDN als Weiterleitungsserver eintragen. Durch den Eintrag in der HOSTS-Datei wird der Name in die interne IP-Adresse aufgelöst und an den internen Webserver weitergeleitet.
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 ...
Things break when the common name on the server certificate doesn´t match the name used by the client request. There are two places where things can break in the SSL-to-SSL-bridging scenario:
- If the common name on the certificate used by the ISA server firewall to impersonate the Web site doesn´t match the name (FQDN) used by the Web client on the Internet
- If the common name on the certificate on the Web site doesn´t match the name (FQDN) used by the ISA firewall service to forward the request; the name in the ISA firewall´s request to the published Web server is determined by the entry on the To tab in the Web Publishing rule
...
Warning: You will encounter the dreaded Internal Server Error 500 if there is a mismatch between the name in the request and the name on the certificate.
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:
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
-
-
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:
• Users who have the Create Computer Objects permission on the Active Directory computers container can also create computer accounts in the domain. The distinction is that users with permissions on the container are not restricted to the creation of only 10 computer accounts. In addition, computer accounts that are created by means of Add workstations to domain have Domain Administrators as the owner of the computer account, while computer accounts that are created by means of permissions on the computers container have the creator as the owner of the computer account. If a user has permissions on the container and also has the Add workstations to domain user right, the computer is added, based on the computer container permissions rather than on the user right
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
W2K3 - LsaSrv
in Windows Forum — LAN & WAN
Geschrieben
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