4zap

Hatte ich schon versucht, aber ich teste nochmal. Danke. Nee, klappt leider auch nicht...... irgendwo ist der Wurm drin.. ich such mal weiter.

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>

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.

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.

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*

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 0x800706BA Der 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.

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.

Die Kosten dafür sind nicht gering, ich gehe hier von ca 20 Euro/User für 24 Monate aus. 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.

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?

*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.

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 :)