[s4] Access Control Rights musings
Andrew Bartlett
abartlet at samba.org
Fri Mar 26 05:36:16 MDT 2010
On Fri, 2010-03-26 at 13:30 +0200, Nadezhda Ivanova wrote:
> On Fri, Mar 26, 2010 at 1:24 PM, Andrew Bartlett <abartlet at samba.org> wrote:
>
> > On Thu, 2010-03-25 at 17:25 +0200, Nadezhda Ivanova wrote:
> > > Hi all,
> > > My apologies for the 10-tomed "Mission Earth" I am dumping on you, but I
> > > would appreciate at least a cursory glance, to make sure I haven't missed
> > > something important.
> > > This is a list of references and short explanations about Access Control
> > > Rights and when the system needs to check them, and my opinion if they
> > are
> > > relevant to our implementation. I suppose it could be useful to all of
> > us,
> > > since I may not always be able to add access checks fast enough in the
> > > appropriate place in the code so other people may need to help. Also
> > perhaps
> > > you can help me decide which ones are actually relevant. I am not sure if
> > we
> > > need them all for interoperability...
> > > I dont know if I should should add all of these that are relevant to the
> > > TODO list, to keep track of what we have.
> > >
> > > *The following are rights that we definitely need to check for:*
> > >
> > > *Add-GUID* - Extended right needed at the NC root to add an object with a
> > > specific GUID. If the requester specifies an object guid when adding an
> > > object, they must have this access right on the NC. A few other
> > conditions
> > > must be met as well, see MS-ADTS 3.1.15.2.1 for reference. I am not sure
> > if
> > > we currently always disallow specifying objectGuids, and if we do, where
> > > it's done...
> >
> > repl_meta_data disallows it, unless 'relax' is specified. I think there
> > is also a 'DS behaviour' bit that should also be checked'
> >
>
> So, does it make sense to do a few tests without this explicit disallow, but
> with checking for
> an access right + the additional conditions and see if we get the same
> behavior. Not sure if it would
> break the openLDAP backend though...
This, like many other things, just won't be supported in that mode. If
it is really desired, we will stop mapping objectGUID to entryUUID.
> > > Kerberos:
> > > Allowed-To-Authenticate - The control access right controls who can
> > > authenticate to a particular machine or service. It basically lives on
> > > computer, user and InetOrgPerson objects. It is also applicable on the
> > > domain object if access is allowed for the entire domain we. It can be
> > > applied to OU's to permit users to be able to set inheritable ACE's on
> > OU's
> > > containing a set of user/computer objects. This one is referenced in
> > > MS-KILE 3.3.5.4 TGS Exchange and MS-SFU 4.3, both documents are about
> > > Kerberos protocol extensions, so maybe abartlet can take a look and say
> > if
> > > they are relevant.
> >
> > Perhaps this is about using the KDC to control access to a service that
> > does not do good internal access control? If the KDC won't give you a
> > ticket, you don't have to trust that the in-house written app can decode
> > the PAC and check that you are really an administrator. (For example).
> > It's a complete abuse of Kerberos, but it probably works :-)
> >
> > It would need to be checked in the KDC before we issue a ticket to a
> > particular service.
> >
>
> Well, if you decide to go into this and need my help, lust let me know. I am
> completely
> ignorant here, would not even know how to test it.
Testing it should be easy - we have code in the RPC-PAC test to do a
kerberos exchange in a torture test.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100326/3f773be6/attachment.pgp>
More information about the samba-technical
mailing list