Alle Aktivitäten

Wenn von Tobit der SQL Server kommt und dieser die Report Services installiert liegt das an Tobit oder jemand hat bei der Installation die Anleitung nicht befolgt.

Die sagen, der Kunde,bzw. Support hat dafür sorge zu tragen, das der Port80 frei und von aussen erreichbar ist. Und funktioniert hat es auch noch nicht, da es nur mit einem "Wartungsvertrag (Sidecare)" nutzbar ist, hat der Kunde aber jetzt.

Also ACME. Normalerweise wird in solchen Fällen der Tobit Server sowas selbst regeln. Hat das denn schon jemals funktioniert? Was sagt Tobit zu dem Thema?

Ja, kommt aber auf die Tobit-Version an

War bestimmt die doofe Autokorrektur… Klar ist Vizefreitag!😁

okay so halb hat es sich erledigt -> wenn ich die RemoteAPP Verbindung via GPO verteile, dann funktioniert es und der User bekommt automatisch die RemoteAPPs und auch diese lassen sich dann ohne Anmeldung starten. Wenn ich es manuell unter Systemsteuerung mache, funktioniert es nicht. Da kann ich den Feed ohne Eingabe von Credentials nicht hinzufügen

Was macht denn der Server alles außer Tobit? Oder kommt mit Tobit auch ein SQL?

Das kommt vom SQL Server Report Server. Brauchst du den überhaupt?

URL-Gruppen-ID: FC00000440000001 Status: Active Anforderungswarteschlangenname: Die Anforderungswarteschlange ist nicht benannt. Eigenschaften: Max. Bandbreite: vererbt Max. Verbindungen: vererbt Zeitlimits: Zeitlimitwerte wurden geerbt. Anzahl von registrierten URLs: 1 Registrierte URLs: HTTP://+:80/REPORTSERVER_SQLXXXXXXXXX/ Danke, damit habe ich schon mal den Übeltäter gefunden, aber wie änder ich das?

Hi, wenn es um LE geht, kannst du das (stundenlang) Troubleshooten oder du nimmst jährlich ca. 20 € - 50 € in die Hand und kaufst einfach ein Zertifikat. ;) (Dann könntest du dir vor allem den Port 80 von extern sparen.) Was gibt denn ein netsh http show servicestate mit Port 80 aus? Gruß Jan

Das ist ein automatischer Vorgang alle 60Tage wobei ein Let`s Encript-Zertifikat erneuert wird. Bei diesem Vorgang muss der Port 80 von extern erreichbar sein, was aber der Fall ist. Nur der Dienst auf dem Server, welcher den Port 80 "annimmt" ist ein verkehrter, und ich habe keine Lösung das zu ändern.

Reden wir hier über acme Zertifikatsanforderung oder was macht tobit da?

Weil das ein Tobit Server Server ist, wo ich das nicht beeinflussen kann.

Wieso regelt man Dinge wie Zertifikatsanforderungen denn per http und nicht per https?

Für eine Zertificatsanforderung soll der Port 80 frei sein. Üblicherweise ist der vom IIS belegt, in diesem Fall ist der IIS ausgeschalten. Nun wird mir bei netstat -ano gezeigt, das der Port80 mit der PID 4 belegt ist, das wiederum ist mit dem Dienst ntoskrnl.exe verbunden, kann also nicht beendet werden. Wie kann das Problem gelöst werden, ich drehe mich im Kreis.

Moin @RalphT, sag mal hast du das irgendwie gefixt bekommen? Ich hab das gleiche Problem. Sind dabei von Office 2016 auf 2024 zu wechseln. Mit 2016 funktioniert das einwandfrei. Das Problem kam erst mit 2024 hoch. Nutzen Office 2024 LTSC mit Oktober Update. Exchange 2019 CU14. OAuth ist auf dem Exchange aktiviert. Outlook verbindet sich auch via Kerberos (wenn das Profil dann konfiguriert ist) ZeroConfigExchange hatte ich schon für 2016 gesetzt. Da hat´s auch funktioniert. Aber bei 2024 klappts bei mir halt nicht. Hatte auch schon die Keys ExcludeExplicitO365Endpoint und ExcludeHttpsRootDomain probiert. Leider auch ohne Erfolg...

Donnerstag! Die Rentner haben doch eine andere Zeitrechnung.

@MurdocX nein, keine AuthN Policies hier.

Und die ist nicht aufgefallen, dass der key vom se identisch zum 2019 ist? Lange Rede kurzer Sinn: es gibt derzeit genau zwei keys weltweit. Einmal für die Standard Edition und einmal für die Enterprise Edition und die sind für 2019 und SE gleich. Personalisierte keys wird es voraussichtlich ab cu2 geben.

Moin an Board, so starten wir dann in den Tag - ich koche Kaffee Allen einen guten Dienstag, bleibt gesund! Hier derzeit klar bei 7°C, es wird ein freundlicher Tag bis etwa 15°C Wer konnte den tollen Vollmond sehen? Hier war es abends leider leicht bewölkt

Ich habe gestern einen Exchange 2019 (bisher ohne sa) mit dem SE und OCT25SU upgedatet. Das ging problemlos und der Server war auch noch aktiviert. Ich habe dann den neuen Key für die SA eingespielt und da sagte er mir, dass der Server bereits lizenziert sei. Nur mal aus Neugierde, wie überprüft denn MS, ob man eine SA gekauft hat oder nicht?

@cj_berlin hast du zufällig bei Dir in der Testumgebung Authenication Policies und Silos? Laut meiner Recherche scheint sich zu verdichten, dass Cross-Forest-Referral ohne Claims/Compound kein FAST enthalten. Kannst du das evtl. gegenprüfen? Ich bin bzgl. Claims/Compound nicht mit festem Schuhwerk unterwegs, um eine valide Aussage treffen zu können.

@cj_berlin Das Ergebnis habe ich bekommen, also ich vom Member in berlin.local auf den Member in muenchen.local zugegriffen habe. Anderst herum, wurde es mit einem Fehler quittiert. Leider bisher nur die halbe Miete. So langsam gehen mir die Ideen aus. Ich werde mal das KDC-Logging auf den DCs einschalten. @daabm alles Beides doch "legacy" Konfiguration ⚙️(Domäne berlin.local) KDC - Kerberos Amoring -> Fail unamored authentication requests ⚙️(Domäne muenchen.local) KDC - Kerberos Amoring -> Supportet berlin.local -> muenchen.local ✅ muenchen.local -> berlin.local ❌ * muenchen.local -> berlin.local klist get cifs/lab02-srv-ber01.berlin.local Current LogonId is 0:0x673703 Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x52e klist failed with 0xc000006d/-1073741715: The attempted logon is invalid. This is either due to a bad username or authentication information. * Screenshots Member muenchen.local * Screenshots Member muenchen.local

Ja, das sind die Tickets, und Du müsstest auch ein TGT von BERLIN ausgestellt im 0x3e7 Kontext auf lab02-srv-muc01 finden. Ist es schon im Enforced-Modus oder noch Supported? Denn wenn es schon im Enforced ist, bist Du ja so weit wie ich

DAS schaff ich mir drauf, wenn wir NTLM weg haben... It's a long way to the top, if you wanna rock'n'roll Ich glaub hier können sich nur wenige vorstellen, was für ein Aufwand es ist, überhaupt erst mal NTLM loszuwerden in einer Enterprise-Infrastruktur, in der sich niemand jemals darum gekümmert hat, daß DNS "Kerberos-freundlich" ist.