diff --git a/rhel8/kerberos.md b/rhel8/kerberos.md
index e095c559..b22c1bc2 100644
--- a/rhel8/kerberos.md
+++ b/rhel8/kerberos.md
@@ -227,6 +227,17 @@ Maybe we can try to create a solution with `KEYRING` which isolates the interact
 
 For the listed use cases above the caches and tickets do not need to survive reboots. If there is something/someone needing `KCM` for some reason, it can be used specifically and privately and will not interfer with the rest of the system.
 
+### How to deal with Systemd --user ?
+The `systemd --user` process is started at the beginning of the first session and ends at the end of the last session. And some desktop environments depend heavily on it.
+
+It might be that "Start of PAM" is good enough, but I expect follwoing problem:
+If `systemd --user` is started with ssh or a previous desktop session, the password entry at the desktop login might not update the TGT as PAM is operating on a different cache.
+The following might create a solution which might isolate the ssh sessions with individual caches and have one cache for `systemd --user` and all desktop sessions:
+The PAM configuration for ssh use a random fixed "Start of PAM" cache, where as for `systemd --user` and the display managers (`gdm` and `lightdm`) the PAM configuration is different as the "Start of PAM" cache is always the same and well known, e.g. `KCM:$UID:systemd--user`.
+
+I figured out that it is possble to inject environment variables into `systemd --user` with `systemctl --user import-environment` or `systemctl --user set-environment`, but that then affects only newly started software.
+Only experiments would show if this is good enought or if some important processes live longer than the desktop session.
+
 ### Red Hat Ticket
 I have an [ticket](https://access.redhat.com/support/cases/#/case/03280446) open with Red Hat on this case. On the first part I concentrated on the missing session isolation, but it showed that this is the supposed behaviour of a KCM setup.