best way to disable a user from authing against ldap?
We have a need to be able to disable users in out ldap server (Sun-ONE-Directory/5.2_Patch_2 B2004.107.0034).
We are using msging and cal server together with Access manager and Comms express.
Setting the inetUserStatus to inactive stops users logging into the comms express etc but we are now having a few remote services that are authenticating against ldap by binding as the user. This works regardless so disabled users can login to certain things.
Whats the recommended way of temporarily disabling an account? We can't just change the password as we would need to restore it when the account it reenabled. Is there something easy to prevent the user binding? (something easy to undo again!).
Cheers,
Darren
# 2
that sounds perfect but http://docs.sun.com/source/817-5218/aci.html#wp19841 says "The nsAccountLock attribute should never be modified manually, but using the command-line utilities" which would be a real pain. I am implementing a backend for a remote admin server that is custom written - it only has ldap access to the ds so I really want to do this with simple ldap.
We are creating users using ldap - is the world going to end if I just set nsAccountLock?
Any other ideas?
Cheers, Darren
# 3
IMMO, the only problem os setting programatically the attribute you mention is the perhaps in future versions of the DS, SUN decide to change the way to lock accounts and you will have to modify your code
I am using it in the way you mention and it works OK for me.
Other possibility is just to change the userPassword attribute to some random value. The only problem with this is that if you have to later reactivate the account, you should save the old password hash in some database.
# 4
I hadn't read your post very carefully :-)
We implemented some time ago a simple application for administrators that randomly changed the password of users but that previously copied the hash in another LDAP attribute, so restoring user accounts was possible and quick.
Once nsUnlock appeared, we modified the application to use this attribute.
# 5
If you need to do account inactivation programmatically, and you are a perl programmer, take a look at perl scripts ns-activate.pl, ns-inactivate.pl, and ns-accountstatus.pl. If you can figure out how it works from that, then do the same thing.
# 6
I found that if I use JNDI to set nsaccountlock to true, it does disable the user from authorizing. However, it also makes the Custom Editor unable to re-activate that user. You can press the "Activate" button, and it will tell you the user has been activated, but if you check the nsaccountlock, it will still be set to true. However, one can still use Generic Editor to delete the nsaccount lock to re-activate the user.
In order for the Custom Editor to be able to reactivate the user, the user must be in the nsManagedDisabledRole. If you add the "cn=nsmanageddisabledrole,<larger context>" to the users nsroledn attribute, then the ldap automatically sets the nsaccountlock value to true.
And if you later delete the nsaccountlock value, the ldap will automatically remove the nsManagedDisabledRole from the user's nsRoleDn.
Tricky stuff,
Christa
