In the spirit of "Know your enemy" (well, actually I admit to be more MS
oriented), I will drop my couple of cents...
On Tue, 2004-02-10 at 13:41, Ez-Aton wrote:
> Well then, I'm just not the type. I'll elaborate.
> [snip]
> > This isn't against you specifically Ez, every Win* user I know thinks
> > the *previous* Windows sucks big time... isn't it weird?
[skipping so not to start a flame bate]
> Not exactly. For some time now, Windows 2003 Server is at hand, and I still
> claim Windows 2000 to be a good product (generally speaking). Windows 2000
> Server implements the AD mechanism (unlike Win2000 Pro), but it's not a
> kernel based part, but a module, you can run the system without (AD
> Maintenance mode).
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.
[snip]
>
> >
> > 3. For site-wide hierarchical management many use LDAP. It is already
> > integrated in the important infrastructural applications -- login,
> > (via pam) Mail (sendmail, postfix, imap4, etc.) and more.
>
> Agree. But it's not the native way of doing things, yet. Implementing an LDAP
> schema is based on picking up the correct schema, while, although it reduces
> the choise, AD (which is based on LDAP and Kerberos) has already built-in
> schema.
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.
[snip]
> >
> > I think one of the problems we have in attaching security information
> > to the user login, is that there are many cases of "non-login" usage:
> > - Someone is running a process via rsh/ssh (this isn't login).
> > - Someone is using my DISPLAY (consuming resources).
> > - Someone is using my disk via NFS (again,... resources).
> > - Packets are being routed via my computer (there are no "user"
> > credentials in the packets at all..)
>
> Agree.
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 :) )
>
> >
> > Let's combine the above points into a real-life scenario:
> > I seat at computer A running via SSH a program on computer B
> > (with its DISPLAY apears on A of course). The program was
> > loaded from my NFS server C and establish a connection
> > to a server D, and the packets are routed through router E.
> >
> > Now since the user activity is distributed, it's non-trivial
> > to apply some central policy to his actions.
See above. I can choke any Winbox in my network :)
> >
>
> Not exactly. You could, through a central LDAP/other directory, which
> Computers A, B & C are to AAA agains, the rules which apply to a specific
> user/computer. If you're permitted to use DISPLAY on other computer, but
> allowed to run only X,Y &Z, that's what you'll run (Computer B now). Computer
> A asks if it's allowed to show DISPLAY, for who and from where, Computer B
> checks if you're allowed to run the software you're running, your server, D,
> checks what are your permissions regarding NFS, quota, etc, and computer E
> checks the source, target, and may be given details about your UID. If all
> computers are checking agains a directory located on computer F (with live
> replica to computer G), you could and should be able to maintain one security
> and permission directory service and tables, and no more. That's good for an
> organization.
Sounds painful...
I would prefer to see the services Kerberized. Much easier to manage.
>
> > You are correct that having a central policy helps. But the hard
> > question is if we can do it *without* sacrification of our
> > distributed world ("The network is the computer" [McNeily]).
>
> No. See above.
Kerberos based AAA anyone ?
>
> >
> > > (I enforced Proxy settings for IE on every client computer just
> > > yesterday),
> >
> > I'm not sure I understand what you mean by "enforced". Does it change the
> > settings in the Explorer preferences? Than this is not enforcement because
> > it depends on the cooperation of the Explorer program -- What would prevent
> > a user modifing the behaviour of Explorer? security by obscurity.
>
> It changes the settings per computer in my Domain. Yes. You had proxy settings
> ten minutes ago, now you don't. You can't change them back (if I decide you
> can't), and even if you could, give the computer then minutes on the net, and
> they'll be back to what I've predefined. That's the power of the GPO.
>
> > The correct place to enforce proxy settings is the firewall regardless
> > of the OS.
You think so ?
Suppose you have a bunch of proxies and you want certain groups of users
or computers to point to different proxies. Using GPO I can do it in a
snap.
>
> How do you force Proxy (actually, in my case - no-proxy) settings for your
> clients on the firewall? Had I used a proxy, I could implement a transparent
> proxy, however, I didn't want them to use a proxy anyhow...
>
> >
> > A Linux note:
> > The "old way" to set proxy was via environment variables -- this had the
> > excelent effect that you can do it at whatever level you want:
> > - For every user -- in system login scripts.
GPO applied to computer objects...
> > - For a single user -- in his own login script.
GPO applied to user objects.
> > - For a single session -- on the command line.
> > The only downside was you have to start the application for it to take
> > effect. I wonder why modern browsers haven't left it as a *default*.
> > Of course if they use GConf, we can still have these properties.
>
> True. I agree. The environment variable is a good tool, although limited. You
> can hardly prevent a user from overaiding your settings. I don't know GConf
> yet, so I can't commetn about it.
> >
> > > and do most of whatever comes to your mind.
> >
> > Can you run scripts? If not, than it's good only for the simple cases of
> > variable=value settings and not places where you need to run some logic.
> > (It's true that most settings are these simple var=value cases).
>
> You can run scripts. CMD scripts, VBS scripts, and if clients can run
> perl/python/BASh, these too. You can run executebles on client computers,
> because inside an organization, there (must be) is a trust relationship.
You can always push your preferred scripting language interpreter to the
clients and run scripts in the user (logon) or computer (startup)
context.
GPO is VERY powerful tool, but it will always bite the sorry ass of the
one that had not bothered to do his RTFM before applying it. It's not
easy and poorly documented, but it lets you do some very interesting
things you have never considered before.
> I'm not saying LDAP on a Linux machine is a bad thing, however I'm saying that
> on Win2k, and using their reemplementation of the LDAP into the AD mechanism,
> they did a good job. Not perfect, but a good one, towards central point of
> control in an organization. We should learn from their successes, and from
> their mistakes, towards doing what we do better.
LDAP is a protocol and although it is the backbone of AD, it is not the
only service in use. LDAP in 2003 (as opposed to LDAP in 2000) is also
RFC compliant (anyone for InetOrgPerson ?)
>
> Ez.
>
>
Now hold your guns. I do both OSes. I love each from different reasons.
My only point is an attempt to emphasize what Ez had already mentioned:
know them both before you run into flamewars.
Regards,
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]
--
=================================================================
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]
