[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