[s4] Access Control Rights musings

[Andrew Bartlett]

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' 

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

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/96349a9f/attachment.pgp>