Slashdot Mirror

See JSI Tip 4107.

Now... creating symbolic and hard links in NTFS, and having the boot partition on a separate HD than your C:\Windows (C:\WINNT) directory, well those are options that you have to go without.

NTFS does support hard links for files. Use "fsutil hardlinks create" to do it. At least one person has made a GUI to do it too, check out Hard Link Magic. If you want to link a folder or drive, it's termed a junction point. Read the nitty gritty here. "mountvol" will do it for drives, "linkd" (from the Resource Kit) will do it for folders, and Junction Link Magic will do it thru a GUI.

Shortcuts are MS's version of symlinks, but there are important differences between the two.

Oh and you can't have your boot partition on a different drive than %WINDIR% because that's the definition of the boot partition: where %WINDIR% resides! I think what you meant is your system partition - which is where the boot files reside (Unintuitive? You bet!)...which can in fact be on a different drive than your boot partition. Anyone who has more than one MS OS on their PC can attest to that.

It is. It just isn't turned on by default.

You can do it with a flag when starting CMD, or you can change the registry to make it permanent:

http://www.jsiinc.com/SUBF/Tip2500/rh2542.htm

Just set the flag to 0x09 to enable TAB as the completion character.

No, seriously...

Bring up your favorite distro. The important bits of immediate concern are Squid and syslog. Prevent direct access to the net from the client machines and force them to go through the proxy using a GPO in ActiveDirectory. Configure Squid how you like, but best to at least add the capability to block certain sites and prevent certain file types from being downloaded:

acl hosts_deny dstdomain "/etc/squid/blocked_sites.txt"
acl filetypes urlpath_regex -i "/etc/squid/filetypes.txt"

http_access deny filetypes
http_access deny hosts_deny

List the domains to block in /etc/squid/blocked_sites.txt. List the file extentions to block in /etc/squid/filetypes.txt in regex fashion (something like \.(exe)$ to block .exe files). Not a complete fix, but a good quick way to safeguard web access.

Now run over to sourceforge and grab ntsyslog. This handy tool exports your Event Viewer logs to a remote syslog server. It installs as a service and it's a cinche to setup. Stick is on your domain controller. On your Linux box add a line like the following to syslog.conf (for sysklogd):

user.alert -/var/log/domain.log

By default, ntsyslog uses user.alert, but you can change that to whatever you like. Also make sure your syslog is configured to receive messages from remote clients. Now, in your default domain policy on the domain controller configure it to audit logon events as well as account logon events, successes and failures for both.

Now you've got web access managed by a central proxy with full logging and minimal blocking abilities and all logon success/failures being reported to Event Viewer on the DC and forwarded to the syslog. If you want to see who is logged into a machine at any given time you can either quickly parse the logs or use something like NetUsers or LoggedOn.

Popular local opinion says that you're likely to have more problems/attacks with/against your Windows server. Having your Event Viewer messages forwarded means you can diagnose problems in the event something happanes to that server. You'll probably want to at least MRTG the Linux box to get an idea of bandwidth usage too. Then enjoy whippin' up your own set of shell scripts to play with your logs (hint: real-time monitoring)!

No, seriously...

Bring up your favorite distro. The important bits of immediate concern are Squid and syslog. Prevent direct access to the net from the client machines and force them to go through the proxy using a GPO in ActiveDirectory. Configure Squid how you like, but best to at least add the capability to block certain sites and prevent certain file types from being downloaded:

acl hosts_deny dstdomain "/etc/squid/blocked_sites.txt"
acl filetypes urlpath_regex -i "/etc/squid/filetypes.txt"

http_access deny filetypes
http_access deny hosts_deny

List the domains to block in /etc/squid/blocked_sites.txt. List the file extentions to block in /etc/squid/filetypes.txt in regex fashion (something like \.(exe)$ to block .exe files). Not a complete fix, but a good quick way to safeguard web access.

Now run over to sourceforge and grab ntsyslog. This handy tool exports your Event Viewer logs to a remote syslog server. It installs as a service and it's a cinche to setup. Stick is on your domain controller. On your Linux box add a line like the following to syslog.conf (for sysklogd):

user.alert -/var/log/domain.log

By default, ntsyslog uses user.alert, but you can change that to whatever you like. Also make sure your syslog is configured to receive messages from remote clients. Now, in your default domain policy on the domain controller configure it to audit logon events as well as account logon events, successes and failures for both.

Now you've got web access managed by a central proxy with full logging and minimal blocking abilities and all logon success/failures being reported to Event Viewer on the DC and forwarded to the syslog. If you want to see who is logged into a machine at any given time you can either quickly parse the logs or use something like NetUsers or LoggedOn.

Popular local opinion says that you're likely to have more problems/attacks with/against your Windows server. Having your Event Viewer messages forwarded means you can diagnose problems in the event something happanes to that server. You'll probably want to at least MRTG the Linux box to get an idea of bandwidth usage too. Then enjoy whippin' up your own set of shell scripts to play with your logs (hint: real-time monitoring)!

Dameware : manage the machines from a remote location.

netusers.exe and some perl or python thrown in to deal with the output of netusers. You can get all your user stats and stuff from this.

With those tools you can develop some scripts to track usage, avaiable comptures and throw it all up on a web site.

Neither of the above make any difference. Any sane *nix installation doesn't allow root logins over the network, and as many have pointed out, all you really need to know is that you're after UID 0.

Somewhat less widely known is that the exact same is true on the Windows platform. The builtin Administrator account (which can't be disabled, is exempt from password lockout, and almost always CAN be used over the network) always has a RID of 500. The SID for the computer can be determined easily enough, so any anonymous user can find out exactly what you renamed your administrator account to.

See NT Bugtraq or JSI for more details.

You do realize that a null session (even more anonymous than guest and very hard to disable as many services depend on it) has the ability to query for your renamed Administrator account, right?

http://www.jsiinc.com/SUBB/tip0500/rh0519.htm

I have auto-run turned off. I did it with tweakui which microsoft provided. I assume this means the CD will always be easily copyable on my computer with the extra effort of holding down the shift key. It sure was nice of microsoft to provide me with this nifty circumvention.

You used to be able to just right click on the cdrom drive in My Computer and choose to turn off autoplay. I always did because autoplay is extremely annoying and breaks things a lot. BUt I seem to have forgotten it is not so easy to do so in Win2k, mainly because I primarily use Linux.

Nevertheless, regedit is your friend if in Windows, and editing a few entries will fix this problem as well.

You know, I think they are causing more damage by including malware on this cd. Many computers have been damaged by software present on these cds which the purchaser thought only contained music and which installed software on their computers without their permission or prior knowlege. These people are no better than virus writers, and it is no wonder they are such hacks. Besides, if you want the cd to be DRM'd would it not make more sense to actually encrypt the contents rather than to have a software driver encrypt them on the fly? Who thought that was a good idea?

http://www.jsiinc.com/

There is an incredable wealth of information on that site.

altp

We run a fairly large NT4 shop here too. A thousand workstations and 50+ servers. Our licensing rep explained that there will be no new licenses sold for either the server or CALs. We can now only buy 2003 CALs thru our licensing contract but the legal verbage that comes with them states that they are only valid for "downgrade rights" one previous version, i.e. to W2K server... they are not legally applicable to NT4 servers. That's the big "gotcha" here. The rep further explained that although right now they're saying on their website that the downloads and knowledgebase articles will still be available, that it is their full intention to purge all downloadables and support information for the old retired products from their website in the near future and not only that, they will have a team of "Gators" -- investigators and litigators (lawyers) scour the Internet looking for unauthorized 3rd parties still publishing this stuff and go after them with a vengeance. Even the famous JSIINC.COM "Tips and Tricks" website is going to come under great scrutiny. Because of all this, our whole IT department was ready willing and able to begin a migration to Linux and Samba. Even our manangement was beginning to be convinced... that is, until this SCO-IBM lawsuit and all the FUD against Linux began flying. Now our management is too scared of Linux and has decreed that we will be going to Windows 2003 instead. Our department recently lost one of our people who went back into the military during the Iraq war and decided to stay in the military permanently now, and another person is about to retire in a couple more months, so their salaries is going to pay for the W2003 migration and we're going to have to run our shop short-staffed for the next year(s) until the economy picks back up. I wish I had gone into real estate instead of computers now.

• The registry in Windows seems to be a logical choice. There are standard tools to use it, it can be manipulated remotely, and except for those horrible clid crap. It is, however, difficult to understand for a human except for those common areas like HKLM\Software\Microsoft\Windows\Run.
• The Windows registry implementation is horribly flawed. It's too likely to get corrupted. A lot of this is from being part of a roaming profile. Losing your registry is like losing all of your application's and user preferences. It really sucks.
• *NIX is a mess when it comes to location of config files, as stated in the article. Even various Linux distros. We have Redhat boxen doing a lot of work now, having switched from a proprietary UNIX (dg/ux) a while back. Some of my techs think we should switch to Debian. I installed it on my workstation in vmware. It's nice, but it'll just require re-learning where the hell everything is. Maybe no big deal but I've got too much to remember already.
• Windows registry trees are not commented. You need to know how to find various reg hack sites and own a ton of resource kits, just to keep a leg up on the crap. Even then everything is not revealed. "You should configure it through the GUI." Yeah, right, on 2,000 machines?
• UNIX config files generally only have one per app. Configuring an app is simply a matter of loading the config file into an editor, reading the including commentary, and adjusting to taste. The exception here is the redhat /etc/sysconfig tree where everything is basically just loading of env vars for other scripts. Not commented, minimal defaults, if you need to figure out something it's dig through docs or read the rc scripts yourself to figure out what to set in it. Yack...
• Windows configs are often done through a maze of menu entries, dialog boxes, tabs, "advanced" buttons, etc... It always leaves you wondering if you've convered everything...
• UNIX config files are easily replicated to another box for a poor man's backup/failover situation. I had a 2000 server in a SAN go down and while I could easily mount that boxes disks into another 2000 server, moving the printer and file shares over was a problem because that shit is all stored in the registry. Instead of a simply copy command, I'd either need to write some sort of program to extract and merge into the backup's registry or figure out another way to replicate the shares. Keeping config crap out of a common database means the service isn't tied to a box so much. Need to move it to another box? Install, copy config files, change a virtual DNS name to point to new location.
• Windows registry is horribly insecure, not by design, but implementation. Loads of apps insist on writing per-user stuff to HKLM during runtime. I should be able to make HKLM r/o for all users but if I do that, shit breaks horribly. Damn it, HKLM should only be scribbled into by an application during its install process.

I seem to recall a registry hack that made games think that NT was really 9x and play instead of displaying a simliar message. Perhaps it would help?

See this great NT Registry Page

Here is more info from a different site

How can I bypass "This game require Windows 95" ?
The SETWIN95.CMD program has the ability to make a program think it is running under Windows 95. If a game comes up with a message like "This game requires Windows 95" when you try to run the game, then you can try SETWIN95.CMD on To use SETWIN95 do the follow: Put in the NT 4.0 CD, Copy setwin95.cmd and imagecfg.exe from \support\debug\i386 in your system path. You can use SETWIN95 with setwin95 title.exe.

The following site has some excellent information on taming the Beast that is NT:

Click here for NT registry hacks

There are other sites that go into this as well, such as System Internals, which also provide handy utilities for things like monitoring open files etc.

That's all the pimping I'm going to do for NT today. Back to Linux Mandrake on my laptop :-).