SUMMARY: [Samba] Samba as PDC with WinXP Clients -> headache!!

[ganapathy murali krishnan]

The way we have it setup is as follows:

Each machine is populated with a "local" startup and shutdown
scripts, and the local Group Policy is modified to activate this.
(Even though I found the registry changes which happen, they alone
are not enough. So I could not automate this with a VBScript or
Python code). These local scripts mount a network share 
(\\sambaserver\netlogon in our case) under guest credentials,
and then execute the "real" startup and shutdown scripts respectively.
Once the real scripts have finished executing the local script cleans
up after itself.

The local machine startup and shutdown scripts run as SYSTEM. This
account is not allowed network access even under guest credentials.
This problem has been solved in many ways. What I do, is to mount the
\\sambaserver\\IPC$ as non-priveleged user. To do this the username and
password must be given there in clear text. Since this user, is only 
allowed to read from the share, this is not a security problem. Once
you have mounted the IPC$ share, you can mount \\sambaserver\netlogon
and then execute the real scripts. Once the real script finishes, we 
have to remove all the network connections including the IPC$ connection
so that when a user logs on, it mounts it using the right credentials 
(may be you mount IPC$ as the user).

Initially debugging is a pain. Since I am unable to become the "SYSTEM" 
user, even using runas (what password?). So in a test machine, I modify 
the group policy and ask it to run the scripts in a console, and not to
terminate the console (default will be to close it after some specified 
timeout). Then in the startup script, run "cmd.exe". That way you are 
the SYSTEM user now. Infact it you run explorer.exe then you see the 
familiar taskbar, desktop... as well the "Press Alt-Ctrl-Del to login" 
dialog (that in itself is a curious sight... using windows explorer, and 
seeinf the Alt-Ctrl-Del message). Using this trick, one can debug the 
startup scripts.

Now you are all set to use it to do some interesting things. The last 
thing our "real" startup script does is to update the "local" shutdown 
script and vice versa. So in case you need to change the local scripts,
you dont have to go around to each machine and do it all over again.

Currently I use the startup scripts to:
1. Stop unnecessary services.
2. synchronise the time
3. Clear all windows print queues (through a VBScript)
4. Make registry changes (not yet implemented but in the works)

I plan to use the shutdown scripts to:
1. Upload drivers for new peripherals to C:\Drivers (or somesuch place)
    and modify the registry, so that windows will look here in
    addition to C:\WINDOWS\INF.
    This way, I drop in the audio driver, and make the registry change,
    next reboot windows sees the new device, and finds a driver for it
    and installs it automatically. This technique will work for all
    peripherals except ofcourse network cards (for obvious reasons)

I plan to use the startup scripts to setup system monitoring software.
Basically setup cron jobs, which run python scripts at specified 
frequency collect data, and update a central database, which has a web 
based (mod_python ofcourse) front end. We already have this working
on Linux,Solaris machines (using PIKT). This will do it on Windows 
machines as well.

I do not know enough about how group policies work. So I havent tried 
anything. I was thinking in terms of NT4 System Policies. But if as you
say I can create a group policy file and store it on a network location,
then all I have to do at machine startup is to activate the settings.
I dont know how to do it. If somebody can tell me it would be useful.

Since I am going on a loong vacation, I wont be able to test these 
things out soon.

Do you need any more information?

- Murali

Daniel Zeiss wrote:
> Hello Murali,
> 
>> One other idea: Nobody seems to be interested in machine level,
>> startup and shutdown scripts (not user logon and logoff scripts).
> 
> 
> I am very interested in that since this would be the possibility of 
> implementing the Active Directory stuff the other way around.
> Imagine on startup the machine would execute a script which executes a 
> script from netlogon share.
> This last script then decides on which machine it is running, which 
> gpedit.msc file it should copy from the server and like this you can 
> distribute group policies like ADS can do.
> 
> No need for ADS anymore ;-)
> 
>> script, using local Group Policies (tried with just registry changes
>> did not work). These local scripts just mount a network share
>> and execute the real startup and shutdown scripts.
> 
> 
> Will you try more? I would love to hear your successes. :-)
> 
> bye
> Daniel
> 
>