4zap
-
Gesamte Inhalte
353 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von 4zap
-
-
von unserem IIS mit Windows Enterprise CA:
.crl application/pkix-crl
.crt application/x-x509-ca-cert
.cer application/x-x509-ca-cert
bzw: hier eine Übersicht:
https://msdn.microsoft.com/en-us/library/bb742440.aspx
Kann man direkt im IIS-Manager auf dem Server unter MIME-Types eintragen
Hi
das ist ja die default Einstellung auf einer CA Webseite auf MS Server. Der Mime Type gibt ja an wie die Datei zu handhaben ist. Hier in deinem Beispiel geht das nur mit IE und aktiviertem ActiveX, klickt man auf die Links startet ja der Zertifikatsassistent und fragt dich ob du die Installation zulassen willst bei application/X509-ca-cert. Ich brauch die .cer oder .crt (egal welche) als Download. Die Seitenbesucher klicken rauf, die .cer Datei wird runtergeladen im Browser und liegt dann als Datei im Download Ordner (oder wo auch immer auf der Platte). Was der User damit macht ist erstmal wurscht. Es soll nur nicht ausgeführt werden
Früher ging das mal einfach mit mime type file/download. Bei diesem IIS Webserver nicht, hatte jetzt testweise das directory browsing aktiviert aber das ändert auch nichts. Der Browser tut immer so als wär es ein Link und haut einen 404 raus - der IIS weiß nicht was er damit anstellen soll. Das ist mein Problem. file/download hat immer funktioniert (zumindest bis version6).
-
Hallo
ich muss ein .crt File zum download auf dem IIS 8.5 bereistellen. Die .crt Datei liegt im Hauptverzeichnis für diese Webseite. Egal was ich anstelle der Link zur Datei führt immer zu einem 404.
Die Seite ist reines HTML, ASP ist nicht gewünscht, soll rein statisch arbeiten.
Im Mime Type hab ich schon den Typ für .crt Dateien auf "file/download" geändert .... da klappt aber nicht.
Für .crl Dateien (Sperrlisten) klappt das. Der Mime Typ dafür ist application/pkix-crl, da kann der Webserver mit umgehen und die Sperrliste wird mir als Download angeboten. Das kann ich aber nicht für .crt oder .cer verwenden. Das File handling klappt damit ja nicht.
Wie muss der mime type beim IIS 8.5 aussehen? Gibts file/download überhaupt noch auf der Version?
der part in der web.config sieht so aus:
<staticContent> <remove fileExtension=".crt" /> <mimeMap fileExtension=".crt" mimeType="file/download" /> <mimeMap fileExtension=".cer" mimeType="file/download" /> </staticContent> -
Das es andere Möglichkeiten gibt, ist mir bewusst. Mich interessiert aber eher die oben genannte Problematik. Finde es merkwürdig, das ich keine Antwort vom Server von extern bekomme, während es beim Win2012R2 jedoch bei gleicher Konfiguration einwandfrei funktioniert.
Ist RDÜ überhaupt konfiguriert auf dem Server2016? Wie oft wird vergessen RDP überhaupt zu erlauben....
Aber den Server via forwarding so auf ein goldenes Tablet zu legen halte ich für keine gute Idee.
-
Einen schönen guten Morgen :)
Mein nächstes Projekt ist einen SBS2011 abzulösen. Der letzte ist schon ein wenig her und dort hatte ich die Domäne komplett neu aufgesetzt. Nun wollte ich kurz nachfragen, ob etwas gegen eine normale Migration SBS2011 -> Server 2016 spricht? In einem anderen Thread hatte ich diesen Link hier gefunden, welche die Migration zu einem Essentials Server beschreibt: https://technet.microsoft.com/en-us/library/jj721750.aspx.
Wie die einzelnen Migration von Exchange und AD, etc. durchzuführen sind, ist mir klar. Nur halt die generelle Frage, ob es "geht" oder etwas dagegen spricht?
Lg
Stefan
Naja was bleibt dir anderes übrig? SBS gibts nicht mehr, also bleibt dir nur standalone oder du gehts mit dem Exchange in die Cloud. Office365. Da gibts einige Migrationsstrategien für. Spart dir die Hardware für den Exchange und die Wartung dafür. Standalone geht auch ohne Probleme.
Ich mochte die SBSe sehr, für kleinere Unternehmen eine kostengünstige und realisierbare Lösung. Ich finds schade das MS die abgesägt hat. Aber wenn man die Strategie von MS betrachtet war es wohl überfällig und zu billig um damit Geld zu verdienen.
-
Aktiviere an einem Client mal das Log Capi2 und melde einen User an der kein Userzertifikat hat. Dann solltest du in besagten Log sehen, ob die Anfragen evtl. Fehlschlagen.
Hallo tesso
wie oben noch am Ende angefügt, ich war mal wieder zu ungeduldig. Als alles repliziert war auf alle DC's weltweit hat er auch wieder ausgerollt, Aber danke für den Tipp. Vermute hier klemmte die GPO. Insgesamt waren es mehr als zwei Stunden Wartezeit. Vielleicht klemmte auch irgendwo die Verbindung im Azure.... es geht jedenfalls wieder wie gewohnt.
-
Hallo Leute
heute rollt meine PKI keine Userzertifikate mehr über das autoenrollment aus. Was bislang immer sauber lief will seit drei Tagen nicht mehr. Jeder der sich an einem Computer im Firmennetzwerk anmeldet (corp.domain.xx) erhält ein Userzertifikat wenn für ihn noch keins auf diesem Rechner existiert. Das Autoenrollment für die Computerzertifikate funktioniert nach wie vor. Frisch deployte Rechner die über den SCCM angesteuert wurden haben alle ihr Computerzertifikat erhalten, nach Anmeldung eines Users am Rechner kommt die GPO für die autoenrollment durch und wird auch als erfolgreich angezeigt. Aber ausgeführt wurde die nicht. Das Userzertifikat ist nicht im Store... auch nach mehrmals neu starten, GPO forcen, usw. kommt da nix an.
Ich finde im Eventlog nix (am Client) egal wo ich schaue. Zwischendurch tauchten mal Certification errors auf mit der eventID 64 und 65. Recherche dazu brachte nichts brauchbares. An der RootCA sehe ich noch nichtmal die Anfrage.
Kurze Analyse:
- DNS geht, Hostnamen können aufgelöst und erreicht werden
- über die SubCA kann ich per https://meinserver/certsrv Userzertifikate requesten und die werden auch ausgestellt
-das ganze geht auch über intranet mit der RootCA (offlline CA) per https://meineCA/certsrv, der request geht durch, das Userzertifikat wird ausgestellt und kann installiert werden
- das ganze geht auch in der MMC für die Benutzer.... ich kann bei der RootCA ein Zertifikat requesten und es wird ausgestellt.
Es läuft eigentlich alles, nur das autoenrollment für die lxkcjcfs84(hier steht ein langer häßlicher Fluch) wollen nicht mehr. Bei der Masse an Clients die wir verwalten wäre das Autoenrollment schon schick, ich möchte nicht an jedem neuen Client einen manuellen Request losschicken müssen.
Die Berechtigungen des Zertifikatstemplates sind ok, alle Rechte für auth. Benutzer für das Autoenrollment sind richtig.
GPO wurde schon neu erstellt, keine Besserung dadurch.
Ich vermute hier trotzdem auch eine Sicherheitsfilterung. Weiß jemand wo ich noch schauen kann um den Fehler zu finden? Certutil kenn ich, hab aber selten damit gearbeitet.
Jemand noch ne Idee bevor ich Ivan in Bukarest anrufe?
Danke & Gruß
Danke, hat sich erledigt. Hat wohl einen Moment gedauert bis meine neue GPO griff. Es geht wieder, User kriegen wieder automatisch ihr UserCert wenn sie sich anmelden und es ist noch nicht auf dem Rechner installiert war. :D *froi*
-
Genau dieses Szenario haben wir auch mal versucht. Oh toll, eingebaute Hochverfügbarkeitslösung!
Kannste vergessen, in der Praxis macht das nur Probleme. DFS Server 1 und DFS Server 2 sind bei den interessanten Ausfällen ggf. nicht synchron (DFS Backlog), irgendwer hat noch eine Datei in Bearbeitung und es gibt dann Probleme wenn die Server wieder zurückgewechselt werden. Auch machen manche DFS Clients nicht das was man erwartet, zack ist er auf einem anderen Server als erwartet. Am Ende hast du Datenverlust und suchst dir einen Wolf nach der einen wichtigen Excel Datei irgendwo in den DFS Syncordnern. Nene.. lass mal. Das klappt so nicht, das musste ich bei unserem Versuch durch Schmerzen lernen.
Hai
Kolaboration für Teams geht mit dem Office365 Gruppen super. Man muss sich nur mal damit beschäftigen. Hier arbeiten 53 Teams in 53 Office 365 Gruppen zusammen an Dokumenten usw. Jeder kann sehen wer gerade in welchem Feld arbeitet. Der neue OneDrive for Business Client ist auch ganz gut zu handhaben, sieht so ähnlich aus wie die aktuelle DropBox. Man muss nur die Administration vorab klären, machs nicht im Sharepoint sondern direkt im Office365 Admin. Ein Konzept für die Umsetzung sollte vorher erstellt werden.
Bei uns sind wir von der alten Verteilerlistenstruktur direkt in die Office365 Gruppen migriert. Auch GoogleBusiness war im Gespräch. Jedoch sind die Funktionen von Excel online um Längen besser als diese Google Tabellentools. Selbst der Chef fands super und das sind meist die, die keine Lust auf Veränderungen haben. Die Funktionen haben aber 100% überzeugt.
-
Huhu
kurzes Update damit der Beitrag auch Sinn macht. Die managed PKI's lassen sich die kommerziellen Anbieter richtig gut vergolden. Die Preise für alle MA übertreffen meine bösesten Erwartungen. Somit ist managed PKI gestorben, die laufenden Kosten sind zu krass wenn man bedenkt wir haben einen eigene CA im Azure stehen.
Signierte Emails brauchen wir in erster Linie für die Partnerkommunikation. Somit hat ich einfach eine SubCA im Azure aufgesetzt, mit der RootCA verbunden, die CRLs und Zertifikatskette öffentlich ansprechbar gemacht und am Ende Userzertifikate für Emailsignierung, verschlüsselung per autoenrollment verteilt. Hat ein paar Tage gedauert aber jetzt haben alle User ihr Clientzertifikat und der Empfänger kann über die SubCA auf CRL und EntepriseCA erreichen. Klappt. War aber buggy.... es gibt wohl einen Bug wenn man das erste Mal einen request Richtung RootCA schickt.
-
Hallo Leute
ich brech mir grad mal wieder einen ab.
Ich versuche eine RPC Verbindung von meiner SubCA zur RootCA zu etablieren und das Stammzertifikat zu requesten. Ich erhalte Fehler
0x800706BADer ist eigentlich bekannt. Meistens liegts an den Berechtigungen im Component Server von CertRequestService. Die habe ich überprüft, stimmen alle.
Firewall überprüft auch beiden Seiten (sind Azure VMs) lokal und ports 60007 - 6032 auf gemacht (mit Absenderscope filter).
Eine WMI Abfrage zu der RootCA ist fehlerfrei ->
Get-WmiObject Win32_ComputerSystem –ComputerName MeineCAServer
Das Resultat ist erfolgreich, ich sehe in der Ausgabe Domäne, Hersteller usw.
Versuch in einen
telnet meinRootCAServer 6007
krieg ich keine Verbindung zustande. Ich vermute es liegt an der Firewall. Ports 6007 bis 6032 habe ich lokal freigeben. Im Azure portal habe ich für beide Server eine Netzwerksicherheitsgruppe eingerichtet und auch dort die Ports aufgemacht und freigegeben für die SubCA (mit Absenderscope filterung)
telnet auf port 6007 schlägt immer noch fehl.
Noch jemand eine Idee dazu?
Hab ein Ticket in Azure aufgemacht. Nachdem ein Kollege auch nix findet was faul sein könnte (netstat spuckt mir die Ports aus) wart ich mal was MS dazu sagt.
-
Moin,
zumindest gab es mal Paketlösungen, bei denen man über eine Schnittstelle automatisiert Personenzertifikate ausstellen lassen kann. Auf die Schnelle finde ich das nicht wieder, möglicherweise gibt es das auch nicht mehr. Selbst wenn, wäre aber die Frage, ob sich das mit Office 365 integrieren lässt - vermutlich nicht. Das ist eher was für Gateway-Lösungen.
Was es aber gibt, sind Zertifikatspakete, mit denen man eine größere Zahl von Personenzertifikaten erwirbt. Die sind dann auch wieder nicht gar so teuer, zumal es dort Staffelrabatte gibt.
Gruß, Nils
kurzes Update:
Genau so wirds aussehen. GlobalSign bietet ein Rootzertifikat an was genau das kann und auch O365 kompatibel ist. Wenn umgesetzt werd ich mal berichten. Bin sicher nicht der Einzigste der die Frage hat.
-
ein Zertifikat alleine wird Dir da nichts nützen. Ich denke, dass Du für jeden User ein gesondertes öffentliches SMime Zertifikat brauchst. Bei 600 Usern wird das ein teurer Spaß
Die Kosten dafür sind nicht gering, ich gehe hier von ca 20 Euro/User für 24 Monate aus.
Moin,
es gibt für sowas auch "Paketlösungen", bei denen man basierend auf einem kommerziellen Zertifikat die Einzelzertifikate selbst erzeugen kann. Ich weiß aber nicht, ob das auch mit Office 365 einsetzbar ist.
Edit: Einen Überblick, wie man Office 365 mit einer internen PKI zusammenbringt, gibt es bei Frank Carius:
http://www.msxfaq.de/cloud/exchangeonline/o365smime.htm
Er beschreibt auch sehr schön einige der Hindernisse, die sich dabei auftun. Was dort aber fehlt, ist die Frage, wie man das "technische Vertrauen" zur Gegenstelle herstellt - und das ist eben meist mit kommerziellen Zertifikaten leichter herstellbar, weil man nicht neben dem Userzertifikat auch noch das Root-Zertifikat weiterreichen muss.
Gruß, Nils
Eigene PKI scheidet aus genau aus diesem Grund: Wie kommt die Gegenstelle an die Root CA?
Paketlösung wäre perfekt. Ich installiere das Stammzertifikat von Comodo auf unserer PKI im Azure AD und verteile daraufhin Userzertifkate. Hab ich aber noch nie gemacht, weiß nicht wie ich das anstellen soll. Weiß da jemand mehr oder hat mal ein paar Links zur Hand? Vermute das ist nicht ohne.
-
Moin,
wenn du Mail verschlüsseln willst, braucht der Kommunikationspartner dein Zertifikat und muss diesem vertrauen. Das bedeutet in aller Regel, dass ein kommerzielles Zertifikat besser ist. Sonst hast du jedes Mal das Problem, dass das Root-Zertifikat der eigenen PKI zum Endanwender auf der anderen Seite muss.
Gruß, Nils
Hallo Nils
das hab ich befürchtet das ich hier ein kommerzielles nehmen sollte. Dank dir! Das hilft mir iim Vorfeld sehr.
-
Hi
für einen 600 User Tenant soll ich signierte Emails bereitstellen. Es gibt eine eigene PKI die ich dafür genommen hätte. Jetzt hat der CTO Bedenken, ich soll ein Comodo Zertifikat nehmen. Halte ich für Blödsinn.
Wo ist der Unterschied zwischen einem gekauften oder einem selbstausgestellten von der PKI?
Find da nicht wirklich was mit Tante Google. Kann mir da jemand ob ich mit dem selbstausgestellten irgendwo Probleme bekommen könnte?
-
Moin,
und der NetBIOS-Name der Domänen?
*HandandieStirnklatsch* Wie recht du hast.
Zum Glück ist die zweite Domäne ein reines Testscenario so das ich mit rendom arbeiten kann ohne das ich jetzt die halbe Firma stilllege.
Dank dir!
-
Hi
beide Domänen unterscheiden sich nur in der Endung. Einmal corp. firma.com der andere ist corp.firma.info. Der Netbios Name der DC's ist aber unterschiedlich. Geklont voneinander sind die auch nicht.
ceups-dom001.corp.firma.com
cgsups-dom0001.corp.firma.info
Müsste doch passen oder?
ich schau mal mit Telnet ob wirklich alle Ports auf beiden Seiten erreichbar sind.
-
Schon älter aber genau das war das problem. Der SCCM muss mit seinem Computeraccount das Recht haben auszurollen. Dann klappts auch mit m Nachbarn.
-
Hallo
hab schon mehrmals erfolgreich zwei Domänen per Trust verknüpft, war nie ein Problem.
Nun hab ich zwei Domänen im Azure, zu jeder Domäne gibt es im Azure einen DC. Die Konfiguration ist fertig, der Trust wird abgelehnt. Funktionslevel ist auf beiden Seiten Server2012r2, Beide DCs sehen sich gegenseitig und können per FQDN angepint werden. Verbunden sind die beiden virtuellen Netze mit dem Azure site2site VPN. Die Domäne kann auch jeweils an beiden DCs aufgelöst werden (corp. domäne.endung1 und corp.domäne.endung2) über FQDN. Ich hab auch die entsprechenden Rechte dazu. Geb ich mein Passwort falsch ein kommt ein Access denied..... wenn ich es richtig eintippe kommt ein The operation failed. The error is: This operation cannot be performed on the current domain.
Ich hab hier irgendwie die Ahnung das das im Azure etwas anders läuft als auf onprem Hardware. Kann mir da jemand weiter helfen? Steh total aufm Schlauch und Tante Google hilf mir nicht. Bevor ich jetzt wieder den Support nerve frag ich mal kurz hier :D
Danke & Gruß
-
Da gibts im Office365 auch das Online Archiv falls du was auslagern musst. Kannst du im Portal pro User aktivieren.
-
Danke für den Input und noch frohe Weihnachtsmänner...
Die Developer habens versaut. Im DNS der Domain hatte jemand ein *.Domäne als CNAME gesetzt.
Nach einem eindringlichen Gespräch macht der das nie wieder. :D
Der Traffic in den Logs hat arg nachgelassen :) -
Hallo
folgende Konfig:
O365 Tenant mit E3 Plan, mehrere Domänen sind integriert und bestätigt. DNS Einträge sind gesetzt im O365 ist bei DNS alles grün, das beinhaltet auch den autodiscover. Eintrag im DNS beim Webhoster. Zeigt alles Richtung Exchange online. Ich ging davon aus das Outlook oder Smartphones die den autodiscover abfragen durch die DNS Einstellungen direkt ins Office365 schauen und sich dort die autodiscover.xml abholen. Die schauen aber auch auf die normale Domäne. Die haben wir im AWS abgelegt und dort ist auch die Webseite. Dort laufen die Logs voll von wegen
172.31.24.171 - - [12/Dec/2016:13:09:04 +0000] "POST /autodiscover/autodiscover.xml HTTP/1.1" 301 446 "-" "Microsoft Office/15.0 (Windows NT 6.1; Microsoft Outlook 15.0.4875; Pro)" meinedomäne.de 82.134.32.90 0.001
Das sieht mir nach eine Outlook 2015 Anfrage aus.
Die hier
172.31.1.155 - - [12/Dec/2016:13:07:16 +0000] "GET /autodiscover/autodiscover.xml HTTP/1.1" 404 405 "-" "OC/16.0.6965.2105 (Skype for Business)" www.meinedomäne.de 82.134.32.90 0.001
sieht mir nach Skype aus...der Unterschied ist nur hier wird die www abgefragt.
Kann mir jemand sagen wieso die Anfragen auf dem Webserver landen? Mein DNS ist richtig konfiguriert und ich versteh nich wieso die Logs vollaufen mit 404 (bei www.meinedomäne.de) und 301 bei (meinedomäne.de). Die Anfrage dürfte doch dort gar nicht ankommen.
Das passiert bei mehreren Domänen und die Einträge stammen von allen möglichen Office Version, Windows oder Mac, Skype etc...
Es läuft hier alles, Email und Skype alles gut. Von daher kein Problem, ich muss nur meinem Webdeveloper langsam erklären wieso mein Exchange den vollspämt :D
-
Hai Alle
für einen Azure Cloud Deployment Point und die Verbindung zum Config Manager (current branch) hab ich auf unserer PKI das Webserver Template dupliziert, benannt und konfiguriert. Die Berechtigungen zum "enroll" wurden gesetzt. Jetzt will ich das ausrollen, es erscheint aber nicht in meiner Template Liste.
Zuerst war ich der Meinung ich muss auf die Replikation warten, aber warten hat nicht geholfen. Wenn ich in der CA auf Certificate Templates gehe und dort mit der rechten Maustaste den "new" -"certificate template to issue" auswähle sehe ich in der Liste die Templates (zumindest die auf denen ich Berechtigung zu ausrollen hab) aber mein dupliziertes Template nicht.
Die Berechtigungen zum Ausrollen hab ich schon 1000x geprüft.... es will nicht erscheinen.
Dienste und Server hab ich zwischendurch schon durchgestartet, hat aber nichts gebracht.
Irgendwer ne Idee zu dem Problem? Wo stell ich mich bucklig an? Weiß das wer?
Danke und Gruß
Rainer
Testweise nochmal ein Template dupliziert und konfiguriert. Das erscheint in meiner Templateliste und kann auch ausgerollt werden. Ich raffs nicht.... Ich lösch beide Certis nochmal und mach das nochmal und berichte dann nochmal.
kurzes Zwischenupdate:
Also was komisch ist ist die Tatsache das den Domänenadmins direkt das "Enroll" Recht mitgeben muss. Setze ich das nachträglich erscheint mein Template nicht in der Liste...vom Server 2008r2 kenn ich sowas nicht.... schon komisch.
-
Fakt ist das das mit dem Metadaten recording im Azure Portal nicht 100% funktioniert und da hat MS noch einige Arbeit vor sich.
Also wer über diesen Beitrag stolpert und Hilfe braucht wendet sich am besten direkt an den Azure Support Manager der euch zugeteilt wurde im Laufe der Zeit.
Webseiten die einen Login über zwei Pages haben sind nicht implementierbar über shared accounts. In großen Organisationen rate ich hier zu SAML2.0. Es funktioniert einfach und ohne Ärger.
-
Danke für die Tipps, werde mir Intergator anschauen und ggf. Sharepoint 2013/2016 evaluieren.
By the way habe Mindbreeze InSpire offeriert bekommen, 12'000€ pro Jahr (Mindestlaufzeit 3 Jahre oder 36'000€). Da hat mich fast der Schlag getroffen...
Wir nutzen die Enterprise Search im Sharepoint online. Wir sind eh komplett in der Cloud. Geht auch mit Hybrid falls ihr einen Sharepoint onprem betreibt und lokale Fileshares vorliegen. Der Index wird in die Cloud gesynct bei Hybrid, das ist verdammt schnell... aber UNC Pfade werden ausgegeben... 12K ist verdammt viel Geld für ein Drittanbieter Tool.
-
Hai
ich verteile ein paar myApps auf die die User im Office365 Portal zugreifen können, d. h. das sind meist externe Webseiten mit irgendeinem Service die dort angesteuert werden.
Die meisten über SAML 2.0 mit gültigen Token und das klappt auch super.
Für ein paar Webservices hab ich einen gemeinsamen Login, d. h. ich möchte das wenn der User auf die myApp im Office Portal klickt soll sich die Webseite öffnen und er wird dort automatisch angemeldet und ist "drin" ohne SAML oder LDAP etc....
Das funktioniert leider nicht immer. Azure erfasst die Metadaten wenn ich die Anmeldung konfiguriere und nachdem ich die Login Daten eingegeben hab erhalte ich die Meldung das die Metadaten gespeichert wurden. Ich weise das dann einer Gruppe zu und die sehen die App dann im Portal oder im myapp.microsoft.com Portal. Klickt man dann drauf landet man auf der Webseite.... aber nix passiert, oder die Login Daten sind im Login Fenster eingetragen aber es erfolgt keine Anmeldung. Bei einer anderen Webseite funktioniert es. So langsam bin ich verwirrt.
Hat mal jemand einen Link zur Azure Doku wo erklärt wird wie man eine App einrichtet für Gruppen die gemeinsame Login Credentials nutzen sollen ohne diese zu kennen?
Hab mich durch die Azure Referenzen gequält ohne wirkliches Ergebnis. google half mir auch nicht.
Danke :)
IIS 8.5 Download von .crt Dateien ermöglichen
in Windows Server Forum
Geschrieben
Hatte ich schon versucht, aber ich teste nochmal. Danke.
Nee, klappt leider auch nicht...... irgendwo ist der Wurm drin.. ich such mal weiter.