> 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!

"Joan Wild" <jwild@nospamtyenet.com> wrote in message
news:uVBFAIhzGHA.476@TK2MSFTNGP06.phx.gbl...
> 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.
>
>
> --
> Joan Wild
> Microsoft Access MVP
>
> johntslatt***@gmail.com wrote:
> > 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.
>
>
> --
> Joan Wild
> Microsoft Access MVP
>
> johntslatt***@gmail.com wrote:
> > 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!

> 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.
>
> Joan Wild wrote:
>> 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.
>>
>>
>> --
>> Joan Wild
>> Microsoft Access MVP
>>
>> johntslatt***@gmail.com wrote:
>>> 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!

news:1157634752.157909.240350@i3g2000cwc.googlegroups.com...
> 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.
>
> Joan Wild wrote:
> > 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.
> >
> >
> > --
> > Joan Wild
> > Microsoft Access MVP
> >
> > johntslatt***@gmail.com wrote:
> > > 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!
>

> 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)
>
>
>
>
> <johntslatt***@gmail.com> wrote in message
> news:1157634752.157909.240350@i3g2000cwc.googlegroups.com...
> > 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.
> >
> > Joan Wild wrote:
> > > 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.
> > >
> > >
> > > --
> > > Joan Wild
> > > Microsoft Access MVP
> > >
> > > johntslatt***@gmail.com wrote:
> > > > 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!
> >