Help!: Problems with Restricted access accounts

[Rich]

Hopefully someone here can point me in the right direction.

My company develops a product used by the healthcare industry. This
application was designed with a multi-tiered architecture; having a
series of business object DLLs that need to be registered on each local
machine to allow proper communications with our server.

Hospitals unfortunately tend not to be on the bleeding edge of technology
(with respect to their office computers) so our clients workstations
range from Windows 95 to Windows XP. Due to this, we are not able to
develop our application "for Windows XP".

Due to HIPAA Security regulations, the IT staffs tend to really clamp
down on user security; we have experienced users not having permissions
to create files under Program Files, not being able to access the
Internet, and not being able to install applications that require any
reading from/writing to the registry. Because of this, we are often
forced to install our product as an Administrator. When the user next
logs in, our product is properly registered and everything works fine.

Recently we encountered a problem on Windows XP systems - these all have
SP2, although I don't know for sure if that is part of the problem or
not.

Our clients have their users set up as Restricted user accounts. This
prevents us from installing as the user (no rights to register DLLs) so
we try our usual installation as an Administrator. As a test, the
administrator account runs our product and it works fine. However, when
the user tries again as a restricted access user account, problems result
- basically, the user is prevented from running our application. It
seems that the user is unable to "see" the DLL entries in the registry.

We have code in place to verify our business objects are registered
before allowing the user to proceed with the login process. Our check,
which essentially verifies the existance of our DLLs somewhere under the
TypeLib node of HKEY_CLASSES_ROOT, correctly locates the DLLs for Admin
and PowerUser accounts but for Restricted access accounts it comes up
empty on these WinXP systems. Since the registry has obviously not
changed, we assume that permissions are the problem.

If we give the user local admin rights, the problem goes away. However,
permissions on the client's network are managed by the client and are out
of our control. And they are reluctant to make changes just to allow our
product to work.

I also tried using "RunAs /profile /user:Administrator programname.exe".
This also allowed a Restricted access user to use our system.
Unfortunately, it pops up a dialog requesting an Administrator password -
this is something the users are not going to have access to.

I saw a post not long ago here inquiring about Admin rights for a single
program so I know others out there are having similar problems. How are
all of you getting around this?

Is it possible to execute RunAs silently? Perhaps passing the password
on the commandline so the user never sees the RunAs dialog? Inelegant as
it is, this would solve my immediate problems.

Is there another way to allow a Restricted access account to simply view
and read DLLs that are registered? My application does NOT require the
user to have write access.

Any help would be greatly appreciated.

Thanks in advance.

Regards,

Rich Ackerson

 

[Leythos]

Our clients have their users set up as Restricted user accounts. This
prevents us from installing as the user (no rights to register DLLs) so
we try our usual installation as an Administrator. As a test, the
administrator account runs our product and it works fine. However, when
the user tries again as a restricted access user account, problems result
- basically, the user is prevented from running our application. It
seems that the user is unable to "see" the DLL entries in the registry.

Microsoft can direct you to the PROPER CODING PRACTICES for secure
environments. Restricted users can still write to the registry, just not
where you're wanting to write too.

There are many solutions to your problem, but, my guess would be that
since you've been doing it wrong for so long that it's going to cost a
lot to rework the apps to properly comply with normal security settings
on workstations.

I've seen this many times, even Quickbooks has this issue, and so do
many developers/companies that didn't see this coming - security is
going to be here for a long time, get use to the proper way of coding.

If you are not already an ISV or Microsoft Partner you should join and
then you can call them for help.

 

[Rich]

Leythos,

Thanks for the reply. I guess I should have worded my initial query a
bit differently.

Microsoft can direct you to the PROPER CODING PRACTICES for secure
environments. Restricted users can still write to the registry, just
not where you're wanting to write too.

I completely understand why a restricted account would not be able to
WRITE to portions of the registry and I believe that HKEY_CURRENT_USER is
generally open to even a restricted account. It doesn't take a genius to
grasp that. But that is not the question I was asking. I am curious why
we cannot READ data that is already there.

There are many solutions to your problem,

Stating one solution would be very welcome. For instance, my quesiton
about running RunAs silently. Is it possible?

but, my guess would be that
since you've been doing it wrong for so long that it's going to cost a
lot to rework the apps to properly comply with normal security
settings on workstations.

True, our handling of the registry needs to be changed and reworking our
application is going to take a sizeable amount of time. However, "normal
security settings on workstations" is a bit of a vague term. As I
indicated in my initial post, our application runs on Windows 9x
workstations as well as Windows 2000 and XP. True, the modern flavors of
Windows have a more precise security system in place, but the older ones
do not. So, if we've been "doing it wrong" for so long, its only because
WINDOWS did it wrong for so long.

I've seen this many times, even Quickbooks has this issue, and so do
many developers/companies that didn't see this coming - security is
going to be here for a long time, get use to the proper way of coding.

Trust me, as someone who has to deal with HIPAA and its over-the-top
security regulations for a living, you don't have to lecture me on
security. And please forgive me for thinking I should be able to use
REGSVR32 to register a DLL in Windows and then have that DLL be
accessible. What was I thinking?

If you are not already an ISV or Microsoft Partner you should join and
then you can call them for help.

Thanks for the advice.

 

[Leythos]

Leythos,

Thanks for the reply. I guess I should have worded my initial query a
bit differently.
I completely understand why a restricted account would not be able to
WRITE to portions of the registry and I believe that HKEY_CURRENT_USER is
generally open to even a restricted account. It doesn't take a genius to
grasp that. But that is not the question I was asking. I am curious why
we cannot READ data that is already there.


Stating one solution would be very welcome. For instance, my quesiton
about running RunAs silently. Is it possible?

Recode your application to make use of the Windows XP and 2000 User
Level access restrictions. Sure, it's not going to work for 98/95/Me,
but it means that your application will also work with Vista if you
follow the User Level norms as documented by MS.

We never use Run/As, so I can't answer that one.

True, our handling of the registry needs to be changed and reworking our
application is going to take a sizeable amount of time. However, "normal
security settings on workstations" is a bit of a vague term. As I
indicated in my initial post, our application runs on Windows 9x
workstations as well as Windows 2000 and XP. True, the modern flavors of
Windows have a more precise security system in place, but the older ones
do not. So, if we've been "doing it wrong" for so long, its only because
WINDOWS did it wrong for so long.

A User Level account CAN read the registry, just not where you've
decided to place your information.

Trust me, as someone who has to deal with HIPAA and its over-the-top
security regulations for a living, you don't have to lecture me on
security. And please forgive me for thinking I should be able to use
REGSVR32 to register a DLL in Windows and then have that DLL be
accessible. What was I thinking?

LOL, we design medical centers and their networks, HIPAA makes us a LOT
of money. We also have to deal with developers that don't code to the
secure way, they still code like it was windows 95/98 and don't pay
attention to the restrictions - they don't teach that in schools you
have to be kicked in the arse by it a few times to learn it

Thanks for the advice.

The ISV program is great for getting free help/info on methods and even
5 free MSDN Universal Subscriptions. You just have to comply with their
requirements.

 

[Rich]

Recode your application to make use of the Windows XP and 2000 User
Level access restrictions. Sure, it's not going to work for 98/95/Me,
but it means that your application will also work with Vista if you
follow the User Level norms as documented by MS.

That is our problem in a nutshell. The majority of our users still use
Win95/98. That is why we don't code "properly". It's not by choice, its
by necessity. Worse still, some customers have a mixed bag of OS's; with
XP and 9x systems being used side-by-side.

No software shop can seriously hope to market their product by opening
with the line "First you have to upgrade all of your hardware...". So
what do the options become then? Market two separate versions of the
product? That would be a logistical nightmare.

A User Level account CAN read the registry, just not where you've
decided to place your information.

But again, we didn't decide WHERE to place the entry; REGSVR32 did. Is
there another way to register a DLL in Windows that allows me to place it
where I want? This is the only thing we use the registry for.

LOL, we design medical centers and their networks, HIPAA makes us a
LOT of money. We also have to deal with developers that don't code to
the secure way, they still code like it was windows 95/98 and don't
pay attention to the restrictions - they don't teach that in schools
you have to be kicked in the arse by it a few times to learn it

And then there are the developers who code like it was Win 9x because for
their clients, IT STILL IS. Regardless of what anyone says, customers
just want to get their job done; they don't give a c**p about having the
latest version of Windows to do it. Win 2K/XP and Vista may be the best
thing to ever happen to computers, but if a client doesn't want to spend
the money to have them and they decide to stick with Windows 95 what are
you supposed to do? In our case, we had a client base that was happy on
Win98 across-the-board. Then someone got a new computer pre-loaded with
WinXP SP2. When they tried to run our product it didn't work.

Please tell me, what would your suggestion be to the client.
1) Tell him to purchase 100 more workstations to upgrade the rest of his
staff so we can put them all on a WinXP-friendly version of the product?
2) Tell him to downgrade his fancy new workstation so our product will
run? (clients really DON'T like to hear that)
3) Drop them as a client because they are stirring up the waters and
causing the product not to run?

Sorry, but the point I am trying to make is it is very easy to state we
simply decided to ignore restrictions and didn't code properly. The fact
of the matter is we coded according to the restrictions placed on us by
our target market. Just like in the old days we couldn't develop 32 bit
Windows apps for DOS systems, today we can't develop an application based
on the Win2K User Level access restrictions and expect it to be properly
supported on our existing Win9x installations.
(But I do agree with you about the getting kicked in the arse part.)

The ISV program is great for getting free help/info on methods and
even 5 free MSDN Universal Subscriptions. You just have to comply with
their requirements.

May have to look into this.

 

[Robert Stradelski]

I saw a post not long ago here inquiring about Admin rights for a single
program so I know others out there are having similar problems. How are
all of you getting around this?

To run only a single program with admin rights and not to enter a password
try runasspc on:
http://www.robotronic.de/runasspcEn.html
to start this runas tool silently use it with the following options:
runasspc.exe /cryptfile:"path\NameOfCryptfile.spc"

bye

 

[Rich]

To run only a single program with admin rights and not to enter a
password try runasspc on:
http://www.robotronic.de/runasspcEn.html
to start this runas tool silently use it with the following options:
runasspc.exe /cryptfile:"path\NameOfCryptfile.spc"

bye

Thank you very much and have a very Merry Christmas!

Rich

 

[Guest]

...

I also tried using "RunAs /profile /user:Administrator programname.exe".
This also allowed a Restricted access user to use our system.
Unfortunately, it pops up a dialog requesting an Administrator password -
this is something the users are not going to have access to.

I saw a post not long ago here inquiring about Admin rights for a single
program so I know others out there are having similar problems. How are
all of you getting around this?

Is it possible to execute RunAs silently? Perhaps passing the password
on the commandline so the user never sees the RunAs dialog? Inelegant as
it is, this would solve my immediate problems.

I'd be stunned if they'd allow that!

Is there another way to allow a Restricted access account to simply view
and read DLLs that are registered? My application does NOT require the
user to have write access.

I'd strongly suggest modifying the permissions on the registry keys invloved
- this can be done as part of the administrative installation process.

While you should know exactly which keys are being accessed I am aware that
with legacy applications such information might become 'lost' or poorly
documented in which case RegMon would be a useful tool.

While modifying the registry permissions should ideally be done as part of
the install it is possible to push them out after the install (at least to
Windows XP; I can't recall if there are any caveates for Windows 2000).

Once you have confirmed the keys that need to be altered you can push the
registry modifications via a Group Policy Object (GPO). This can be done via
the Computer section of a GPO:
Computer Configuration > Windows Settings > Security Settings > Registry