Administrator and other users...

  • Thread starter Thread starter Fenster
  • Start date Start date
F

Fenster

I would like to make user accounts on my XPe system, which is CF-based,
but it just occurred to me: how do they set their own passwords if the
"disk" is write-filter protected? Or is this not possible? Or are
passwords saved to an unprotected part of the "disk" on the basis that
they are unlikely to be changed anywhere near as often as the write
cycle limit of the CF?
 
Fenster,
I would like to make user accounts on my XPe system, which is CF-based, but it just occurred to me: how do they set their own
passwords if the "disk" is write-filter protected?
Click to expand...

Typically user scenerios on images with protected OS are the responsibility of whoever designs the image.
In other words, you either should pre-setup all user passwords upfront or have an administrator setting the password for an user at
run time and commiting the change.

Also, you cpuld move NTUSER.DAT (user registry hive) to an unprotected partition if change any user settings can be persistent on
your target device (I mean if this is acceptable for your system specs). Frankly, I never tried this approach to fix user password
issues. Moreover, I don't think it is going to work jus tlike that becuase there is also SAM database (security hive) that is also
related to the user password changes.
However, you may give it a try if the password issue is critical to fix on your system.

Another solution that might be interesting to you is to use File Based Write Filter (FP2007). With it you can unprotect user
registry hives and, if necessary, the system and security hives, without moving them to another unprotected volume.
Or is this not possible?
Click to expand...

Nothing is impossible. However, please keep in mind that Windows XP wasn't designed specifically to fit in embedded space. Therefore
XPe got some legacy such as many system and user level settings (and especially security related settings) are really hard to
isolate from the OS itself. Therefore you can't move them (easily) to an unprotected area - another disk, partition, or etc.

One of possible solutions for changing such settings at user level (without permissions to commit the change) is to come up with a
custom GUI that will allow to enter the settings and save them to a file (even an encrypted file) that stays on an unprotected
volume. Then you can have a service level app (service that starts before the user logon) that will read the file and apply new
settings via WIn32 API. This way you can trick the Windows and Filter. I realize though this appraoch may take some time to be
implemented.
Or are passwords saved to an unprotected part of the "disk" on the basis that they are unlikely to be changed anywhere near as
often as the write cycle limit of the CF?
Click to expand...

Sorry, couldn't make a sense out of this.
 
KM said:
Fenster,


Typically user scenerios on images with protected OS are the
responsibility of whoever designs the image.
In other words, you either should pre-setup all user passwords upfront
or have an administrator setting the password for an user at
run time and commiting the change.

Also, you cpuld move NTUSER.DAT (user registry hive) to an unprotected
partition if change any user settings can be persistent on
your target device (I mean if this is acceptable for your system
specs). Frankly, I never tried this approach to fix user password
issues. Moreover, I don't think it is going to work jus tlike that
becuase there is also SAM database (security hive) that is also
related to the user password changes.
However, you may give it a try if the password issue is critical to fix
on your system.

Another solution that might be interesting to you is to use File Based
Write Filter (FP2007). With it you can unprotect user
registry hives and, if necessary, the system and security hives,
without moving them to another unprotected volume.


Nothing is impossible. However, please keep in mind that Windows XP
wasn't designed specifically to fit in embedded space. Therefore
XPe got some legacy such as many system and user level settings (and
especially security related settings) are really hard to
isolate from the OS itself. Therefore you can't move them (easily) to
an unprotected area - another disk, partition, or etc.

One of possible solutions for changing such settings at user level
(without permissions to commit the change) is to come up with a
custom GUI that will allow to enter the settings and save them to a
file (even an encrypted file) that stays on an unprotected
volume. Then you can have a service level app (service that starts
before the user logon) that will read the file and apply new
settings via WIn32 API. This way you can trick the Windows and Filter.
I realize though this appraoch may take some time to be
implemented.


Sorry, couldn't make a sense out of this.
Click to expand...
What I meant here was that one of reasons for using EWF with CF drives
is because they have a limited amount of write cycles before they give
the ghost. Windows being what it is this limit would soon be reached
and the CF wrecked. Passwords on the other hand are unlikely to be
changed often enough during the life of a system to damage the CF by
writing the password file to CF, assuming passwords could be written to
unprotected volumes (as you discussed).

Thanks for your thoughts, they given me something to look into and have
a think about.

F.
 
Back
Top