Fedora directory users - Nov 2006 - Question about account inactivation

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? 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)?
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.

Radek

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.

-- 
Pete

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

Radek Hladik wrote:
> Is it not possible to tell FDS somehow to include this attribute in 
> all search results despite it is operational attribute?
I guess if you modify schema to remove its operational directive.

-- 
Pete

Pete Rowley napsal(a):
> Radek Hladik wrote:
>> Is it not possible to tell FDS somehow to include this attribute in 
>> all search results despite it is operational attribute?
> I guess if you modify schema to remove its operational directive.
> 
But would I not need to include the attribute in some objectClass then?

Radek

Radek Hladik wrote:
> Pete Rowley napsal(a):
>> Radek Hladik wrote:
>>> Is it not possible to tell FDS somehow to include this attribute in
>>> all search results despite it is operational attribute?
>> I guess if you modify schema to remove its operational directive.
>>
> But would I not need to include the attribute in some objectClass then?
>
Yep. It is either operational or it is not. You could make the schema 
modification and either turn off schema checking or add the 
extensibleObject objectclass to the entries. Neither of those options is 
really recommended. Client modification is your best option.


-- 
Pete