Security Permissions for New User

[GeekGirlau]

I've made the erroneous assumption that when you create a new user in a secure database and add them to specific groups, they inherit all the permissions for those groups. However what I'm finding is that the user doesn't automatically have permission to open the database object, even if they belong to groups that do.

Is this correct? Do I need to manually set the permissions for each individual user after assigning them to groups? Do I need to set the permission for only the database object, or for all existing objects within the database?

I need to set up several secure databases to be able to be maintained by non-programmers, so I need to give certain users the ability to create new users with as little human intervention as possible.

 

[AccessGuru]

Well, if we follow the steps to secure a database, users belong to no groups except the Users group which is compulsory.

If you create a new group, let us call it Staff, make sure it can open the database, and make users belong to that. THat way when you programmatically create a new user he/she must be added to belong to the Users and Staff group.

That should work. Also, the PID should be identical for each user of the same name in different databases you create for multidatabase access.

 

[GeekGirlau]

You'd think so wouldn't you. However it doesn't work that way.

I'm using a single .MDW file for multiple databases. There are a few groups, each of which has varying permissions for various databases.

If I add a new user and add it to a group, even if the group has permission for the database, the new user doesn't. They don't inherit the group's permissions for the database, or any object within it. In fact, they don't have permission for anything!

 

[AccessGuru]

which version of access and mdb jet database are you using?

 

[GeekGirlau]

Access 97 - how do I tell which version of jet?

 

[AccessGuru]

Use this code to check. Open a macro and call it bu entering =init(). Modify it to debug.print what ever you need.

'This module demonstrates a technique for determining whether a user has the version
'of the Jet engine that corresponds with the Microsoft Access Service Pack. The function
'FVerifyJetVersion() retrieves the file version information from MSAJT200.DLL via direct
'Windows API calls and compares the build version of the file with the JET_MINORVERSION
'constant below. The build version that is being checked should not be confused with the
'information returned from the Version property of the DBEngine object.
'The Init() function should be called by an AUTOEXEC macro to ensure that all users only
'open the database with JET 2.5. If a user is still using a version of JET prior to 2.5,
'a message will be displayed and Access will quit. The informational message and shut down
'of the application can be changed or commented out to meet individual needs.
'See the READSRV.TXT file installed with the Service Pack for more details.

'These are necessary to define the JET engine file name and the minimum JET drop number.
Const JET_FILENAME = "msajt200.dll"
'This is not the same as the version property from the DBEngine object. This number
'should not be modified.
Const JET_MINORVERSION = 1100

' Type returned by VER.DLL GetFileVersionInfo
Type VS_FIXEDFILEINFO
wTolLen As Integer
wValLen As Integer
szSig As String * 16
dwSignature As Long '/* e.g. 0xfeef04bd */
dwStrucVersion As Long '/* e.g. 0x00000042 = "0.42" */
dwFileVersionMS As Long '/* e.g. 0x00030075 = "3.75" */
dwFileVersionLS As Long '/* e.g. 0x00000031 = "0.31" */
dwProductVersionMS As Long '/* e.g. 0x00030010 = "3.10" */
dwProductVersionLS As Long '/* e.g. 0x00000031 = "0.31" */
dwFileFlagsMask As Long '/* = 0x3F for version "0.42" */
dwFileFlags As Long '/* e.g. VFF_DEBUG | VFF_PRERELEASE */
dwFileOS As Long '/* e.g. VOS_DOS_WINDOWS16 */
dwFileType As Long '/* e.g. VFT_DRIVER */
dwFileSubtype As Long '/* e.g. VFT2_DRV_KEYBOARD */
dwFileDateMS As Long '/* e.g. 0 */
dwFileDateLS As Long '/* e.g. 0 */
End Type

' User defined type so we can copy into the type above using LSet
Type fBuffer
Item As String * 1024
End Type

Declare Function GetFileVersionInfoSize Lib "ver.dll" (ByVal stFileName As String, ByVal stTmp As String) As Long
Declare Function GetFileVersionInfo Lib "ver.dll" (ByVal stFileName As String, ByVal hVersionInfo As Long, ByVal lSize As Long, ByVal stBuf As String) As Integer

Function FVerifyJetVersion()

Dim Buffer As fBuffer
Dim vInfo As VS_FIXEDFILEINFO
Dim stBuf As String
Dim lSize As Long
Dim stUnused As String * 4
Dim errCode As Long
Dim stMajor As String
Dim stMinor As String
Dim VerNum As String

lSize = GetFileVersionInfoSize(JET_FILENAME, stUnused)
stBuf = String$(lSize + 1, 0)
errCode = GetFileVersionInfo(JET_FILENAME, 0&, lSize, stBuf)

If errCode <> 0 Then
Buffer.Item = stBuf
LSet vInfo = Buffer
FVerifyJetVersion = ((vInfo.dwProductVersionLS And &HFFFF&) > JET_MINORVERSION)
Else
FVerifyJetVersion = False
End If

End Function

Function Init()
On Error GoTo Init_Err

' Verify correct version of jet
If FVerifyJetVersion() Then
' This can be uncommented to verify that you are running JET 2.5
' MsgBox &quot;You are running the correct version of JET&quot;
Else
' Message to inform user that they are running JET 2.0
MsgBox &quot;You must be running JET 2.5 to access the database. Copy the 2.5 version of MSAJT200.DLL to your {windows}\system directory and restart.&quot;
' This closes the Access application
Application.Quit
GoTo Init_Exit
End If


Init_Exit:
On Error Resume Next
Exit Function

Init_Err:
MsgBox Error$
Resume Init_Exit
End Function

 

[GeekGirlau]

I get an error on GetFileVersionInfoSize telling me that the file ver.dll is not found. I've tried entering the full path for this file and still get the same error.