phatair

Eine Frage ist mir noch eingefallen. Gibt es eigentlich eine Liste der Service Classes für die SPNs? Ich habe dazu irgendwie nur die allgemeine Info von MS gefunden https://learn.microsoft.com/en-us/windows/win32/ad/name-formats-for-unique-spns Das klingt für mich so, als könnte ich beliebig wählen was ich dort eintrage. Aber was genau macht diese dann, wenn ich das einfach beliebig erstellen kann. Oder versteh ich hier was falsch? Wenn wir bisher einen weiteren SPN für einen Server z.B. für einen SMB Share oder eine Webseite benötigt haben, dann hatten wir ja nur den netdom Befehl ausgeführt. Dieser hat dann den SPN gesetzt und auch den DNS Alias erstellt. Der Befehl hat dann einfach für alle bestehenden service classes auf dem entsprechenden AD Objekt die SPNs eingetragen. Als Beispiel Auf einem Server haben wir den SPN server1 mit dem netdom Befehl hinzugefügt. In dem Server AD Objekt wurde dann HOST/server1 RestrictedKrbHost/server1 Termsrv/server1 WSMAN/server1 hinzugefügt. Ist das jetzt komplett falsch? Mit SetSPN müsste ich ja den Service angeben. Das heißt wenn ich das für einen SMB Share mache, gebe ich als service CIFS/ an. wenn ich das für einen Webserver mache, gebe ich HTTP/ an, usw. Oder reicht es auch, einfach nur HOST/ anzugeben? Bin grad etwas verwirrt

Danke euch! Ich schaue mir das Thema mal etwas genauer an. Am Ende macht man mit SetSPN erstmal nichts falsch, gerade wenn man nicht zu 100% weiß was man tut. Da hast du Recht, Evgenij.

Das mit Set-ADxyz ist natürlich der einfachste Weg, dass stimmt. Ich dachte immer, dass man die speziellen Tools wie netdom oder eben SetSPN dafür nutzen muss, da man sonst mehrere manuelle Schritte durchführen muss. Aber dann schaue ich mir Set-AD mal an. Wenn wir jetzt bei dem Thema schon sind, vielleicht kann mir jemand die Frage auch beantworten :) Ich muss ja dann eine "Service class" mitgeben. Hier steht ja z.b. dann HOST/ oder RestrictedKrbHost/ mit dabei. Wir setzen den SPN vor allem für Webservcies oder SMB Shares. Da reicht dann ja ein HOST oder irre ich mich da?

Hi Martin, danke dIr! Dann nutzen wir ab sofort auch nur noch SetSPN. Soweit ich das verstanden haben, nutzt man die SPNs ja auch nur wegen der Kerberos Authentifizierung und da reicht es ja, wenn in der AD die Einträge gesetzt werden. Gruß, Steffen

Vielen Dank Martin. Ich habe jetzt auch rausgefunden woran es liegt, dass ich mit dem Domänen Admin "Zugriff verweigert" beim abrufen der SPNs mit dem NetDom Befehl erhalte. Bei uns sind die Domänen Admin Accounts auf den Servern und Clients aus der "Administratoren Gruppe" entfernt. Der NetDom Befel benötigt aber wohl die administrativen Rechte um den SPN auszulesen, da ich ja remote auf den Server zugreifen würde (meine Vermutung). Wenn ich den Domänen Admin in die "Administratoren Gruppe" aufnehme, funktioniert auch der NetDom Befehl. Wenn ich es also richtig sehe, dann fragt der setspn Befehl die Infos direkt aus dem AD Objekt ab, der netdom Befehl fragt diese dann wohl vom Server direkt ab. Das ist wahrscheinlich die Info vom Martin, dass Netdom WinNET-Provider nutzt und SetSPN ADSI nutzt. Ich dachte auch immer, dass beim SPN setzen auch lokal auf der Maschine was verändert werden muss und das mit dem netdom Befehl automatisch durchgeführt wird. Die Info hatte ich hier gefunden: https://woshub.com/add-alternate-computer-name-windows/ Macht das der setspn auch oder setzt der nur den Wert im AD Objekt und ich müsste den registry parameter dann manuell auf dem entsprechenden Server setzen? Grüße

Top, danke dir. Dann werden wir in Zukunft SetSPN verwenden und nicht mehr netdom. Mich wundert es zwar immer noch, warum es bei netdom den "Zugriff verweigert" Fehler gibt, aber mir fehlt die Zeit das jetzt zu klären :) Das die Berechtigungen passen, sieht man ja eigentlich am funktionierenden SetSPN Befehl. Schönen Abend Dir.

Hi Jan, ha...das ist ja faszinierend. Damit funktioniert es. Das heißt dann wohl auch, dass wir setspn auch zum setzen der SPNs nehmen sollten und nicht mehr netdom, oder? Wenn ich es richtig sehe, ist netdom dann die "alte" Variante? Ich war einfach nur verwundert, da das setzen der SPN bisher damit immer gut funktioniert hat. Nur beim auslesen ist nun aufgefallen, dass es bei unterschiedlichen Usern plötzlich Probleme gab (obwohl deren Berechtigung auf die AD Objekte identisch waren). Gruß, Steffen

Hallo zusammen, ich habe folgends Problem bzw. verstehe das Verhalten nicht so ganz. Wir haben bei einigen Windows Server 2019 Servern den SPN über den Netdom Befehl eingetragen. Das Auslesen des SPN über "netdom computername <server name> /enum" funktioniert dann manchmal mit dem Domänen Administrator und manchmal mit unseren "Server Admins". Die Fehlermeldung lautet dann einfach nur "Zugriff verweigert". Ein wirkliches Muster habe ich noch nicht rausgefunden. Beide User haben auf das Attribut "msDS-AdditionalDnsHostName" Leserechte. Soweit ich das verstehe, sollte das doch ausreichen um mit dem oben genannten Befehl den SPN auszulesen. Schreibrechte auf das Attribut brauche ich ja nur, wenn ich den SPN mit dem User setzen will. Aber auch das Rechte hätte der User. Oder was für Voraussetzungen müssen noch gegeben sein, damit man den SPN auslesen kann? Vielen Dank Grüße

Haben jetzt den download mode auf 99 gestellt. Updates vom Teams Client funktionieren nun und auch die WSUS Anbindung scheint weiterhin wie gewohnt zu gehen. Danke Dir!

Hallo zusammen, ich habe mal eine kurze Frage zum Download Mode der Delivery Optimization Einstellung Aktuell nutzen wir den download mode 100 (Bypass) da wir keine Delivery Optimization benötigen und die Downloads über WSUS bereitgestellt werden. Dual Scan ist deaktiviert. Nun ist es so, dass der neue MS Teams Client über DO 100 keine Updates laden kann. Dqs wird auch bei MS so kommuniziert. https://learn.microsoft.com/en-us/microsoftteams/new-teams-bulk-install-client#prerequisites-for-target-computers Wir überlegen nun den MS Teams Client manuell über unser Client Management zu aktualisieren oder den DO Mode umzustellen. Bei MS habe ich dazu folgende Tabelle gefunden https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization-reference#download-mode So ganz schlau werde ich daraus aber noch nicht. Mode 100 verstehe ich ,hier wird BITS verwendet und keine Delivery Optimization. Mode 0 würde zwar peer-to-peer deaktiveren, aber trotzdem HTTP Anfragen zu MS durchführen Mode 99 deaktivert Delivery Optimization - also keine Kommunikation zu MS (so würde ich es verstehen), aber trotzdem wird gesagt ->In this mode, Delivery Optimization provides a reliable download experience over HTTP from the download's original source or a Microsoft Connected Cache server, with no peer-to-peer caching Ist das nicht ein Widerspruch? Einmal wird gesagt DO ist deaktiviert und dann wird erwähnt das DO wird in diesem Mode verwendet um aus der original Quelle Daten nachzuladen (das wäre dann ja MS oder wäre da mit der WSUS gemeint?) Was wir wolle ist einfach ein download der Updates über den WSUS ohne jegliche MS Konnektivität (so wie es jetzt mit Mode 100 funktioniert). Oder ist das mit den anderne Modi gar nicht möglich? Was hätte Mode 99 für einen weiteren Nachteil? Danke schon mal im Voraus. Grüße

Danke für den kurzen Erfahrungsbericht. Dann ist für uns LTSC auch erstmal raus. Wir setzen auch DELL Geräte ein und haben einige Schnittstellen die Treiber benötigen und einiges an Third-Party Software. Dazu kommt, dass wir nicht bei jedem Update von einer LTSC zur nächsten eine komplette Neuinstallation durchführen wollen. Da der LTSC Support ja auch von 10 auf 5 Jahre reduziert wurde, ist das auch kein großes Argument mehr. Mal abgesehen davon, dass es ja aktuell noch gar keine Win 11 LTSC gibt. Dann prüfen wir noch mal den genauen Unterschied zwischen Pro und Enterprise und werden dann wohl hier eine Entscheidung treffen. Danke für die Rückmeldung. Wir haben das schon mal durchgerechnet und uns die MS Pakete angeschaut. Natürlich können wir damit viel bisherige Services ablösen, die Frage ist nur - wollen wir wirklich alles über MS Produkte lösen (meine Meinung ist dazu - nein) - wer soll diese Migrationen durchführen (da bräuchte ich 1-2 zusätzliche Mitarbeiter die nur mit der Migration der Systeme beschäftigt sind - Mail Gateway, Patch Management, EMM/MDM, Endpoint, Project Management, usw). Das können wir aktuell nicht stemmen und zum anderen sind wir mit den Produkten auch nicht unzufrieden. Aber das ist ein anderes Thema :)

Hallo zusammen, wir planen aktuell die Migration zu Windows 11. Aktuell laufen bei uns alle Clients mit Windows 10 Pro 22H2. Die Frage die wir uns aktuell stellen ist, werden wir auch bei Windows 11 auf Pro gehen oder vielleicht doch auf Enterprise bzw. LTSC. Ich habe bei MS jetzt keinen direkten Vergleich von Pro und Enterprise gefunden. Ich habe mit jetzt mal an diesem Vergleich orientiert und da wäre jetzt der Aufpreis für Enterprise für uns nicht wirklich lohnenswert. https://www.xda-developers.com/windows-11-pro-vs-enterprise/ Es war zwar auch schon bei Win 10 so, dass einige GPOs nur mit Enterprise funktioniert haben, aber auch das konnten wir ganz gut abfedern. So wie ich es sehe, ist für uns einer der Hauptgründe die etwas längere Supportzeit. Enterprise 36 Monate Pro 24 Monate Die LTSC wäre dann ja noch mal länger im Support, richtig? Hier wären es dann 5 Jahre und die Windows Funktionen bleiben auf dem Stand des Releases und werden nicht wie bei Pro und Enterprise immer weiter aufgebläht. So wie ich das aber aktuell sehe, gibt es noch gar kein Windows 11 LTSC, dass soll wohl erst noch kommen. Was wir hier brauchen ist ein stabiles OS, ohne großen Schnickschnack wie Copilot, Windows Store, Wetter Apps usw. Kann man die Unterschiede grob so zusammenfassen? LTSC -> OS auf die wichtigsten Funktionen reduziert, langer support Enterprise -> OS kann etwas feiner per GPOs administriert werden als die Pro, größerer Funktionsumfang für Unternehmen, etwas längerer Support Pro -> OS mehr oder weniger wie in Consumer OS mit dem kürzesten Support Eine Frage hätte ich noch zur LTSC Version. Wie war das bei der Win 10 Version. Wenn ich einen Client auf Win 10 1809 LTSC hatte und wollte den dann auf Win 10 21H2 bringen. Konnte ich das einfach per InPlace Upgrade machen? Brauchte ich für das Update dann wieder eine neue Lizenz? Danke euch. Grüße, Steffen P.s. Abo Lizenen wie M365 E3 / E5 usw stehen bei uns aktuell nicht zur Debatte.

Interessant - das gleiche Problem haben wir immer mal wieder auch. Den RegKey werde ich mal ausprobieren. Danke Dir. Das Thema werde ich mal unseren Fortigate Kollegen geben. Danke!

Die "Wait for network" GPO haben wir eigentlich auf allen Clients aktiviert und diese greift auch für VPN Clients https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsLogon::SyncForegroundPolicy Wir sprechen ja von dieser GPO, richtig? Cloud joined ist bei uns nicht möglich, wir sind nicht in der Azure/EntraID Welt und werden das auch zeitnah nicht sein. Ob das jetzt gut oder schlecht ist würde ich hier gerne nicht diskutieren

Alles klar. Das heißt ein Großteil der VPN Lösungen ist davon betroffen, wenn die nicht bei der Anmeldung warten bis wirklich die VPN Verbindung steht und die DCs befragt werden können. Gut zu wissen. Ich werde beim Support mal nachfragen ob man hier irgendwie eine Verzögerung definieren kann. Danke für die Hilfe.

Uff...jetzt stehe ich irgendwie auf dem Schlauch. Aber MS sagt ja extra, wenn Gruppenmitgliedschaften bei einer VPN Verbindung nicht aktualisiert werden, soll man die VPN Verbindung vor dem Login aufbauen. Das wäre, nach meinen Verständnis, ja bei uns gegeben, da der FortiClient erst die VPN Verbindung aufbaut und dann die Windows Anmeldung durchführt. Wenn ich dich jetzt aber richtig verstehe, ist aber auch in dieser Konstellation (da die Anmeldung zu schnell nach der VPN Verbindung hergestellt wird) der Fehler nicht wirklich gelöst. Man müsste somit erst eine VPN Verbindung aufbauen, kurz warten und dann die Windows Anmeldung durchführen, richtig? Wenn ich dich also richtig verstehe, gibt es keine wirklich Lösung für das Problem? Außer man sperrt den Bildschirm nach der Anmeldung, entsperrt den Bildschirm und meldet sich ab und wieder an. Das hatte bei uns zumindest geholfen.

Danke für den Tipps und Hilfestellungen. Wir beobachten das Verhalten jetzt erstmal weiter. Möglicherweise ist es wirklich nur das Verhalten bzw. die Trägheit von whoami /groups.

Hi Nils das ist bzw. war auch meine Vermutung und das versuche ich gerade mit dem Support rauszufinden. Allerdings bin ich jetzt doch noch mehr verwirrt. Bei den letzten 2 Tests hat es jetzt plötzlich funktioniert. Neue AD Gruppe erstellt. Meinen User hinzugefügt Von Windows abgemeldet und Anmeldung inkl SSL VPN whoami /groups hat jetzt dann die neue Gruppe angezeigt puh....gibt es irgendeine Einstellung mit der definiert wird, wie lange die Verbindung zum DC dauern darf bis eine zwischengespeicherte Anmeldung verwendet wird? Meine Vermutung ist, dass vielleicht manchmal die Connection einfach etwas zu langsam ist und der Client (trotz bestehender DC Verbindung) meint er ist offline. Gruß, Steffen Edit: Ein kurzer Nachtrag. bei dem command whoami /groups werden Gruppen unterschiedlich dargestellt einige Gruppen sind als "Typ" Gruppe angegeben und einige als "Alias" und werden bei den Gruppen als "Lokale Gruppe" angezeigt. So z.B. auch meine Test Gruppe die dem User schon längst entzogen wurde. Aber auch andere Domänen Gruppen werden als "Alias" und "Lokale Gruppe" angezeigt. Andere Domain Gruppen werden eben als "Gruppe" und ohne "Lokale Gruppe" angezeigt. Ist das normal bzw. was ist hier der Unterschied? Heißt das Attribut "Lokale Gruppe" wirklich, dass der Client diese Gruppen als lokale Gruppe ansieht und nicht als AD Gruppe?

Hi Martin, da war ich dann etwas ungenau - stimmt. Die Anmeldung am SSL VPN findet vor der Windows Anmeldung statt. Wir wählen im Login Screen die "Anmeldeoptionen" aus und dort gibt es den FortiClient zur Auswahl. Die User melden sich mit ihren AD Login, es wird die SSL VPN Verbindung aufgebaut und es erfolgt die Abfrage vom 2Faktor. Erst danach wird die Windows Anmeldung durchgeführt. Mir ist daher schleierhaft warum die Gruppenmitgliedschaft nicht aktualisiert wird. Auch verwenden wir bei den VPN Sessions keine anderen GPOs. Alles identisch zum LAN. Einzig beim VPN Login wird als Post Action ein "gpupdate" durchgeführt. Aber das dürfte ja kein Problem darstellen, oder doch? Wenn ich dann eben den Bildschirm mit STRG+L sperre, wieder entsperre, danach mich von Windows abmelde und neu inkl. VPN anmelde, ist die Gruppe auch aktualisiert. Bin etwas ratlos an was das liegen könnte. Gibt es irgendwelche Einstellungen in Windows die so ein Verhalten erklären könnten?

Hallo zusammen, Wir haben ein kleines Problem bei unserem vpn login. Wir nutzen forticlient für den ssl vpn. Die Verbindung wird mit bzw vor der Windows Anmeldung ausgeführt. Soweit funktioniert das auch gut. Nur ist uns jetzt aufgefallen, dass neue Gruppenmitgliedschaften nicht übernommen werden. Dies passiert nur, wenn der Client direkt im LAN ist. Sieht also wie folgt aus. User ist im vpn oder offline. Wir fügen den User in eine neue ad Gruppe hinzu. User baut neue vpn Verbindung auf bzw meldet sich bei bestehender Verbindung ab und meldet sich neu an Windows an und baut dabei auch die vpn Verbindung neu auf. Whomai /groups zeigt weiterhin die Gruppe nicht an. Meldet sich der User an einem Client im LAN neu an, wird die Gruppe gleich übernommen. Ich vermute, dass irgendwie zwischengespeicherte Infos verwendet werden. Wenn der User im vpn dann den Bildschirm sperrt, entsperrt und dann neu anmeldet, wird die Gruppe auch übernommen ( wird von ms im unten genannten link als workaround genannt). Bin mit dem Fortinet Support noch drüber das zu analysieren. Aber aktuell sagen die, es liegt an unseren clients. Kann man beim login irgendwie forcieren, dass die Gruppen neu ausgelesen werden und nicht zwischengespeicherte Infos verwendet werden? Ich hatte folgenden ms Artikel gefunden https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/group-membership-changes-not-updating-over-some-vpn-connections Dieser beschreibt genau unsere Problem, aber wir bauen schon die von connection mit der Windows Anmeldung auf. Würde es vielleicht schon ausreichen ein klist purge beim vpn login mitzugeben, damit die Gruppen neu eingelesen werden? Für Ideen wäre ich sehr dankbar. Liebe Grüße

Hi sunny, Vielen Dank für die ausführlichen Infos und die Mühe das zusammenzutragen!! Ich bin auch etwas blöde und hab den Wald vor lauter Bäumen nicht gesehen. Ich habe für das PRTG monitoring schon eine Gruppe für die wmi/dcom Berechtigung erstellt und diese dann immer manuell für wmi berechtigt, damit wir dafür keine Admin Berechtigung benötigt wird. Die Infos helfen mir aber noch um das zu automatisieren und um das Ganze noch besser zu verstehen.

Hi sunny61, das wäre ja wundervoll. Ich hatte nur diese whitepaper bei docusnap selber gefunden. Dort werden die notwendigen Berechtigungen für die Inventarisierung aufgelistet. https://media.docusnap.com/media/doc/howto/Docusnap_Whitepaper_Docusnap-Inventarisierung.pdf Dort ist z.b. bei der windows Inventarisierung erwähnt das es lokale Admin Rechte braucht. Bei exchange oder dhcp wird sogar von Domänen Amin Rechten gesprochen. Bei uns läuft aktuell der Docusnap Server Dienst mit einem AD Service Account der entweder lokale Admin auf den entsprechenden Servern ist. Wenn ich das, wie du schreibst anpassen kann, wäre das eine weitere Lösung. Vielen Dank und ein schönes Wochenende

Hallo zusammen, wir setzen bei uns Docusnap zum Inventarisieren und Dokumentieren der IT Landschaft ein bzw. sind dabei es noch weiter zu implementieren. Aktuell ist es so, dass die Inventarisierung der AD, DHCP, Server, Exchange, Veeam, SQL usw. über den Docusnap Server laufen. Das heißt dort ist ein Service Account hinterlegt der dann zusätzlich auf allen zu inventarisierenden Servern lokaler Admin ist. Diese lokalen Adminrechte werden laut Docusnap oft einfach benötigt. Dort wo es nicht notwendig ist, sind die Rechte granular vergeben. -> gefällt mir aktuell nicht so gut, da ein einzelner Service Account doch sehr weitreichende Berechtigungen auf mehreren Servern hat. Nun gibt es auch die Möglichkeit die Inventarisierung über ein Script laufen zu lassen, dass wird dann lokal auf dem jeweiligen Server ausgeführt und das Ergebnis (eine XML Datei) wird dann auf einen Share abgelegt und vom Docusnap Server eingelesen. -> würde mir besser gefallen. Ich würde für jeden Server einen eigenen AD Service Account erstellen. Dieser wird mit unserer bestehenden GPO dann in die lokale Admin Gruppe des jeweiligen Servers mit aufgenommen. Somit könnte ein Scheduled Task auf jedem Server laufen, der mit dem jeweiligen Service Account ausgeführt wird und die XML Datei erstellt und im Share ablegt. Vorteil wäre, ich habe nicht mehr einen Account der auf mehreren Servern gleichzeitig lokaler Admin ist. Wie würdet ihr das sehen? Macht der Aufwand Sinn oder macht der Aufwand wenig Sinn, wenn man grundsätzlich kein Tiering Modell oder ähnliches nutzt? Ich kann natürlich nicht unser komplettes Sicherheitskonzept hier erklären und mir ist auch klar das ihr deswegen keine 100% Aussage treffen könnt, aber mich würde mal interessieren ob der grundsätzliche Denkansatz in die richtige Richtung geht oder ob ich mich hier im "Klein Klein" verliere. Grobe Info zu unserem Sicherheitskonzept der Admin Accounts - Niemand hat zusätzliche Domänen Admin Rechte und der default DA ist deaktiviert und hat auch auf Member Server / Clients kein Zugriff - die bestehenden DA Accounts werden nur für die Tätigkeiten in der AD genutzt, wozu DA Rechte notwendig sind - für die IT gibt es getrennte Client und Server Admins und die Anmeldung ist an den jeweils anderen System unterbunden - kein "normaler User" hat Adminrechte oder einen Admin Account - Default Admin auf den Servern ist deaktiviert und jeder Server hat einen eigenen lokalen Admin mit unterschiedlichen Kennwort - Es gibt fast keine Service Sammelaccounts mehr, jeder Service Account wird einer Aufgabe zugeordnet und danach benannt - LAPS leider noch nicht aktiv Vielen Dank.

Wenn ich es richtig verstehe, müsste man WinRE ja deaktivieren, damit die Sicherheitslücke nicht ausgenutzt werden kann. Ich bin nun davon ausgegangen, wenn keine Wiederherstellungspartition vorhanden ist, kann auch WinRE nicht aktiv sein. Laut Reagentc /info ist es das aber. Bei administrator.de hat jemand ein Script geschrieben, damit man WinRE deaktivieren kann. Werde mir das mal genauer anschauen. Oder wie deaktiviert ihr das WinRE?

Hallo zusammen, Microsoft hat mal wieder ganze Arbeit beim Patch day geleistet. Das Update KB5034441 schlägt mit dem Fehler 0x80070643 fehl, wenn die Wiederherstellungspartition zu klein ist. Dazu kommt noch, dass es wohl in der von Microsoft genannten Anleitung zum vergrößern der Partition Fehler gibt (habe ich selber noch nicht geprüft). Das Ganze sieht mal wieder etwas nach Chaos aus. Mir gparted oder ähnlichen Tools kann ich das ja an einzelnen clients anpassen und die partition vergrößern, aber bei 100 oder mehr clients ist das doch Wahnsinn. Wie löst ihr das Problem, falls ihr davon betroffen seid? Da mit dem Update ja eine Bitlocker Sicherheitslücke geschlossen wird, ist das Update wichtig und kann nicht einfach ignoriert werden. Ich habe mal ein paar Clients bei uns geprüft. Einige haben gar keine Wiederherstellungspartition bei anderen ist sie 500mb bis 700mb groß. Da wir die Geräte imagen, ist es mir aktuell noch ein Rätsel warum es da Unterschiede gibt🤔 Das Update werden wir morgen mal auf test Clients einspielen. Hier noch die Quellen https://www.deskmodder.de/blog/2024/01/09/windows-10-kb5034441-winre-update-als-sicherheitsupdate-kann-fehler-0x80070643-ausloesen/#comments https://www.heise.de/news/Patchday-Microsoft-Kerberos-Authentifizierung-unter-Windows-verwundbar-9592648.html Grüße