On Wed, 2004-02-11 at 02:17, Oron Peled wrote: > On Tuesday 10 February 2004 23:49, Guy Teverovsky wrote: > > AD in general is a bunch of bundled services. You can remove AD from > > your server and can get it up and running back again. > > Does it mean it only affect other applications? or does the kernel > somehow "calls back" AD to ask policy questions? > > This question is important because it ultimately determines the level > of *enforcement* AD has over applications. This is because user space > applications or libraries may be subverted in various ways and thus not > respect the settings AD ordered them. Only kernel level enforcement > will achieve the required effect in these cases.
Let me re-phrase that: >From the server(s) side: you can demote Domain Controller hosting an AD to stand-alone server. You can also boot the box without AD services loaded (used for AD restore/maintenance) Clients: you can disjoin the client from AD domain (need "Addd/Remove computer to domain right - by default Local Admin). As long as the client computer is in the AD domain, the AD will enforce the security model of the client (you can control computer specific or user specific settings). I would not call it "kernel level", but rather Local System Authority (LSA) level, which is not userland. I am having a hard time to define "kernel level" in NT based OSes (is it just me ?) Having local admin on the client might give you some leverage in default configuration and let you block the security model enforcements, but the local admin rights can be revoked using the same old buddy named GPO. So you might find yourself having local admin, but not being able to disjoin the machine from AD or block the enforcements. You can even restrict local logons without authenticating against AD. Heck... I once managed to lock myself out of a workstation by using to strict GPO and could not do anything even though I had local admin account :) > > Even if AD is user space only, it may still be very usefull as a central > facility for controlling (cooperating) applications, but not as enforcement > mechanism. > > > Another important point is the lack of granular ACLs you can apply to > > OpenLDAP objects/attributes. AD here does IMHO much better job. It is > > not trivial, but very powerful. The ACL lets you easily delegate tasks > > to other people, while, when properly maintained, protecting you data. > > I'm not sure I follow you -- doesn't the 'access' directive in slapd.conf > does exactly this? (man slapd.conf) You mean that you must restart the service ? AD does that on the wire (Ilya, thanks for pointing that out :) ). I am repeating myself, but... No inheritance, no inheritance blocking. OpenLDAP ACL is flat. > > Of course most (but not all) Linux filesystems don't support ACL's so your > claim is valid when directed to the granularity of Linux file permissions. > > In your spare time google for "QoS Admission Control" and "IP Security > > Policy". In Microsoft world all the points you raised can be easily > > managed (although it is VERY rare to stumble on an sysadmin using those. > > Well... More points in my CV :) ) > > That was interesting reading (BTW, net/sched/cls_rsvp.* implement this > on standard Linux kernels at least since 2.2.19). However, to really control > lan resources, the switches/routers should have some *authentication* > mechanism to identify the DSBM -- otherwise people can easily highjack > the network. > > Example: http://www.mail-archive.com/[EMAIL PROTECTED]/msg12432.html No I have to do some reading... Thanks for the pointer. > > > I would prefer to see the services Kerberized. > > Now you hit the point. Kerberos solves the distributed services problem: > - Because it is authenticated. > - Because the client and the server don't have to trust each other. > > However, it seems that per user IP-policies (outside of the specific box) are > still an illusion as IP packets don't carry the user information. We can > dictate them only on cooperating hosts. Agreed. You can do you best to optimize the network, but meanwhile there are ways out. Guy -- ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
