$ad_options['force_unlock'] = true; not working

[glorenzutti]

I there! Im using 1.4.3 version, and I can't get to work the force_unlock option.
Everything works, besides this.
Im only using the reset by email token feature.
The password its changed, but the user its still disable.

This is the relevant part of my config.

If anyone can give me a clue, it would be awesome.
tnxs in advance.

root@ltb01:/usr/share/self-service-password/conf# grep -v '#' config.inc.php |grep -v ^$

[faust64]

Hi,

Your configuration does not show, I assume you did set $ad_mode = true as well?
The force_unlock option should remove the lockoutTime attribute from an user, when changing its password.
Can you tell which attribute is used to disable accounts in your AD?

[glorenzutti]

Okey, sorry. Now I understand. The force_unlock dosen't enable disabled accounts.
Tnxs, sorry again.

[faust64]

No problem.
Managing attributes such as pwdAccountLockedTime, you could look into https://github.com/ltb-project/service-desk -- though that one is not meant to be self-service, like ssp, rather admin-oriented.
Or if your attribute disabling accounts is neither pwdAccountLockedTime nor lockoutTime, we could consider adding support, ... let us know.

[glorenzutti]

No problem.
Managing attributes such as pwdAccountLockedTime, you could look into https://github.com/ltb-project/service-desk -- though that one is not meant to be self-service, like ssp, rather admin-oriented.
Or if your attribute disabling accounts is neither pwdAccountLockedTime nor lockoutTime, we could consider adding support, ... let us know.

Well i did check the service-desk and im going to use it. But it would be awesome to let the users active they own accounts, like they change the password. The attribute that need to be managed is the userAccountControl, in AD and samba4.

Although I did not test the service-desk application, there I see that there is the possibility of activating and deactivating the accounts. I gather that it is implemented there.

Tnxs in advance.

[faust64]

Thanks for your follow-up.
Actually, I don't think that service-desk already handles userAccountControl management. That project is more recent, and probably lacks completion in some aspects. Though we could look into this ...

Could you confirm: you want to take the original userAccountControl value, and remove out 0x0002 / ACCOUNTDISABLE (https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties#list-of-property-flags), keeping whatever else was set?
Or should we force-set a new value instead, like 0x0200 / NORMAL_ACCOUNT (which may be customized in config.php).
... Or maybe do something in between, like ensure we're not 0-ing that field (having quickly checked their docs, I'm not sure yet what a "0" would imply there)
I might look into this, at least for service-desk. And check with an owner how relevant it would be to implement something like this in self-service-password.

Also, doc would suggest that userAccountControl attribute refers to older active directories (2012). A note (with what I guess is a typo, 2003 / 2013), points to another doc: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/useraccountcontrol-manipulate-account-properties , which mentions something like: https://docs.microsoft.com/en-us/windows/win32/adschema/a-msds-useraccountdisabled
I'm not much familiar with active directories, ... shouldn't we look into this as well? (instead?) Are you still running 2012 servers?

[faust64]

I've opened a new case.
Feel free to answer here, or over there: ltb-project/service-desk#48

[glorenzutti]

Sorry for the delay. This is exactly what I need.
Even yesterday, after I understood that the application did not comply with this, I took advantage of the post_hook option.
The post_hook that I put together activates the user.
In fact I was going to report a bug that I found with this, which I am not going to put here to avoid mixing things up.

[glorenzutti]

Adding to what has already been said, the need to activate the user has many more use cases than to change the attributes that the application already does.
I appreciate very much that you have read what I shared, and that you have analyzed the case. Hopefully you can include the functionality also in the service-desk application.

The weak point that I found the service-desk is that it does not handle profiles. It would be great if the application has profiles, and also be able to have a record of who did what.

If the two apps were related, it would be another breakthrough. Because you could see in the service-desk who used the application to request a password reset, among many other things.