Using Windows logon

  • Thread starter Thread starter Jonathan Blitz
  • Start date Start date
J

Jonathan Blitz

I need to build a logon screen for my Access project.
Is there any way to get to the windows id of the user so that I can ask the
user for his/her windows logon and password and pass it through to the
operating system to be checked.
That way I will not have to manage passwords etc. within my system.

--
Jonathan Blitz
AnyKey Limited
Israel

"When things seem bad
Don't worry and shout
Just count up the times
Things have worked themselves out."
 
Using the code in http://www.mvps.org/access/api/api0008.htm at "The Access
Web", you can get their network ID. Since they've already been
authenticated, do you really need to reauthenticate them?

If so, Randy Birch has sample code at
http://vbnet.mvps.org/code/network/acceptsecuritycontext.htm Note that you
occasionally need to be careful with code from Randy's site: it's intended
for VB programmers, so sometimes the instructions for forms won't work in
Access. However, this particular sample looks as though it should port
without problem.

You do realize, of course, that this won't provide any security: that a user
will still be able to get at your application simply by importing everything
into a new database and commenting out the code that authenticates them?
 
How do I lock a user out of the code?


--
Jonathan Blitz
AnyKey Limited
Israel

"When things seem bad
Don't worry and shout
Just count up the times
Things have worked themselves out."
 
An MDE will prevent them from copying the code, but they'll still be able to
copy the data, queries and macros.

Otherwise, you're going to have to apply full Access security, which means
you will have to maintain separate user IDs and passwords, since Access
doesn't support integrated security.
 
Hi Jonathan,

Thanks for posting in the community.

First of all, I'd thank Douglas for his efforts on your issue. The method to secure Access
project is handy and easy to implement. However, as Douglas mentioned, you should
notice that they won't provide any security if a culprit get at your application simply and re-
perform a database import.

Based on my experience, the security level on the instance may be also a good choice. In
the workgroup information file, you can implement your security mechanism, storing
information on members of a workgroup, including user passwords. Access reads the
workgroup information file when opening a database to determine who is allowed access to
the objects in the database and what permissions they have to those objects. In this way,
you can build a logon screen for your Access project, not on the project level but on the
instance level.

For detailed information on how to Creating Secure Data Access Pages, please read the
following technical article:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnacc2k/html/securedap.asp

To create and join a workgroup information file, please see the Access help topic "Create,
join, or fix workgroup information files"

Jonathan, does this answer your question? Please feel free to post in the group if this solves
your problem or if you would like further assistance.

Best regards,

Billy Yao
Microsoft Online Support
 
Many thanks.

It will take me some time to try all this out.
I will get back to you all if I need any more guidance.

--
Jonathan Blitz
AnyKey Limited
Israel

"When things seem bad
Don't worry and shout
Just count up the times
Things have worked themselves out."
 
Hi Jonathan,

I agree with Douglas that you can use MDE to avoid user out of the code, with which is able
to encapsulate the code and secure it in a safe mode. To follow up, I believe a .MDW file is
also a faithful guarder that ensure your code to be safe.

I'm sure you have read this in another post of you. Here I provide you with the way to secure
a database for distribution as a Run-Time application and not force the users to log on with
a password.

1. Use the Workgroup Administrator program (Wrkgadm.exe) to create a new
workgroup information file (System.mdw).

NOTES: Write down the Name, Organization, and WorkGroup ID strings that you
will be prompted for when creating your new workgroup information file and
store them in a safe place. If your workgroup information file ever becomes
lost or corrupted, you can reconstruct it using these identical strings, which
are then encrypted to create a unique token. Without a valid workgroup
information file, you could conceivably be locked out of your database
forever.

2. The Workgroup Administrator automatically logs you on using the new
workgroup information file. Open the database you wish to secure.

NOTES: The workgroup file stores information about what Groups are available,
the Users' logon passwords, and which Users are members of which Groups. The
database file stores the User and Group permissions.

3. You'll be logged on as a user named Admin. From the Tools Menu, select
Security, then User and Group Accounts to add a password for the Admin user.

NOTES: The Admin user is the default account, and setting its password is what
"activates" security.

4. Create a new "Super" user, which is the account you will use to secure the
database. Add this new user to the Admins group.

NOTES: Write down the strings you use for the name and PID in case you ever
need to recreate your workgroup information file. The PID is not the password
- it is encrypted, along with the Name, to create a unique token identifying
the user.

5. Remove the Admin user from the Admins group so that Admin is a member only
of the Users group.

NOTES: You cannot delete the built-in user (Admin) or groups (Admins, Users).
There must always be at least one user assigned to the Admins group so if you
have not added a user to this group you will not be able to remove the Admin
user from the Admins group.

6. Quit Microsoft Access and log back on as the new *Super* user you created in
step 4. You will not have a password for this account yet, so now is a good
time to set one.

7. Open the database you want to secure and run the Security Wizard. Select the
objects you want to secure (it makes sense to secure them all).

NOTES: The Security wizard will create a new database which will be owned by
your new *Super* user and it will import all of the objects and relationships
into it. It will also remove all permissions from the Admin user and the Users
group and encrypt the new database. The original database will be renamed with
a "bak" extension but will not be altered.

8. Open the new database using the *Super* user login. At this point the
Security Settings should be:

- The Admin user is only a member of the Users group.
- The *Super* user is a member of the Users and Admins groups.
- The Admin user has no permissions.
- The *Super* user has no permissions.
- The Users group has the permissions selected in the Security Wizard.
- The Admins group has full permissions.

9. Assign the permissions you want the users to be able to have to the Admin
User.

10. Remove the password from the Admin User then quit Microsoft Access.

NOTES: This will force the user to log on as the Admin User and will disable
the logon dialog so a password is not needed. This will also prevent the
*Super* user from being able to log on.

In order to be able to perform administrative duties you would need to create
or modify an Access shortcut and add the /USER and /PWD switches to allow the
*Super* user to log on as a member of the Admins Group.

For additional information on this security field, please see the following articles:

289885 ACC2002: Overview of How to Secure a Microsoft Access Database
http://support.microsoft.com/?id=289885

254372 ACC2000: Overview of How to Help Protect a Microsoft Access Database
http://support.microsoft.com/?id=254372

232390 ACC: How to Share a Secured Database on a Network (also apply to Acc2000 and
Acc2002)
http://support.microsoft.com/?id=232390


Jonathan, does that answer your question? Please apply my suggestions above and let
me know if this helps resolve your problem. If there is anything more I can do to assist you,
please feel free to post it in the group

Best regards,

Billy Yao
Microsoft Online Support
 
Well.

Yeah I think that covers it all.

Now I have to go back to the customer and ask him how much security he wants
and thinks is neccessary.
At least now I have all the information I need about what can be done and
how to do it.

--
Jonathan Blitz
AnyKey Limited
Israel

"When things seem bad
Don't worry and shout
Just count up the times
Things have worked themselves out."
"Billy Yao [MSFT]" said:
Hi Jonathan,

I agree with Douglas that you can use MDE to avoid user out of the code, with which is able
to encapsulate the code and secure it in a safe mode. To follow up, I believe a .MDW file is
also a faithful guarder that ensure your code to be safe.

I'm sure you have read this in another post of you. Here I provide you with the way to secure
a database for distribution as a Run-Time application and not force the users to log on with
a password.

1. Use the Workgroup Administrator program (Wrkgadm.exe) to create a new
workgroup information file (System.mdw).

NOTES: Write down the Name, Organization, and WorkGroup ID strings that you
will be prompted for when creating your new workgroup information file and
store them in a safe place. If your workgroup information file ever becomes
lost or corrupted, you can reconstruct it using these identical strings, which
are then encrypted to create a unique token. Without a valid workgroup
information file, you could conceivably be locked out of your database
forever.

2. The Workgroup Administrator automatically logs you on using the new
workgroup information file. Open the database you wish to secure.

NOTES: The workgroup file stores information about what Groups are available,
the Users' logon passwords, and which Users are members of which Groups. The
database file stores the User and Group permissions.

3. You'll be logged on as a user named Admin. From the Tools Menu, select
Security, then User and Group Accounts to add a password for the Admin user.

NOTES: The Admin user is the default account, and setting its password is what
"activates" security.

4. Create a new "Super" user, which is the account you will use to secure the
database. Add this new user to the Admins group.

NOTES: Write down the strings you use for the name and PID in case you ever
need to recreate your workgroup information file. The PID is not the password
- it is encrypted, along with the Name, to create a unique token identifying
the user.

5. Remove the Admin user from the Admins group so that Admin is a member only
of the Users group.

NOTES: You cannot delete the built-in user (Admin) or groups (Admins, Users).
There must always be at least one user assigned to the Admins group so if you
have not added a user to this group you will not be able to remove the Admin
user from the Admins group.

6. Quit Microsoft Access and log back on as the new *Super* user you created in
step 4. You will not have a password for this account yet, so now is a good
time to set one.

7. Open the database you want to secure and run the Security Wizard. Select the
objects you want to secure (it makes sense to secure them all).

NOTES: The Security wizard will create a new database which will be owned by
your new *Super* user and it will import all of the objects and relationships
into it. It will also remove all permissions from the Admin user and the Users
group and encrypt the new database. The original database will be renamed with
a "bak" extension but will not be altered.

8. Open the new database using the *Super* user login. At this point the
Security Settings should be:

- The Admin user is only a member of the Users group.
- The *Super* user is a member of the Users and Admins groups.
- The Admin user has no permissions.
- The *Super* user has no permissions.
- The Users group has the permissions selected in the Security Wizard.
- The Admins group has full permissions.

9. Assign the permissions you want the users to be able to have to the Admin
User.

10. Remove the password from the Admin User then quit Microsoft Access.

NOTES: This will force the user to log on as the Admin User and will disable
the logon dialog so a password is not needed. This will also prevent the
*Super* user from being able to log on.

In order to be able to perform administrative duties you would need to create
or modify an Access shortcut and add the /USER and /PWD switches to allow the
*Super* user to log on as a member of the Admins Group.

For additional information on this security field, please see the following articles:

289885 ACC2002: Overview of How to Secure a Microsoft Access Database
http://support.microsoft.com/?id=289885

254372 ACC2000: Overview of How to Help Protect a Microsoft Access Database
http://support.microsoft.com/?id=254372

232390 ACC: How to Share a Secured Database on a Network (also apply to Acc2000 and
Acc2002)
http://support.microsoft.com/?id=232390


Jonathan, does that answer your question? Please apply my suggestions above and let
me know if this helps resolve your problem. If there is anything more I can do to assist you,
please feel free to post it in the group

Best regards,

Billy Yao
Microsoft Online Support
Click to expand...
 
Hi Jonathan,

How are things going? I am just checking on your progress regarding the information that
was sent you. After you create a Workgroup Information File (.mdw) and set the accounts for
users, whether you can ask them for logon and password. If you encounter any difficulty,
please do not hesitate to let me know.

I would appreciate it if you could post here to let me know the status of the issue. If you have
any questions or concerns, please don't hesitate to let me know. I look forward to hearing
from you, and I am happy to be of assistance.

Thank you,

Billy Yao
Microsoft Online Support
 
Will do so as soon as I get information back from the client.

--
Jonathan Blitz
AnyKey Limited
Israel

"When things seem bad
Don't worry and shout
Just count up the times
Things have worked themselves out."
 
Back
Top