Authentication: Delete UTM user-object when deleted from backend server
When we remove a user from our LDAP Directory (namely eDirectory or ActiveDirectory) the User in UTM is untouched. It would be nice if the UTM could know about this and purge its matching user-object as well. (Or display us a report of users who are no longer seen on the backend server so we could trigger a delete periodically).
Creating a new VPN user with Active Directory works quite well in ASG, but there's no way to disable a user without logging into the ASG and deleting the local account that was created from the A/D account. Furthermore, the user name and password are cached on the ASG so changing it doesn't break access either.
Craig Wilson commented
We're now in 2016, and still we cannot do this. my UTM is now filled with obsolete AD objects
C'mon Sophos we could really do with a mechanism to remove objects that are no longer in AD!
***, feature still not included, and it still suxx that it isn't.
Tim Hather commented
This should be seen as essential not nice to have. A messy UTM is not a happy UTM!!
I would like to see this feature available too for the same reasons as mentioned before.
Currently im researching the possibilities to provide user authorization for a wireless network from a directory of subscribed members. So when a member is remove from a certain group on the directory, at least the active switch in the user data of the UTM should be set to FALSE.
this become now a must not nice to have, since all companies want to have one access control, and if we add capability to active existing users on UTM to avoid a manual operations.
I'd like to see that very much.
A huge number of Remote Access users coming from the backend (AD) clutters the network definitions and fills it up a lot.
It would be nice if unused/expired/non existent accounts would be periodically checked and removed (or as mentioned before listed separately to bulk-delete them)
Just to keep your UTM "clean"...
Ramon Lustrati commented
This would be a great feature and should be easy to implement, because the astaro is reaching the ldap on a easy way
Gert Hansen commented
The current design requires to create a shadow account of the user from the active directory. The reason for this is, that we create a cert/key pair for this user automatically on the fly which is needed for additional authentication and this information can not be stored in the AD as Astaro never writes to the AD.
But we do NOT store the password of the user in this cached user account. we only cache it for 15min (i think). This means if the disable the account in the AD or remove it from the group, he will NOT be able to log in anymore after 15min, as we do the password authentication against the AD then. If he still can, it is a bug.