[Freeipa-devel] [PATCH] user and group deletion

Pete Rowley prowley at redhat.com
Tue Oct 30 18:55:43 UTC 2007


Simo Sorce wrote:
> On Tue, 2007-10-30 at 11:24 -0700, Pete Rowley wrote:
>   
>> Simo Sorce wrote:
>>     
>>> On Tue, 2007-10-30 at 10:58 -0700, Pete Rowley wrote:
>>>   
>>>       
>>>> Simo Sorce wrote:
>>>>     
>>>>         
>>>>> I don't see how we could easily do group inactivation, deletion is ok
>>>>>       
>>>>>           
>>>> Clues: Class of service, an "inactivation group" and the memberof 
>>>> attribute :)
>>>>     
>>>>         
>>> Yes,
>>> but we need to deal with existing clients and how they will interpret
>>> this.
>>>
>>> So far for users inactivation is simple as you simply deny them auth,
>>> but for groups there is no auth.
>>>
>>>   
>>>       
>> It is the members of the group that matter.
>>     
>
> I see, so you propose to delete the memberOf attirbute for "disabled"
> groups, and re-add it later if the group is enabled again, I see.
>   
No. The scheme would work like this:

A group called "Inactivated" to which other groups are made a member 
when their membership is to be inactivated.
A classic class of service scheme that uses memberof as its cos 
specifier, a single template with an rdn = dn of the "Inactivated" group 
and delivering nsAccountlock: true

Thusly, any group added to the "inactivated" group will have their 
membership inactivated with nsAccountlock: true showing up in the people 
entries.
> But I guess we still have clients that looks at the group's 'member'
> attribute, not at the user's memberOf ...
>   
Inactivation is not about what other clients think, it is a mechanism to 
prevent binding to the DS.

-- 
Pete

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20071030/0338e59f/attachment.bin>


More information about the Freeipa-devel mailing list