Well then, I'm just not the type. I'll elaborate. On Tuesday 10 February 2004 10:32, Oron Peled wrote:
On Tuesday 10 February 2004 05:28, Ez-Aton wrote:
... starting from Windows 2000 (i don't count WinNT as a real OS anyhow),
First an unrelated observation. Through the years I used to hear: "Windows for Worgroups isn't real OS -- Win95 is true 32bit OS" "Win9X is just a graphical shell -- WinNT is modern design done by the same people who did VMS" "WinNT is obsolete -- W2K is the future"
and I'm waiting for: "W2K is the old world OS -- W2K server and .Net are true revolution"
This isn't against you specifically Ez, every Win* user I know thinks the *previous* Windows sucks big time... isn't it weird?
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).
Welllll, it would stand to reason Microsoft will include *some* enhancement in their newer products...
I, for one, still see NT4 is the their best corporate desktop environment. It's not surprising that when faced with the prospect of migrating to w2k, the Linux/Samba combo suddenly appeared so appropriate.
[snip]
Personally I'll take any day my first old slackware (kernel 0.99pl14) with its FVWM (with GoodStuff config) -- it was functional, fast and stable.
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.
So does any LDAP compliant directory (including OpenLDAP). You do not want to make up schema as you go along. Other ldap servers also offer much better documentation.
[snip]
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.
This is also the weakness of it. OGO does not modify the security of settings of the registry keys (as I assumed first time I used it), but overrides them with the server stored keys. This gives a reasonably intelligent user a window (hahaha) of opportunity.
The correct place to enforce proxy settings is the firewall regardless of the OS.
*One* of the places. I consider OGO to be a convenient method to deploy proxy settings, not to enforce them.
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. - For a single user -- in his own login script. - 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.
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.
Ez.
================================================================= 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]
