7
Denkfehler bei GPO-Delegierung?
Hallo,
wer meine letzten beiden Themen verfolgt weiß, dass ich grade auf der Suche nach einer Möglichkeit bin, einen Besprechungsrechner so weit wie möglich zu begrenzen, dass hier "nur" RDP möglich ist. Da ich an der Stelle nicht weiter gekommen bin, wollte ich nun die Absicherung Gruppenrichtlinien vornehmen. Da ein Teil der Gruppenrichtlinien vom Benutzer abhängig ist (Beispielsweise das Laufwerks- und/oder Druckermapping), so wie einige Einstellungen NUR an dem PC aber nicht an anderen PCs gelten sollen habe ich zunächst nur für diesen einen Rechner den Loopback-Verarbeitungsmodus aktiviert und eine GPO gebaut, die an diesem Rechner bestimmte Einstellungen vornimmt.
Es sieht nun so aus:
1. Eine Gruppenrichtlinie die den Loopback aktiviert (ersetzen), Sicherheitsfilter der Besprechungsraurechner.
2. Eine Gruppenrichtlinie Besprechungsraum, Sicherheitsfilter Besprechungsraumrechner und Domänen-Benutzer
Beide Gruppenrichtlinien liegen in der OU für die Unternehmensclients.
Fazit: Es funktioniert Die in der zweiten GPO eingestellten Benutzer-Konfigurationen werden erfolgreich ausgeführt.
Das sah/sieht schonmal gut aus. Aber es müssen noch ein paar andere Dinge weg. Netzlaufwerke und Drucker werden hier nicht gebraucht. Also habe ich unter Delegierung folgendes eingetragen:
Besprechungsrechner -> erweitert -> Gruppenrichtlinie übernehmen -> verweigern
Mein Gedankengang war, dass damit die Netzlaufwerke und Drucker nicht bei der Anmeldung an diesem Rechner verbunden werden. Werden Sie allerdings dennoch. Frage an der Stelle: Habe ich hier einen Denkfehler? Ich bin davon ausgegangen, wenn ich einen Computer hier den Zugriff verweigere, dann wird das nicht ausgeführt oder gilt das Verweigern nur für den Teil der Computerkonfiguration? Beide Gruppenrichtlinien liegen im direkten Domänen-Pfad und werde Domänenweit ausgeführt. Bei diesen beiden könnte ich natürlich in der Zielgruppenadressierung noch einen Filter setzen, aber den müsste ich dann ja bei jedem Laufwerk und jedem Drucker einfügen. Es gibt aber noch weitere die in der OU der Mitarbeiter stehen.
Ich könnte auch einen WMI Filter auf die GPO legen, die dann diesen einen Rechner ausschließt, aber WMI Filter bremsen immer so und darauf würde ich gerne verzichten.
Daher jetzt nochmal klar die Frage: Wie muss ich eine Delegierung konfigurieren, damit eine Gruppenrichtlinien die in der OU Mitarbeiter Benutzerkonfigurationen definiert auf einem Client in der OU Clients diese Benutzerkonfigurationen bei der Anmeldung eines Mitarbeiters nicht übernimmt?
Gruß
Doskias
wer meine letzten beiden Themen verfolgt weiß, dass ich grade auf der Suche nach einer Möglichkeit bin, einen Besprechungsrechner so weit wie möglich zu begrenzen, dass hier "nur" RDP möglich ist. Da ich an der Stelle nicht weiter gekommen bin, wollte ich nun die Absicherung Gruppenrichtlinien vornehmen. Da ein Teil der Gruppenrichtlinien vom Benutzer abhängig ist (Beispielsweise das Laufwerks- und/oder Druckermapping), so wie einige Einstellungen NUR an dem PC aber nicht an anderen PCs gelten sollen habe ich zunächst nur für diesen einen Rechner den Loopback-Verarbeitungsmodus aktiviert und eine GPO gebaut, die an diesem Rechner bestimmte Einstellungen vornimmt.
Es sieht nun so aus:
1. Eine Gruppenrichtlinie die den Loopback aktiviert (ersetzen), Sicherheitsfilter der Besprechungsraurechner.
2. Eine Gruppenrichtlinie Besprechungsraum, Sicherheitsfilter Besprechungsraumrechner und Domänen-Benutzer
Beide Gruppenrichtlinien liegen in der OU für die Unternehmensclients.
Fazit: Es funktioniert Die in der zweiten GPO eingestellten Benutzer-Konfigurationen werden erfolgreich ausgeführt.
Das sah/sieht schonmal gut aus. Aber es müssen noch ein paar andere Dinge weg. Netzlaufwerke und Drucker werden hier nicht gebraucht. Also habe ich unter Delegierung folgendes eingetragen:
Besprechungsrechner -> erweitert -> Gruppenrichtlinie übernehmen -> verweigern
Mein Gedankengang war, dass damit die Netzlaufwerke und Drucker nicht bei der Anmeldung an diesem Rechner verbunden werden. Werden Sie allerdings dennoch. Frage an der Stelle: Habe ich hier einen Denkfehler? Ich bin davon ausgegangen, wenn ich einen Computer hier den Zugriff verweigere, dann wird das nicht ausgeführt oder gilt das Verweigern nur für den Teil der Computerkonfiguration? Beide Gruppenrichtlinien liegen im direkten Domänen-Pfad und werde Domänenweit ausgeführt. Bei diesen beiden könnte ich natürlich in der Zielgruppenadressierung noch einen Filter setzen, aber den müsste ich dann ja bei jedem Laufwerk und jedem Drucker einfügen. Es gibt aber noch weitere die in der OU der Mitarbeiter stehen.
Ich könnte auch einen WMI Filter auf die GPO legen, die dann diesen einen Rechner ausschließt, aber WMI Filter bremsen immer so und darauf würde ich gerne verzichten.
Daher jetzt nochmal klar die Frage: Wie muss ich eine Delegierung konfigurieren, damit eine Gruppenrichtlinien die in der OU Mitarbeiter Benutzerkonfigurationen definiert auf einem Client in der OU Clients diese Benutzerkonfigurationen bei der Anmeldung eines Mitarbeiters nicht übernimmt?
Gruß
Doskias
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator tomolpi am 26.10.2020 um 17:28:38 Uhr
Typo im Titel korrigiert
Content-ID: 616443
Url: https://administrator.de/forum/denkfehler-bei-gpo-delegierung-616443.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
7 Kommentare
Neuester Kommentar
Moin 
Ich stehe da gerade vlt. ein wenig auf dem Schlauch...
Wenn Du die Übernahme der GPO verweigerst, wird die GPO nicht angewendet. Wieso sollte dann irgendetwas überhaupt passieren?
das gilt für die Übernahme der Richtlinie auf dem System. Und wenn der Computer sie nicht übernimmt, wird sie auch nicht für Benutzer übernommen. Wenn du die "Authentifizierten Benutzer" entfernst, wirst du immer extra darauf hingewiesen, dass auch für die Benutzerkonfiguration der Computer die Richtlinie lesen und übernehmen können muss.
s.o. - weil gleiches Ergebnis...
Loopbackverarbeitung mit "Ersetzen"
Gruß
Zitat von @Doskias:
Das sah/sieht schonmal gut aus. Aber es müssen noch ein paar andere Dinge weg. Netzlaufwerke und Drucker werden hier nicht gebraucht. Also habe ich unter Delegierung folgendes eingetragen:
Besprechungsrechner -> erweitert -> Gruppenrichtlinie übernehmen -> verweigern
Mein Gedankengang war, dass damit die Netzlaufwerke und Drucker nicht bei der Anmeldung an diesem Rechner verbunden werden.
Das sah/sieht schonmal gut aus. Aber es müssen noch ein paar andere Dinge weg. Netzlaufwerke und Drucker werden hier nicht gebraucht. Also habe ich unter Delegierung folgendes eingetragen:
Besprechungsrechner -> erweitert -> Gruppenrichtlinie übernehmen -> verweigern
Mein Gedankengang war, dass damit die Netzlaufwerke und Drucker nicht bei der Anmeldung an diesem Rechner verbunden werden.
Ich stehe da gerade vlt. ein wenig auf dem Schlauch...
Wenn Du die Übernahme der GPO verweigerst, wird die GPO nicht angewendet. Wieso sollte dann irgendetwas überhaupt passieren?
oder gilt das Verweigern nur für den Teil der Computerkonfiguration?
das gilt für die Übernahme der Richtlinie auf dem System. Und wenn der Computer sie nicht übernimmt, wird sie auch nicht für Benutzer übernommen. Wenn du die "Authentifizierten Benutzer" entfernst, wirst du immer extra darauf hingewiesen, dass auch für die Benutzerkonfiguration der Computer die Richtlinie lesen und übernehmen können muss.
Ich könnte auch einen WMI Filter auf die GPO legen, die dann diesen einen Rechner ausschließt, aber WMI Filter bremsen immer so und darauf würde ich gerne verzichten.
s.o. - weil gleiches Ergebnis...
Daher jetzt nochmal klar die Frage: Wie muss ich eine Delegierung konfigurieren, damit eine Gruppenrichtlinien die in der OU Mitarbeiter Benutzerkonfigurationen definiert auf einem Client in der OU Clients diese Benutzerkonfigurationen bei der Anmeldung eines Mitarbeiters nicht übernimmt?
Loopbackverarbeitung mit "Ersetzen"
Gruß
Moin,
das ist schon der richtige Weg mit der Loopback-Verarbeitung mit Ersetzen. Aber dadurch überschreibst Du nur die GPOs der Benutzer. Die der Clients bleiben erhalten. Deshalb würde ich so vorgehen:
1. Der Rechner kommt in eine eigene OU.
2. Für diese OU wird die Vererbung unterbrochen und nur die DDP verknüpft. Dann bist Du sicher, dass keine andere GPO mehr auf den Rechner wirkt.
3. Es wird eine GPO erstellt, in der die entsprechenden Einstellungen vorgenommen werden. Hier wird auch die Loopback-Verarbeitung eingestellt.
Wenn dann noch unerwünschte LWe verbunden werden, dann werden sie nicht über GPOs, sondern über Login-Skripts eingerichtet.
hth
Erik
das ist schon der richtige Weg mit der Loopback-Verarbeitung mit Ersetzen. Aber dadurch überschreibst Du nur die GPOs der Benutzer. Die der Clients bleiben erhalten. Deshalb würde ich so vorgehen:
1. Der Rechner kommt in eine eigene OU.
2. Für diese OU wird die Vererbung unterbrochen und nur die DDP verknüpft. Dann bist Du sicher, dass keine andere GPO mehr auf den Rechner wirkt.
3. Es wird eine GPO erstellt, in der die entsprechenden Einstellungen vorgenommen werden. Hier wird auch die Loopback-Verarbeitung eingestellt.
Wenn dann noch unerwünschte LWe verbunden werden, dann werden sie nicht über GPOs, sondern über Login-Skripts eingerichtet.
hth
Erik
Zitat von @Hubert.N:
Ich stehe da gerade vlt. ein wenig auf dem Schlauch...
Wenn Du die Übernahme der GPO verweigerst, wird die GPO nicht angewendet. Wieso sollte dann irgendetwas überhaupt passieren?
Ich stehe da gerade vlt. ein wenig auf dem Schlauch...
Wenn Du die Übernahme der GPO verweigerst, wird die GPO nicht angewendet. Wieso sollte dann irgendetwas überhaupt passieren?
Weil ich nicht nur eine GPO habe sondern mehrere. Wenn cih eine Verweigere, die die Benutzerdrucker mappt, dann wird immernoch die ausgeführt, die ich speziell für diesen einen Rechner (mit dem Drucker im Raum) erstellt habe
oder gilt das Verweigern nur für den Teil der Computerkonfiguration?
das gilt für die Übernahme der Richtlinie auf dem System. Und wenn der Computer sie nicht übernimmt, wird sie auch nicht für Benutzer übernommen. Wenn du die "Authentifizierten Benutzer" entfernst, wirst du immer extra darauf hingewiesen, dass auch für die Benutzerkonfiguration der Computer die Richtlinie lesen und übernehmen können muss.
Ich könnte auch einen WMI Filter auf die GPO legen, die dann diesen einen Rechner ausschließt, aber WMI Filter bremsen immer so und darauf würde ich gerne verzichten.
s.o. - weil gleiches Ergebnis...nein leider nicht. Delegierung verbieten funktioniert nicht. WMI-Filter funktioniert.
Daher jetzt nochmal klar die Frage: Wie muss ich eine Delegierung konfigurieren, damit eine Gruppenrichtlinien die in der OU Mitarbeiter Benutzerkonfigurationen definiert auf einem Client in der OU Clients diese Benutzerkonfigurationen bei der Anmeldung eines Mitarbeiters nicht übernimmt?
Loopbackverarbeitung mit "Ersetzen"
Siehe oben. Das ist schon der Fall. Das Problem ist allerdings folgendes (bei den Netzlaufwerken. Sie werden als Benutzer Domainweit gemappt und es gibt keine Konfiguration für Netzlaufwerke auf "Besprechungsraum"-Ebene. Daher führt ersetzen folglich zu nichts. Es gibt ja nichts was ersetz werden kann. Natürlich kann ich die Netzlaufwerke auch wieder löschen, aber dann hab ich in der Verarbeitungsreihenfolge erst die GPO die das Domainweit hinzufügt und dann die die es wieder entfernt. Das sind zwei unnötige, da sich aufhebende Konfigurationen, die zu nichts weiter führen als die Anmeldung unnötig zu verlangsamen. Dann kann ich auch mit WMI Filtern arbeiten.
Gruß
Zitat von @erikro:
das ist schon der richtige Weg mit der Loopback-Verarbeitung mit Ersetzen. Aber dadurch überschreibst Du nur die GPOs der Benutzer. Die der Clients bleiben erhalten.
das ist schon der richtige Weg mit der Loopback-Verarbeitung mit Ersetzen. Aber dadurch überschreibst Du nur die GPOs der Benutzer. Die der Clients bleiben erhalten.
Das ist durchaus richtig. Ein Großteil der Computer-Einstellungen sollen auch erhalten bleiben. WSUS-Updates, Virenscanner definitionen, Proxy Eisntellungen, Deaktivierung von Wechsellaufwerken, etc.. Das alles soll ja erhalten bleiben. Es müssen nur einige Eisntellungen beim Benutzer angepasst werden.
Deshalb würde ich so vorgehen:
1. Der Rechner kommt in eine eigene OU.
2. Für diese OU wird die Vererbung unterbrochen und nur die DDP verknüpft. Dann bist Du sicher, dass keine andere GPO mehr auf den Rechner wirkt.
3. Es wird eine GPO erstellt, in der die entsprechenden Einstellungen vorgenommen werden. Hier wird auch die Loopback-Verarbeitung eingestellt.
1. Der Rechner kommt in eine eigene OU.
2. Für diese OU wird die Vererbung unterbrochen und nur die DDP verknüpft. Dann bist Du sicher, dass keine andere GPO mehr auf den Rechner wirkt.
3. Es wird eine GPO erstellt, in der die entsprechenden Einstellungen vorgenommen werden. Hier wird auch die Loopback-Verarbeitung eingestellt.
Die Idee mit der deaktivieren Vereerbung werde ich mir mal durch den Kopf gehen lassen. Dann muss ich die oben genannten GPOs halt doppelt verknüpfen. MS empfiehlt (und so habe ich es bislang auch in den Systemhäusern immer gehandhabt), dass es eine GPO gibt, die nichts macht als den Loopback-Verarbeitungsmodus zu aktivieren. Dadurch bleibt es immer schön übersichtlich zu erkennen, wo der Loopbackmodus aktiviert ist und wo nicht.
Wenn dann noch unerwünschte LWe verbunden werden, dann werden sie nicht über GPOs, sondern über Login-Skripts eingerichtet.
Danke für den Hinweis. Wir haben noch einige Logon-Skripte aktiv, aber nicht bei dem user wo das Problem heute in der Teststellung aufgefallen ist.
Gruß
Doskias
Zitat von @Doskias:
Das ist durchaus richtig. Ein Großteil der Computer-Einstellungen sollen auch erhalten bleiben. WSUS-Updates, Virenscanner definitionen, Proxy Eisntellungen, Deaktivierung von Wechsellaufwerken, etc.. Das alles soll ja erhalten bleiben. Es müssen nur einige Eisntellungen beim Benutzer angepasst werden.
Zitat von @erikro:
das ist schon der richtige Weg mit der Loopback-Verarbeitung mit Ersetzen. Aber dadurch überschreibst Du nur die GPOs der Benutzer. Die der Clients bleiben erhalten.
das ist schon der richtige Weg mit der Loopback-Verarbeitung mit Ersetzen. Aber dadurch überschreibst Du nur die GPOs der Benutzer. Die der Clients bleiben erhalten.
Das ist durchaus richtig. Ein Großteil der Computer-Einstellungen sollen auch erhalten bleiben. WSUS-Updates, Virenscanner definitionen, Proxy Eisntellungen, Deaktivierung von Wechsellaufwerken, etc.. Das alles soll ja erhalten bleiben. Es müssen nur einige Eisntellungen beim Benutzer angepasst werden.
Verständlich. Dann würde ich erstmal das machen, wie ich es vorgeschlagen habe. Dann testen, ob die unerwünschten LWe und Drucker weg sind. Wenn ja, nach und nach die anderen erwünschten GPOs verknüpfen und jedes Mal testen.
Die Idee mit der deaktivieren Vereerbung werde ich mir mal durch den Kopf gehen lassen. Dann muss ich die oben genannten GPOs halt doppelt verknüpfen. MS empfiehlt (und so habe ich es bislang auch in den Systemhäusern immer gehandhabt), dass es eine GPO gibt, die nichts macht als den Loopback-Verarbeitungsmodus zu aktivieren. Dadurch bleibt es immer schön übersichtlich zu erkennen, wo der Loopbackmodus aktiviert ist und wo nicht.
Früher galt die Regel: Wenn Microsoft was empfiehlt, mache das Gegenteil.
Ich tendiere dazu, möglichst nur ein GPO-Objekt mt einer OU zu verknüpfen, weil es dann schön übersichtlich bleibt, was da direkt drauf wirkt. Das ist wahrscheinlich aber eher Geschmackssache.Wenn dann noch unerwünschte LWe verbunden werden, dann werden sie nicht über GPOs, sondern über Login-Skripts eingerichtet.
Danke für den Hinweis. Wir haben noch einige Logon-Skripte aktiv, aber nicht bei dem user wo das Problem heute in der Teststellung aufgefallen ist.
Was mir noch dazu einfällt: Wenn Du die Laufwerke persistent eingebunden hast, dann bleiben die so lange, bis Du sie wieder explizit trennst. Das könnte auch ein Grund dafür sein, dass sie nicht verschwinden, obwohl die GPO nicht mehr da ist.
Guten Morgen
Nun habe ich Dein Problem auch endlich so wirklich verstanden
Du solltest Dir mal Gedanken zum grundsätzlichen Design deiner Richtlinien machen. Hättest Du dir initial nur ein wenig mehr Arbeit gemacht und die OUs besser strukturiert und die Benutzerrichtlinien nicht einfach global auf die gesamte Domäne gelegt, dann hättest Du diese Probleme erst gar nicht.
Gruß
Nun habe ich Dein Problem auch endlich so wirklich verstanden
Du solltest Dir mal Gedanken zum grundsätzlichen Design deiner Richtlinien machen. Hättest Du dir initial nur ein wenig mehr Arbeit gemacht und die OUs besser strukturiert und die Benutzerrichtlinien nicht einfach global auf die gesamte Domäne gelegt, dann hättest Du diese Probleme erst gar nicht.
Gruß
Zitat von @Hubert.N:
Guten Morgen
Nun habe ich Dein Problem auch endlich so wirklich verstanden
Du solltest Dir mal Gedanken zum grundsätzlichen Design deiner Richtlinien machen. Hättest Du dir initial nur ein wenig mehr Arbeit gemacht und die OUs besser strukturiert und die Benutzerrichtlinien nicht einfach global auf die gesamte Domäne gelegt, dann hättest Du diese Probleme erst gar nicht.
Gruß
Guten Morgen
Nun habe ich Dein Problem auch endlich so wirklich verstanden
Du solltest Dir mal Gedanken zum grundsätzlichen Design deiner Richtlinien machen. Hättest Du dir initial nur ein wenig mehr Arbeit gemacht und die OUs besser strukturiert und die Benutzerrichtlinien nicht einfach global auf die gesamte Domäne gelegt, dann hättest Du diese Probleme erst gar nicht.
Gruß
Wir haben eine Struktur und an der Optimierung arbeite ich noch. Aber wenn man neu im Unternehmen ist, dann kann man nicht einfach alles was sich in 20 Jahren entwickelt hat von jetzt auf gleich umwerfen. Einige Dinge greifen auf OUs zurück und bevor ich nicht alles richtig verstanden habe, wird da nicht dran rumgefummelt. Aber:
Es sind "nur" 4 GPOs die Domainweit gemappt sind von der Default Domain Policy abgesehen. Diese sind:
- Bei Anmeldung aufs Netzwerkwarten: ist da sinnvoll, da es überall greifen soll und muss so nicht bei jeder OU händisch hinzugenommen werden
- WINRM Dienst aktivieren und Zugriff nur von bestimmten IPs zulassen. ist auch da sinnvoll, damit es nicht in jeder OU gepflegt werden muss
- Druckermapping: Da wir zu Übersicht nur eine Druckermapping GPO haben liegt die hier. Die Drucker werden dann über die Zielgruppenadressierung an die User Verteilt die sich in entsprechenden Berechtigungsgruppen befinden. Warum liegt die GPO hier und nicht bei den Usern. Es erden sowohl die Drucker verteilt (Benutzerkonfiguration) als auch die Server mitgegeben von denen Druckertreiber installiert werden dürfen (Computerkonfiguration). Wenn ich die GPO in die OU der User lege, so wird der Computer-Teil nicht mehr ausgeführt bzw. in den OUs der Rechner/Server das Mapping bei den Usern nicht mehr durchgeführt. Hier müsste man dann die GPO in 2 Trennen um sie hier wegzubekommen.
- Netzlaufwerksmapping. Die liegt hier, weil wir die OUs Strukturiert haben. Wir haben Mitarbeiter, Admins, Serviceaccounts. alles in eigenen OUs aber nur eine GPO die die Netzlaufwerke mappt. Auch hier gilt wieder die Zuordnung über eine Zielgruppenadressierung und damit es nicht in jeder OU verknüpft werden muss liegt es hier.
Alles anderen GPOs liegen in den entsprechenden OUs und sind da gut Strukturiert. Nur: Selbst wenn ich die GPOs nun trenne und mehrfach verbinde, würde das nichts ändern. Der User bekommt weiterhin das Netzlaufwerk gemappt. Egal ob auf Domain oder OU Ebene (habe ich nämlich schon probiert). Und bei den Druckern.
Die Struktur sieht so aus:
Domain -> OU Clients -> OU Standort 1
Domain -> OU Clients -> OU Standort 1 -> OU Besprechungsraum
Domain -> OU Clients -> OU Standort 2
Domain -> OU Clients -> OU Standort 3
Derzeit liegen die Drucker auf Domäneneben. Schieb ich es auf OU Clients ändert sich nicht. Schieb ich Es auf die OU Standort würde sich immer noch nichts ändern. Ändern würde sich das nur, wenn ich für den Besprechungsraum eine eigene OU einbaue, was dann so aussieht:
Domain -> OU Clients -> OU Standort 1
Domain -> OU Clients -> OU Standort 1 Besprechungsraum
Domain -> OU Clients -> OU Standort 2
Domain -> OU Clients -> OU Standort 3
und dann die Mappings von der Domäne in die jeweiligen OU Standorte schiebe. Dann hab ich aber eine OU in der nur ein Client ist und die immer noch die gleichen Benutzerkonfigurationen lädt (bis auf die Drucker) die unter beispielsweise Domain -> MA -> MA Standort 1. Das würde ich ja nur dann lösen könne, wenn ich die Mitarbeiter neu sortiere, aber da sich die Mitarbeiter sowohl am Standort als auch im Besprechungsraum anmelden sollen, macht hier eine Trennung ja keinen Sinn.
Ich hab jetzt, wie oben beschrieben eine neue OU am Standort für den Besprechungsraum angelegt und hier wie von Erikro vorgeschlagen die Vererbung deaktiviert. Dadurch werden sämtliche Benutzer-GPOs kategorisch abgelehnt, egal ob auf Domain- oder OU MA- Ebene. Jetzt muss ich nur noch die GPOs die hier greifen sollen hinzufügen und dann kann ich in den Test gehen.
Lösungsmarkierungen erfolgen dann später
