The Owner SID for a Security Descriptor is most definitely replaceable.
You can initialize a blank security descriptor (SD), fill in the Owner
SID (SetSecurityDescriptorOwner) with your desired new owner, then
overwrite the existing SD (the neat part is during the overwrite the
blank sections of the new SD are ignored, leaving the existing SD
components in place). The trick (at the time) was that you required
SeDebugPrivileges to perform the low level SD replacement.
I wrote a Windows version of Chown back in 1998 after a breakout
discussion on Security programming at MS PDC, where it was questioned
whether or not it was possible to do programmatically. If you're
interested, I think the source is still posted on VbAdminCode
(http://www.vbadmincode.btinternet.co.uk/). Please note that it's very
old code and was at the time intended to work against file objects in
NTFS, but I believe the principals still hold true for manipulation of
Directory objects (and it still works on NTFS 5 file objects, I just
tested it).
As for the architectural concept of assigned ownership control, the
two-part process of object ownership defined by Microsoft has it's pros
and cons. Owner identity control from the standpoint of giving a user
the 'right' to be the owner of an object and then that user actually
'taking' ownership does ensure a degree of ownership integrity, but in
my mind the overhead required to perform this two-part procedure has the
potential for creating an administrative problem (esp. in large-scale
environments where the ownership of objects may change hands
frequently). Also, it begs the greater question of what your 'trusted'
administrators should be able to do (which is why I wrote Chown :-)).
Richard
> -----Original Message-----
> From: Darren Sykes [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 20, 2002 8:32 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] setting/restricting permissions on
> objects in OU tree
>
>
> I fully understand the theory behind ownership, however on
> NTFS permissions, this could be manipulated. Look at number
> 16) on http://www.giant-technologies.co.uk/quotaadvisor/
> which mentions the utility they provide. Presumably a dACL on
> a file will by the same structure as those on an AD object?
>
> Darren.
>
>
> -----Original Message-----
> From: Tony Murray [mailto:[EMAIL PROTECTED]]
> Sent: 20 September 2002 13:23
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] setting/restricting permissions on
> objects in OU tree
>
> No, I'm not sure - just going on what I've read. It would
> make sense from a security point of view though. If I can
> only _take_ ownership then it's pretty clear that I am the
> authentic owner. However, if I can assign ownership to
> anyone and everyone then the concept of owner authenticity disappears.
>
> Tony
> ---------- Original Message ----------------------------------
> From: "Darren Sykes" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Fri, 20 Sep 2002 13:00:23 +0100
>
> Tony,
>
> Are you sure ownership can't be given away? That wasn't my
> understanding (though it's what you'll read in Microsoft's
> MCSE books). AFAIK, there's nothing in the API which will
> prevent you from doing this, just the GUI.
>
> There are 3rd party applications which add this functionality
> (Quota software if I remember rightly, as quotas are assigned
> to the owner of an object). So perhaps coding would be possible?
>
> Darren.
>
>
> -----Original Message-----
> From: Tony Murray [mailto:[EMAIL PROTECTED]]
> Sent: 20 September 2002 12:57
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] setting/restricting permissions on
> objects in OU tree
>
> If I understand this correctly, the issue here is that the
> creator of an object is automatically designated as the Owner
> of the object. Through ownership of the object this person
> has certain permissions that you don't really want them to have.
>
> I don't have a neat solution this, but perhaps there are some
> workarounds, e.g.
>
> 1. Provide a tool (e.g. web based) that allows people with
> delegated permissions to create the objects they are allowed
> to, but use a protected account to actually perform the
> object creation. In other words, the tool acts as
> intermediary. It checks the credentials of the user
> requesting the creation against the ACL and, if the account
> has the required permission, the tool will create the object
> using the protected account.
>
> 2. Use a protected account to take ownership of objects
> shortly after they have been created. I don't like this
> approach as the only way that I know to change ownership is
> to actually take it by clicking - it can't be given away.
>
> Tony
>
> ---------- Original Message ----------------------------------
> From: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> Date: Fri, 20 Sep 2002 11:58:17 +1000
>
> Rick,
> Any further ideas?
> Gil?
>
> Michael Homsey
> Telecommunications and Industrial Physics
> CSIRO, Australia
>
>
> -----Original Message-----
> From: Rick Kingslan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 17 September 2002 2:16 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] setting/restricting permissions on
> objects in OU tree
>
> Michael,
>
> Good question here, and one that I haven't run into - hence
> don't have an answer. 10 minutes of looking at my references
> didn't turn up anything. I'll keep looking, because I
> remember reading something about this andit's kinda bugging me now.
>
> Gil, if you're reading this - what do you know about this?
>
> Rick Kingslan - Microsoft MVP [Windows NT/2000]
> Microsoft Certified Trainer
> MCSA, MCSE+I - Windows NT / 2000
>
> "Any sufficiently advanced technology
> is indistinguishable from magic."
> --- Arthur C. Clarke
>
>
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: Monday, September 16, 2002 9:53 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [ActiveDir] setting/restricting permissions on
> > objects in OU tree
> >
> >
> > Thanks Rick,
> > there must be something i am missing.
> > I can restrict the changes to the immediate OU so its
> > permissions cannot be changed. I can restrict the objects
> > created (eg nesting of OUs ) and the computer objects.
> > However, if I create a sub-ou, it allows me to disconnect the
> > inherited permissions with the check box. which privelege
> > turns this off?
> >
> > Michael Homsey
> >
> > -----Original Message-----
> > From: Rick Kingslan [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, 16 September 2002 9:48 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [ActiveDir] setting/restricting permissions on
> > objects in OU tree
> >
> >
> > Go to the advanced ACLs of the user / group that you want to
> > remove the ability to change permissions and remove the
> > 'Modify Permissions' permission at that level.
> >
> > This must be done in the Advanced mode of the Security of the
> > object(s) that you want to affect.
> >
> > Rick Kingslan - Microsoft MVP [Windows NT/2000]
> > Microsoft Certified Trainer
> > MCSA, MCSE+I - Windows NT / 2000
> >
> > "Any sufficiently advanced technology
> > is indistinguishable from magic."
> > --- Arthur C. Clarke
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]] On Behalf Of
> > > [EMAIL PROTECTED]
> > > Sent: Sunday, September 15, 2002 6:17 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [ActiveDir] setting/restricting permissions on
> > > objects in OU tree
> > >
> > >
> > > Dear all,
> > >
> > > I wish to be able to delegate the creation of OUs and specific
> > > objects in an OU tree. Giving the permission to create an
> OU allows
> > > the creator to change permissions and cirumvent controls
> on the OU
> > > subtree.
> > >
> > > If I wanted peopleto manage a certain type of object eg
> > > create/deleet computer accounts full control of computer accounts
> > >
> > > create delete sub OUs, but not change permissions so that
> they could
> > > create delete people objects,
> > >
> > > Whats set of permissiosn are need on the parent oU to
> achieve this?
> > >
> > >
> > > Michael Homsey
> > > CSIRO Australia
> > > List info : http://www.activedir.org/mail_list.htm
> > > List FAQ : http://www.activedir.org/list_faq.htm
> > > List archive:
> > > http://www.mail-archive.com/activedir%> 40mail.activedir.org/
> > >
> >
> >
> > List info : http://www.activedir.org/mail_list.htm
> > List FAQ : http://www.activedir.org/list_faq.htm
> > List archive:
> > http://www.mail-archive.com/activedir%> 40mail.activedir.org/
> >
> > List info :
> > http://www.activedir.org/mail_list.htm
> > List FAQ : http://www.activedir.org/list_faq.htm
> > List archive:
> > http://www.mail-archive.com/activedir%> 40mail.activedir.org/
> >
>
>
> List info : http://www.activedir.org/mail_list.htm
> List FAQ : http://www.activedir.org/list_faq.htm
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
> List info : http://www.activedir.org/mail_list.htm
> List FAQ : http://www.activedir.org/list_faq.htm
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
>
> List info : http://www.activedir.org/mail_list.htm
> List FAQ : http://www.activedir.org/list_faq.htm
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
>
>
> **************************************************************
> **********
> ********************************
> This e-mail is from Energis Communications Ltd, 50 Victoria
> Embankment,
> London, EC4Y 0DE, United
> Kingdom, No: 2630471.
>
> This e-mail is confidential to the addressee and may be
> privileged. The
> views
> expressed are personal and do not necessarily reflect those
> of Energis.
> If you are not
> the intended recipient please notify the sender immediately by calling
> our switchboard on
> +44 (0) 20 7206 5555 and do not disclose to another person or
> use, copy
> or forward
> all or any of it in any form.
>
> **************************************************************
> **********
> ********************************
> List info : http://www.activedir.org/mail_list.htm
> List FAQ : http://www.activedir.org/list_faq.htm
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
>
> List info : http://www.activedir.org/mail_list.htm
> List FAQ : http://www.activedir.org/list_faq.htm
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
>
>
> **************************************************************
> ******************************************
> This e-mail is from Energis Communications Ltd, 50 Victoria
> Embankment, London, EC4Y 0DE, United
> Kingdom, No: 2630471.
>
> This e-mail is confidential to the addressee and may be
> privileged. The views
> expressed are personal and do not necessarily reflect those
> of Energis. If you are not
> the intended recipient please notify the sender immediately
> by calling our switchboard on
> +44 (0) 20 7206 5555 and do not disclose to another person or
> use, copy or forward
> all or any of it in any form.
>
> **************************************************************
> ******************************************
> List info : http://www.activedir.org/mail_list.htm
> List FAQ : http://www.activedir.org/list_faq.htm
> List archive:
> http://www.mail-archive.com/activedir%> 40mail.activedir.org/
>
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
