пн, 21 дек. 2020 г. в 23:26, Greg Cox <g...@mozilla.com>: > On Mon, Dec 21, 2020 at 7:57 AM Илья Шипицин <chipits...@gmail.com> wrote: > >> that's interesting point. >> being dependent on whether users logs or not does not look very good. >> > > We only go to their logs when they come to us with issues. When we can > head the users off ahead of time, it's easier. > > >> I'd say it is identity management related thing to renew user cert when >> it is about to expire. >> i.e. notify user in proper way and tell him to renew. >> >> as a side question, how do you inform users ? i.e. is it some self >> service portal ? >> > > It's definitely "an IAM problem" to begin with... but it becomes "a VPN > problem" eventually. (abstractly speaking). > > We have a cron that, every day, looks at the CA's VPN certs. If you are > at 14, 7, 3, 2, or 1 days left, you get an email warning of the impending > expiration and links to the login portal + docs so you can renew (or revoke > the cert and stop being nagged). At 2 days expired you get a final mail > explaining that it's expired and you won't be nagged anymore and what to do > if you need back in. >
wow. it is exactly how I meant it :) > > This helps tickets a lot, but when people filter their mail and never read > it, the lack of access falls through to being "a VPN problem." We did what > we could to head off the issue ahead of time from the IAM side, and it > becomes a situation where, as the support personnel, "well, there MUST be > something vastly wrong because surely nobody would miss 6 emails and end up > here asking me to look at a problem." ... except, they do. > if there's self service portal, can we use dhcp option 114 (which is used for captive portal) ? > My contention is, a VPN client has enough information from its own certs > to know when its certs are expired and thus not going to work (Yes, there's > plenty of OTHER reasons a connection can fail, but in a well designed > setup, the user's certs will go stale long before the server). It tells > you this problem in the logs, which folks never read. If the software were > to contain a mechanism to make certain failure cases automatically more > prominent, particularly for 'simple' users who have GUI clients, it'll be a > big win for supportability on larger installs. > > And I realize this is getting into advocacy and away from what's right for > a -devel list, so I'll stop here on this thread. > we are still on topic. > > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
