Hi there,
we are already successfully using the password self service via webinterface for our ad domain users. In addition to this are we in the testing phase of the password self service reset for Windows, which also changes the local cached domain password of the user on the Windows client. Unfortunately we are hitting an obstacle concerning our VPN software, which relies on a user certifate and username/password:
As I found out Windows is securing access to different kind of data through encrypting it with so called masterkeys. The encryption is done with the current user password, you can read that in detail here: https://support.microsoft.com/en-us/topic/bf374083-626f-3446-2a9d-3f6077723a60
So here is the problem: Once you change your domain password via Adaxes password self service those masterkeys get inaccessable and for domain-joined clients the builtin workflow would now contact the AD domain controller in order to get a backup key, create a new masterkey and encrypt them with the "new" password. Unfortunately the idea behind the self-service software is that there is no direct connection to the domain and in our case the VPN client, which could establish a connection to the AD, relies on the access to the user certificate and its private key. But the private key is not accessible because of the logic explained above. So at the end we have a Windows client where the user is able to login but can only establish VPN after he contacted the AD through another way e.g. beeing onsite or a secondary VPN client without certifcate authentication, which is both not favourable.
I think every function in this interaction works as exptected and there is no bug that I am reporting here. I just wanted to ask if anybody else had/has the same problem and maybe can report how they solved it.
Thanks in advance.