Roving Configurations
---------------------

The scheme described in this file is basically that suggested to me
by Kees Koenders. It allows a user to move from client machine
to client machine, and to get the same access on each. In addition,
it means that the password passed to dialmon when logging in does
not have to be left in a file on a client machine, where it is
probably free for all to see (even if it does not give shell access to
the Linux box). Essentially, authentication is handled by the Windows
box's login mechanism, and the dialm client configuration is derived
from the logged in user.

The description here assumes that (a) you have Samba running on the
Linux box and that (b) each user to whom you want to give roving access
is a real user on the Linux box. By real user, I mean that they have
an entry in the password file, although they need not actually have
login access.

First, create a directory on the Linux box, say /etc/dialmon, and in
it create a file called <username>.ini for each user that you want to
give roving access. Each such file can initially be empty, should be
owned by the user (and have suitable group ownership). The files
should be read-write owner, but have no group nor other access.

Second, create a Samba share called, say, dialmon, which maps to the
directory created above. The share should be accessible by all users
that are getting roving access. You will need to restart smb to make
the new share visible on the network. My entry looks like:

---------
[dialmon]
    comment = DialMon user configurations
    path = /etc/dialmon
    valid users = mike beacon tina
    public = no
    writable = yes
    printable = no
---------

Thirdy, go to a client machine, and assign a drive letter to the
share that you just created, for example G. Then, assuming that
the dialm client is invoked by a shortcut (probably via the STartUp
folder), change it so that dialm is started with the single argument
G: (or whatever). Note that the : is neccessary, G on its own will not
work. This needs to be done on each client machine.

Now run or restart the dialm client. When it starts up, it looks for
a file "G:\<username>.ini" where the username is that of the user
who is currently logged on to windows. If it can open this file for
reading, then it is used as the configuration file; if not then
it falls back on the default file (typically c:\windows\dialmon.ini).
The first time that the client uses a network configuation, the
configuration dialog will appear, and should be filled in in the
normal way.

Hence, if the logged on user is one of your roving users, then they
will get the configuration from the Linux box. Other users will end
up with the local configuration. These can probably be set up not to
log on to dialmon, since they probably only need the default access
allowed by dialmon. Further, since the roving users' configuration
files are owned by themselves, and can only be read by them, nobody
else can see their dialmon passwords (and, roving users cannot see
each others passwords, if paranoia extends that far).

It should be possible to do this without having to assign a drive letter.
If the argument to the dialm client does not have a colon as its
second character, then the name \\<argument>\dialmon\<username>.ini is
generated instead. Unfortunately, this does not seem to work until
some other windows program has touched the file, as if the share is
not properly mapped at first. Does anyone known what I might need to
put into my code to fix this?

There are some other possibilities.

It should be possible to lock down a roving user's configuration file
so that they cannot change it, provided that they do not have login
access to the Linux box. Once their configuration file is set up, use
the chattr command to make the file immutable.

Samba need not actually run on the same machine as the dialmon daemon,
and a Windows NT server could presumably be used instead. However, I
have no way of testing this, nor is it likely that I will (or, even,
would wish to).

Roving users could probaby be grouped onto configuration files by
creating suitable groups, and setting appropriate ownerships and
permissions on the configuration files. You could then have, say,
super-administrators who could do stuff like block and restart diald;
normal administrators who can take the link down; and the rest of
the troops who can only watch what is going on.

Many thanks again to Kees Koenders for the original suggestion.
