Jump to content

Kat'l

Members
  • Gesamte Inhalte

    25
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von Kat'l

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. mir würde ja auch schon eine Antwort reichen wie: das geht nicht oder das geht nur so und so *mhm*:suspect:
  2. Hallo, ich möchte mit einer anderen Organisation verschlüsselte E-Mails austauschen. Dazu besteht auf meiner Seite eine MS Zertifizierungsstelle (unrelevant) und es sind die öffentlichen Schlüssel der anderen Organisation zugänglich (sowie Zertifizierungsstellenzertifikat-beispielsweise über Grupenrichtlinien als vertrauenswürdige CA verteilt). Wie kann ich jetzt die Kontakte mit entsprechenden öffentlichen Schlüsseln (der anderen Organisation) für jederman zugänglich machen (egal wo er sich befindet) ohne das die Schlüssel lokal gespeichert werden müssen bei jedem Nutzer? Die eine Möglichkeit wären ja die ÖO, da gibt es aber soweit ich das probiert habe, keinen Chance mit OWA.Aber zumindest wären intern die Zertifikate verfügbar. Gedacht hatte ich mit das egtl so, dass ich ein Kontakt im AD anlege und zu diesem dann das entsprechende öffentliche Zertifikat hinzufüge - aber dafür finde ich keine Möglichkeit?! Kann mir da jemand weiterhelfen?Oder gibt es da noch andere Ansätze? Katja
  3. so hoffe mein posting hilft wenigstens anderen weiter. das einzigste Problem dabei war das auch die Gruppe DomainController (nicht nur Domainbenutzer oder Domaincomputer) mit in CERT_DCOM_ACCESS eingefügt werden musste.
  4. so ich schon wieder ;) wie ich festgestellt habe, tratt der erwähnte Fehler nur dieses wochenende auf und da hatten ein Problem mit der Netzwerkkarte des Zertifizierungsserver - dh der Fehler wäre schon mal abgehakt! *juhu* aber seit letzte woche tritt der Fehler auf, welcher dem andern zum verwechseln ähnlich ist, sozusagen: Ereignistyp: Fehler Ereignisquelle: AutoEnrollment Ereigniskategorie: Keine Ereigniskennung: 13 Beschreibung: Die automatische Zertifikatregistrierung für "lokaler Computer" konnte ein Zertifikat "Domänencontroller" (0x80070005) nicht registrieren. Zugriff verweigert Bis jetzt konnte ich diesen Fehler nicht beheben, hab schon folgendes gemacht: =================================================== Zur Kontrolle ob es eine CA gab/gib, folgenden Filter setzten: dsquery * forestroot -scope subtree -filter (objectclass=PkiEnrollmentService) Mögliche Ausgabe: "CN=InternalCA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=domäne,DC=int" >> ist korrekt ------------------------------------------------------------------------------------------------- Nach SP1 wird Sicherheitsgruppe CERT_DCOM_ACCESS angelegt: - Kontrolle ob DomainBenutzer und DomainComputer hinzugefügt sind >> ja ------------------------------------------------------------------------------------------------- MS: "Zuweisen von Berechtigungen für die Zertifikatsregistrierung Zum Schluss müssen Sie jeder Sicherheitsgruppe der Domänencontroller der Domäne die Berechtigung gewähren, sich für die Domänencontrollerzertifikate zu registrieren. So gewähren Sie Domänencontrollergruppen die Berechtigung, sich für Domänencontrollerzertifikate zu registrieren 1. Starten Sie das Snap-In für Active Directory-Sites und -Dienste. 2. Klicken Sie auf das Menü Ansicht und anschließend auf Dienstknoten anzeigen. 3. Doppelklicken Sie auf den Knoten Dienste und den Knoten Public Key Services und anschließend auf Zertifikatvorlagen. 4. Doppelklicken Sie auf Domänencontroller, dann auf Eigenschaften, und wählen Sie dann die Registerkarte Sicherheit. Hinweis: Die Domänencontrollergruppe in der Domäne der Zertifizierungsstelle weist bereits die Berechtigung Registrieren für diese Vorlage auf. Sie müssen die Berechtigung Registrieren allen anderen Domänencontrollergruppen aus anderen Domänen in der Gesamtstruktur gewähren. Andernfalls verfügen diese Domänencontroller nicht über die Berechtigung, die Zertifikate Domänencontroller erfolgreich anzufordern, und deren automatische Registrierung schlägt fehl." Authentifizierter Benutzer: read; DC's: read, enroll >>ok ------------------------------------------------------------------------------------------------- certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG War erfolgreich und erhielt neuen Wert + certsvc neugestartet. ------------------------------------------------------------------------------------------------- - Rechte auf Zertifikatsvorlage "Domänencontroller" gesetzt (domänencomputer: read,enroll; auth. Benutzer: read) - Einstellung der Gruppenrichtlienen im Active Directory(-Benutzer und -Computer) auf Automatische Zertifikatsanforderung + autom. Registrierung http://www.microsoft.com/germany/kleinunternehmen/aufgaben/sicherheit/artikel/erstellen-einer-organisations-stammzertifizierungsstelle.mspx ------------------------------------------------------------------------------------------------- C:\Dokumente und Einstellungen\ibes_monitor>certutil >> Eintrag von Zertifizierungsstelle korrekt ------------------------------------------------------------------------------------------------- Rechte auf “C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys" Administrator / Benutzer /System /Jeder -> alle mindestens Rechte zum lesen, ausführen und ordnerinhalte auflisten Weiß jemand von euch noch weiter?...wäre toll. Danke schonmal fürs lesen.
  5. Hallo zusammen, ich komme bei diesem Problem echt nicht weiter. Seit wir eine Unternehmens-CA installiert haben, tritt folgender Fehler, alle 8h - ich nehme an, nach Aktualisierung der Richtlinien, auf unserem 2. DC auf: Ereignistyp: Fehler Ereignisquelle: AutoEnrollment Ereigniskennung: 13 Beschreibung: Die automatische Zertifikatregistrierung für "lokaler Computer" konnte ein Zertifikat "Domänencontroller" (0x800706ba) nicht registrieren. Der RPC-Server ist nicht verfügbar. Der anderen DC (wo die Zertifizierungsstelle installiert ist) hat das Zertifikat dagegen automatisch erhalten. weiter infos: - Windows 2003 Server + SP1 - Die Seite der Zertifizierungsstelle ist zu den vertrauenswürdigen Sites hinzugefügt. - Zertifizierungsstellenzertifikat wurde automatisch verteilt und befindet sich in "Vertrauenswürde Stammzertifizierungstellen" - Händiges Richtlinien aktualisieren (gpupdate /force) hat nichts gebracht. Leider hab ich keine Ideen mehr, auch nicht so ich noch suchen soll (eventid.net, support.microsoft.com - nix gebracht). Ist jemanden von euch dieser Fehler schon mal untergekommen oder hab ihr noch Ideen was man testen könnte? Danke für eure Hilfe.
  6. hatte nochmal alle Zertifikate kontrolliert, das Zertifikat des ISA Servers war falsch ausgestellt. der Proxy des Outlookprofils war außerdem nicht korrekt(muss ja auch msstd:externe_exchange). daraufhin habe ich am ISA ein RPC_DATA_IN erhalten. und der letzt endliche Übeltäter war dann dieser Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy ValidPorts Servername_intern:6001-6002;FQDN_intern:6001-6002;FQDN_oder_IP_extern:6001-6002; Servername_intern:6004;FQDN_intern:6004;FQDN_oderIP_extern:6004; Ich bekomme nun mein Postfach auf, dies passiert aber erst beim zweitenmal der Einwahl. woran könnte das hängen? wäre toll wenn ihr eine idee hättet. danke.
  7. ok habe jetzt die outlookfehlererkennung angeschalten und bekomme Remoteprozeduraufruf Fehlercode (6BA) was laut http://www.megos.ch/support/doserrors.txt darauf hinweißt das der RPC Server nicht erreichbar ist ... das sagt mir nun irgendwie nicht mehr als vorher. ist vielleicht der eintrag in der hostdatei nicht korrekt. oder kann es auch sein, dass das mit den Zertifikaten noch nicht genau überein stimmt?
  8. soooo dummerwiese bin ich immer noch nicht weiter. die fehlermeldung auf das rpc verzeichnis kommt jetzt wieder, ich hatte lediglich dort schreib/lese rechte vergeben. wenn ich nun direkt über IE auf das rpc verzeichnis zugreife https://externe_ip_von_isa/rpc, werde ich ja richtig weiter geleitet und laut isa log wird diese Verbindung auch zugelassen. mir scheint als ob der ISA nichts mit der outlook anfrage anzufangen weiß-also wohin er sie weiter leiten soll (? wieso auch immer, obwohl der listener der webveröffentlichungsregel auf den externen port des isa's lauscht und auf den exchange weiterleitet).deshalb habe ich noch einträge in die hosts und in die lmhosts gemacht (externe_ip_isa exchange_fqdn). leider habe ich keine ideen mehr. ich hoffe aber jemand von euch hat noch eine idee, wo der fehler liegen könnte.
  9. Hallo, und zwar möchte ich über ein outlook konto zurgiff zu meinem exchange postfach haben (rpc over http), der exchange server (ebenfalls DC und zertifizierungsstelle) befindet sich hinter einem isa server. folgende konfiguration habe ich dazu vorgenommen: -> RPC-über-HTTP Proxy installiert/eingerichtet -> Standartwebsite konfiguriert (+ Zertifikat) -> Ports für Proxy in regedit eingetragen -> Zertifikatsstelle angelegt (ISA und Client haben Zertifikate) -> sichere Webveröffentlichungsregel auf ISA angelegt (pfade für webacces und rpc in einer Regel, auch selben Listener) die stolperstelle die noch vorzufinden ist, und wo ich nicht genau weiß was da falsch läuft, ist dass bei der von mir angelegten Richtlinie im ISA im Reiter Bridging zwar SSL aktivieren kann, aber eine Zertifikats auswahl ist nicht möglich ob wohl ich für den Firewalldienst das Zertifikat eingebunden hab - ist das überhaupt notwendig (?) zur konfiguration im isa schreibe ich jetzt nichts weiter, da ich vermute das die soweit korrekt ist, auf grund dessen, dass ich von meinem client aus über webaccess auf mein postfach zugreifen kann (bitte verbessert mich fall ich da daneben liege). ebenfalls komme ich auf das /rpc-verzeichnis, es kommt die zertifikatsabfrage (name das zertifikates stimmt ja nicht mit dem von außen erreichbaren exchange überein) dann die anmeldung , aber keine fehlermeldung ( obwohl HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters NSPI interface protocol sequences - ncacn_http:6004 gesetzt ist) liegt dabei schon der fehler? nun zu meinem outlook problem: die konfiguration erfolgte nach der ms anleitung http://office.microsoft.com/en-us/assistance/HA011402731033.aspx aber es kommt keine verbindung zustande. dad log des isa servers hat mir bisher dabei auch nicht weiter geholfen... es kommt eine Anfrage an den isa server(init) und das nächste ist dann wieder die trennung, der isa baut keine verbindung richtung exchange auf, so wie es aussieht, obwohl haargenau das selbe im log des isa's bei dem webaccess zugriff drinsteht (cient und ziel-ip...) ich weißt leider nicht wo ich noch bei der fehlersuche ansetzten könnte, habt ihr da ideen? achso und eh ichs vergesse ein urlscan ist nicht mit drin.
  10. Das beim server ist echt sehr komisch :suspect: na gut, aber am client hab ich's nun auch getestet (Einstellungen sind am Server und am Client vorgenommen) und es will wieder nicht gehen....*wah* also ehrlich gesagt fällt mir dazu jetzt gar nichts mehr ein keine ahnung ob das evtl damit zusammenhängt das es bei den Druckaufträgen auch relativ lang dauert (>1min) bis sie "ankommen" und gedruckt werden?! aber ich kann mir das schwer in zusammenhang mit der Bestätigung vortsellen...was könnte das den für ne Ursache haben?
  11. ich meine wenn du direkt ein dokument vom server auf druckst, bekommst du dann auch die Bestätigung auf dem server? bis jetzt habe ich das nämlich nur so probiert.
  12. Also theoretischer Weise müsste das laufen?! *mh?* hab jetzt auch mal nur die 2 Haken drin gehabt und es kommt trotzdem nichts an. Aber muss auch dazu sagen, das ich das Ganze vom Server aus ausprobiere und es funktioniert weder zu Netzwerkdruckern noch zu Druckern an einem anderen PC. @cyrus: funktioniert das denn bei dir direkt am Server?
  13. Hey cyrus, ja die habe ich auch ausgewählt (meinte ich mit " xx> Druckerbenachrichtigung für Vorgängerversionsclients auch alle Haken gesetzt " war nur zu faul alles auf zu schreiben :rolleyes: ). und obs dazu noch ne policy gibt *mh* ehrlich gesagt keine ahnung. ich weiß nicht, habe das ganze auch noch bei einem anderen win2k3 server probiert,leider auch ohne erfolg. nun frag ich mich halt ob das überhaupt noch geht!? nutzt das jemand von euch bzw weiß ob das egtl gehen müsste?
  14. hallöchen, hat von euch jemand schon mal probiert ob er bei einem win2k3 server (w2k, xp clients) nachrichten bekommt die den druckauftrag bestätigen? ich weiß hier wollen alle den Dienst ausschalten... wenn ihr noch ne andere möglichkeit habt um die User darüber zu Informieren (damit sie nicht vergessen das sie gerade gedruckt haben ;) ) wär ich auch dafür offen. nun erstmal zur Konfiguration: - Nachrichtendienst ist aktiviert ("net send" funktioniert auch zwischen den Servern bzw Clients) - in den Servereigenschaften (Drucker und Faxgeräte) ist folgendes aktiviert: xx> Informative Benachrichtigung für lokale Drucker anzeigen xx> Informative Benachrichtigung für Netzwerkdruckeranzeigen xx> Druckerbenachrichtigung für Vorgängerversionsclients auch alle Haken gesetzt Muss sonst noch irgendwas eingestellt werden? danke fürs lesen, hoffe ihr habt ideen dazu!
  15. so also wir habens jetzt gepackt. erst haben wir das alles noch mal gecheckt: - maustreiber (USB-Maus durch Ps2 maus ausgetauscht) - Updates sind alle die gleichen drauf (auf beiden clients) - farb und desktopeinstellungen denke ich nicht, weil eine "normale" remoteverbindung erst funktioniert (deswegen auch nicht GraKa) daran lags auf jeden fall nicht. und die lösung des problems war nun ( keiner kann sich das erklären...): wir haben die ältere version davon installiert (Terminaldiensteclient), dort hat das ganze einwandfrei funtioniert. und danach wieder die Remotedesktopverbindung (neuer) laufen lassen und schon ging auch das. dankeschön für eure Hilfe!!! und wenn noch jemand ne idee hat wieso das so ist, dann würde mich das auch interessieren ;)
×
×
  • Neu erstellen...