&author.jht;
June 15 2005Advanced Network Managementaccess control
This section documents peripheral issues that are of great importance to network
administrators who want to improve network resource access control, to automate the user
environment, and to make their lives a little easier.
Features and Benefits
Often the difference between a working network environment and a well-appreciated one can
best be measured by the little things that make everything work more
harmoniously. A key part of every network environment solution is the ability to remotely
manage MS Windows workstations, remotely access the Samba server, provide customized
logon scripts, as well as other housekeeping activities that help to sustain more reliable
network operations.
This chapter presents information on each of these areas. They are placed here, and not in
other chapters, for ease of reference.
Remote Server AdministrationHow do I get User Manager and Server Manager?User ManagerServer ManagerEvent Viewer
Since I do not need to buy an NT4 server, how do I get the User Manager for Domains
and the Server Manager?
Nexus.exeWindows 9x/Me
Microsoft distributes a version of these tools called Nexus.exe for installation
on Windows 9x/Me systems. The tools set includes:
Server ManagerUser Manager for DomainsEvent Viewer
Download the archived file at the Microsoft Nexus link.
SRVTOOLS.EXEUser Manager for DomainsServer Manager
The Windows NT 4.0 version of the User Manager for
Domains and Server Manager are available from Microsoft
via ftp.
Remote Desktop Managementremote desktop managementnetwork environment
There are a number of possible remote desktop management solutions that range from free
through costly. Do not let that put you off. Sometimes the most costly solution is the
most cost effective. In any case, you will need to draw your own conclusions as to which
is the best tool in your network environment.
Remote Management from NoMachine.ComNoMachine.Com
The following information was posted to the Samba mailing list at Apr 3 23:33:50 GMT 2003.
It is presented in slightly edited form (with author details omitted for privacy reasons).
The entire answer is reproduced below with some comments removed.
remote desktop capabilities
I have a wonderful Linux/Samba server running as PDC for a network. Now I would like to add remote
desktop capabilities so users outside could login to the system and get their desktop up from home or
another country.
Windows Terminal serverBDCPDCremote login
Is there a way to accomplish this? Do I need a Windows Terminal server? Do I need to configure it so
it is a member of the domain or a BDC or PDC? Are there any hacks for MS Windows XP to enable remote login
even if the computer is in a domain?
Answer provided: Check out the new offer of NX software from
NoMachine.
Remote X protocolVNC/RFBrdesktop/RDP
It implements an easy-to-use interface to the Remote X protocol as
well as incorporating VNC/RFB and rdesktop/RDP into it, but at a speed
performance much better than anything you may have ever seen.
modem/ISDN
Remote X is not new at all, but what they did achieve successfully is
a new way of compression and caching technologies that makes the thing
fast enough to run even over slow modem/ISDN connections.
KDE konquerormouse-overrdesktop
I test drove their (public) Red Hat machine in Italy, over a loaded
Internet connection, with enabled thumbnail previews in KDE konqueror,
which popped up immediately on mouse-over. From inside that (remote X)
session I started a rdesktop session on another, a Windows XP machine.
To test the performance, I played Pinball. I am proud to announce
that my score was 631,750 points at first try.
NXTightVNCrdesktopRemote X
NX performs better on my local LAN than any of the other pure
connection methods I use from time to time: TightVNC, rdesktop or
Remote X. It is even faster than a direct crosslink connection between
two nodes.
Remote XKDE sessioncopy'n'paste
I even got sound playing from the Remote X app to my local boxes, and
had a working copy'n'paste from an NX window (running a KDE session
in Italy) to my Mozilla mailing agent. These guys are certainly doing
something right!
I recommend test driving NX to anybody with a only a passing interest in remote computing
the NX utility.
Just download the free-of-charge client software (available for Red Hat,
SuSE, Debian and Windows) and be up and running within 5 minutes (they
need to send you your account data, though, because you are assigned
a real UNIX account on their testdrive.nomachine.com box).
They plan to get to the point were you can have NX application servers
running as a cluster of nodes, and users simply start an NX session locally
and can select applications to run transparently (apps may even run on
another NX node, but pretend to be on the same as used for initial login,
because it displays in the same window. You also can run it
full-screen, and after a short time you forget that it is a remote session
at all).
GPL
Now the best thing for last: All the core compression and caching
technologies are released under the GPL and available as source code
to anybody who wants to build on it! These technologies are working,
albeit started from the command line only (and very inconvenient to
use in order to get a fully running remote X session up and running).
To answer your questions:
You do not need to install a terminal server; XP has RDP support built in.
NX is much cheaper than Citrix &smbmdash; and comparable in performance, probably faster.
You do not need to hack XP &smbmdash; it just works.
You log into the XP box from remote transparently (and I think there is no
need to change anything to get a connection, even if authentication is against a domain).
The NX core technologies are all Open Source and released under the GPL &smbmdash;
you can now use a (very inconvenient) command line at no cost,
but you can buy a comfortable (proprietary) NX GUI front end for money.
OSS/Free SoftwareLTSPKDEGNOMENoMachine
NoMachine is encouraging and offering help to OSS/Free Software implementations
for such a front-end too, even if it means competition to them (they have written
to this effect even to the LTSP, KDE, and GNOME developer mailing lists).
Network Logon Script Magic
There are several opportunities for creating a custom network startup configuration environment.
No Logon Script.Simple universal Logon Script that applies to all users.Use of a conditional Logon Script that applies per-user or per-group attributes.Use of Samba's preexec and postexec functions on access to the NETLOGON share to create
a custom logon script and then execute it.User of a tool such as KixStart.
The Samba source code tree includes two logon script generation/execution tools.
See examples directory genlogon and
ntlogon subdirectories.
The following listings are from the genlogon directory.
genlogon.pl
This is the genlogon.pl file:
#!/usr/bin/perl
#
# genlogon.pl
#
# Perl script to generate user logon scripts on the fly, when users
# connect from a Windows client. This script should be called from
# smb.conf with the %U, %G and %L parameters. I.e:
#
# root preexec = genlogon.pl %U %G %L
#
# The script generated will perform
# the following:
#
# 1. Log the user connection to /var/log/samba/netlogon.log
# 2. Set the PC's time to the Linux server time (which is maintained
# daily to the National Institute of Standards Atomic clock on the
# internet.
# 3. Connect the user's home drive to H: (H for Home).
# 4. Connect common drives that everyone uses.
# 5. Connect group-specific drives for certain user groups.
# 6. Connect user-specific drives for certain users.
# 7. Connect network printers.
# Log client connection
#($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
open LOG, ">>/var/log/samba/netlogon.log";
print LOG "$mon/$mday/$year $hour:$min:$sec";
print LOG " - User $ARGV[0] logged into $ARGV[1]\n";
close LOG;
# Start generating logon script
open LOGON, ">/shared/netlogon/$ARGV[0].bat";
print LOGON "\@ECHO OFF\r\n";
# Connect shares just use by Software Development group
if ($ARGV[1] eq "SOFTDEV" || $ARGV[0] eq "softdev")
{
print LOGON "NET USE M: \\\\$ARGV[2]\\SOURCE\r\n";
}
# Connect shares just use by Technical Support staff
if ($ARGV[1] eq "SUPPORT" || $ARGV[0] eq "support")
{
print LOGON "NET USE S: \\\\$ARGV[2]\\SUPPORT\r\n";
}
# Connect shares just used by Administration staff
If ($ARGV[1] eq "ADMIN" || $ARGV[0] eq "admin")
{
print LOGON "NET USE L: \\\\$ARGV[2]\\ADMIN\r\n";
print LOGON "NET USE K: \\\\$ARGV[2]\\MKTING\r\n";
}
# Now connect Printers. We handle just two or three users a little
# differently, because they are the exceptions that have desktop
# printers on LPT1: - all other user's go to the LaserJet on the
# server.
if ($ARGV[0] eq 'jim'
|| $ARGV[0] eq 'yvonne')
{
print LOGON "NET USE LPT2: \\\\$ARGV[2]\\LJET3\r\n";
print LOGON "NET USE LPT3: \\\\$ARGV[2]\\FAXQ\r\n";
}
else
{
print LOGON "NET USE LPT1: \\\\$ARGV[2]\\LJET3\r\n";
print LOGON "NET USE LPT3: \\\\$ARGV[2]\\FAXQ\r\n";
}
# All done! Close the output file.
close LOGON;
Those wishing to use a more elaborate or capable logon processing system should check out these sites:
http://www.craigelachie.org/rhacer/ntlogonhttp://www.kixtart.orgAdding Printers without User Interventionrundll32
Printers may be added automatically during logon script processing through the use of:
&dosprompt;rundll32 printui.dll,PrintUIEntry /?
See the documentation in the Microsoft Knowledge Base article 189105.
Limiting Logon Connections
Sometimes it is necessary to limit the number of concurrent connections to a
Samba shared resource. For example, a site may wish to permit only one network
logon per user.
The Samba preexec script parameter can be used to permit only one
connection per user. Though this method is not foolproof and may have side effects,
the following contributed method may inspire someone to provide a better solution.
This is not a perfect solution because Windows clients can drop idle connections
with an auto-reconnect capability that could result in the appearance that a share
is no longer in use, while actually it is. Even so, it demonstrates the principle
of use of the preexec script parameter.
The following share configuration demonstrates use of the script shown in .
[myshare]
...
preexec script = /sbin/PermitSingleLogon.sh
preexec close = Yes
...
Script to Enforce Single Resource Logon
#!/bin/bash
IFS="-"
RESULT=$(smbstatus -S -u $1 2> /dev/null | awk 'NF > 6 {print $1}' | sort | uniq -d)
if [ "X${RESULT}" == X ]; then
exit 0
else
exit 1
fi