Allow Help Desk to Reset Passwords Without Full Admins Permissions

  • Thread starter Thread starter johntslattery
  • Start date Start date
J

johntslattery

I would like to allow our help desk to reset user passwords but don't
wish them to have the rest of the abilities members of the Admins group
have. Easily enough done if one doesn't mind embedding an Admins member
user name and password in an executable or Access application, but I
would prefer not to do that, perhaps only as a matter of principle in
that I understand user level security is somewhat easily cracked. Are
there permissions that may be added to an MDW and its documents that
will enable just the ability to change a user password without knowing
the old password? Other ideas on the matter would be appreciated, too.
The best I've come up with is encrypting a connection string in
web.config of an ASP .NET application. Thanks for any help!
 
Thisis coveredin the security FAQ (darn spacebar is acting up)

This is covered in the security FAQ:
http://support.microsoft.com/?id=207793

Essentially you distribute a production mdw. Keep your development mdw for
yourself. The production mdw will have a different admins group, which will
be able to reset passwords, but not be able to manage permissions.
 
....That is, the productions admin will be able to manage
permissions by moving people into and out of security
groups, but won't be able to manage permissions directly.
 
Thanks for the response, Joan. Definitely not something I had thought
of, though it does go a bit further than just being able to reset
passwords. Setting up new users is, however, something I have
considered transferring to the security administrators and this
solution would allow it.

The risk and disruption of retroactively implementing this may be too
great, though. If I am not misunderstanding the explanation in the FAQ,
I would need to create a new MDW for production use and duplicate all
of the existing groups, users, and memberships. This, of course, would
mean that each user would have a new password. I'm not sure I'd be able
to successfully pitch changing 600 user passwords.
 
You are correct in that you'd create a new mdw for production and create all
of the existing groups/users/memberships.

Your development mdw wouldn't need to contain any users, save for a few test
users, assuming you manage permissions by group and not by user.

As for the change in passwords, you might be able to make it fly with the
excuse that passwords should be changed periodically <g>
 
There are two ways to make sure you are not distributing
'the admins group used to create the database'

1) Distribute a new MDW, that is not the development MDW.

2) Distribute a new MDB, that was not created using the
MDW everyone has.

Since you have 600 user passwords, I assume that you are
using groups to control security. That means that your new
development MDW has to have the same groups.

You need to create a new development MDW, then re-create
the security groups in it, then setup the default permissions,
then create a new empty database, then import everything
from the old application, then re-assign any other permissions,
then distribute the new application.

That is, you need to either distribute a new production MDW,
OR a new production MDB and a new development MDW.

The important thing is the mismatch between the development
and the production MDW. Either one can be changed. After
either one has been changed, one won't be able to change
permissions controlled by the other.

(david)
 
David, thanks for the post. I apologize for the belated response. (On
vacation.)

Again, as in the case of Joan's post, you've suggested something that
hadn't occurred to me. If it were just a single application, I think my
decision would be made; however, there are about 40 to consider.

I've considered building a tool for cataloging permissions associated
with a database and its containers and documents for later
reapplication. (I think it might be a way to experiment with making
source code control usable and it would figure into a move to a new MDW
that's been discussed here for some time.) With this tool and some
automation, your suggestion would allow me to do this transparently to
the user, except, of course, for the downtime.

Thanks, again. I'll consider it.
 
Back
Top