ANNOUNCE: Utility to set permissions on registry in profiles (was
RE: Upgrading PDC)
Mayers, P J
p.mayers at ic.ac.uk
Sun Nov 28 16:35:22 GMT 1999
Ok, after being sufficiently persuaded... :o)
I just finished up v0.1 of a utility I call regsec. If anyone has a site I
can put this on for download, that would be cool.
The utility basically does the following:
1) Uses RegLoadKey to load the registry portion of the profile (ntuser.dat)
2) Sets the permissions to a given username (Full Control)
3) Unloads it
This will *only* be useful if you have a situation such as the following:
1) A users RID changes for some reason
2) A domain SID changes (reinstalling a PDC for example)
3) The permissions on the profile get trashed (non-samba, but we have it
here at IC)
...And you don't want to recreate the profile from scratch losing all the
Since some of you seem to think that you have this problem, I wrote the
utility. It's about 400 lines of (sort-of commented code) and has to be run
in the following manner.
1) On a WinNT machine
2) Logged on as someone who has SeRestoreName privileges (Administrators
It does not run from unix, and will not (unless Luke implements
RegConnectRegistry and RegLoadKey RPC calls in rpcclient, and even then
you'll need an NT box).
To: Mayers, P J
Sent: 11/27/99 2:50 PM
Subject: RE: Upgrading PDC
<persuade> beer </persuade>
Norman R. McBride
Computing Services, City University, England norm at city.ac.uk
"...the extreme case best illustrates the norm..." Stephen
On Mon, 22 Nov 1999, Mayers, P J wrote:
> It should be possible to write a smallish win32 program that calls
> RegLoadHive, loading the binary ntuser.dat file, then setting the ACL
> that entire hive, and unloading it again. It ought to be about 50
> of code (ish).
> If anyone is really interested and can't write this themselves, I
> be persuaded to have a look.
> And no, it's not possible to have a unix based solution. The program
> would have to run under NT.
> -----Original Message-----
> From: Dave.Stevenson at durham.ac.uk
> To: Multiple recipients of list SAMBA-NTDOM
> Sent: 11/22/99 10:59 AM
> Subject: Re: Upgrading PDC
> I can relate to this. Same thing, had a 1 year old Samba PDC operating
> then tried
> upgrade. Profiles will NOT work with new PDC. Seems something to do
> SID's generated, fraid I dont know enough to relate details but
> to say
> that it is necessary to remove all roaming profile registry settings
> (NTUSER.DAT) and generate new ones to avoid the "unknown user" and
> registry setting permission denied business.
> Caused mucho raised blood pressure here, compounded by the fact that
> many users
> also had locally (cached) profiles.
> I developed a solution using registry files to store user's settings.A
> web based
> form allows users to set up simplified preferences for common
> a series of template registry (and INI ) files all bound together with
> of perl scripts on an intranet server.
> Then I deleted all users NTUSER.DAT files from their profiles (as they
> logged off)
> When they logged on again they were presented with a form to setup
> A UNIX perl script generates a .reg file and a number of INI/JS files
> a public
> directory. A second script is invoked on the local workstation (by
> button press)
> that runs as the user to install the reg settings etc.
> It's dirty but it works. Took almost two/three weeks for all users to
> filter through
> the reset process.
> An alternative that would dump existing registry settings, INI and JS
> files would be trivial
> to produce and would offer a safety net for those users whose profiles
> keep reverting
> to default User or Default User(network) due to various network, MS,
> Happy to share experiences and scripts if you want em
> There must be an easier way ( changing SID?? ) I know it's possible to
> change workstation
> SID's (NewSID program) but dont know enough to say If same is possible
> user ID's . I recall that there may be something in the NT server
> resource kit??
> > We've been using a version of the PDC code for... blimey, must be
> nearly a
> > year and a half now, with over 200 satisfied users. Now we're
> > upgrade to a much more recent version, so that we can take advantage
> of all
> > of the new-fangled features such as networked administrator
> > Anyway, upon testing a recent copy of the HEAD branch, it all worked
> > apart from one teensy problem. Accounts would log in, download
> > roaming profile, and categorically refuse to load in the registry
> > for that user. So the logon.bat which maps their drives complains
> > changes could not be saved, and they don't get their nice colours,
> fonts, et
> > cetera.
> > Is this because of a change in the way Samba is coded, or is it a
> > issue with a simple solution? Having to tell 200+ users that
> > their registry when we upgrade is not something I'm looking forwards
> > obviously. :)
> > Norman R. McBride
> > Computing Services, City University, England
norm at city.ac.uk
> > "...the extreme case best illustrates the norm..."
> Stephen King
More information about the samba-ntdom