Pete Rowley napsal(a):
> Radek Hladik wrote:
>> I would like to ask one stupid question about account inactivation.
>> When I use FDS console to deactivate user, it produces some "magic"
>> with CoS to add operational attribute nsAccountLock to the specified
>> user entry. Is there any reason why this is done so complicated?
> It is done this way so that large numbers of accounts can be activated
> or deactivated with one single modification.
>> Why the nsAccountLock attribute can not be specified as optional
>> attribute in for example posixAccount class? And is this approach
>> possible in case I need only user account inactivation (I mean no
>> groups or roles)?
> You should not do that because it modifies standard schema, and no good
> will come of that.
>> I need to provide our account administrators with some easy
>> possibility to inactivate account via phpldapadmin and I would like to
>> do it in as standard way as possible. Of course we could change the
>> password hash specifier i.e. from {SSHA} to {SSHA-disabled} but I
>> consider this as last resort option.
> You can do that right now. Add nsAccountLock: true to an entry it will
> be locked. Operational attributes don't require that the entry have a
> particular objectclass to pass schema check.
>
Thanks, this works, but I have problem with displaying the operational
attribute in phpldapadmin - in fact in other ldap browsers too, only
Softerra can be configured which operational attributes it should
include in entry. Phpldapadmin can show internal attributes and I could
change source code to include nsAccountLock but it assumes that user do
not need to change these attributes and thus does not allow user to
modify them :( . I can (and probably will) code a piece of code into
phpldapadmin to provide checkbox for this, but first I want to find more
clean possibilities. Is it not possible to tell FDS somehow to include
this attribute in all search results despite it is operational attribute?
Radek
