DBWACLServer - introduction

<< Click to Display Table of Contents >>

Navigation:  DBWACLServer >

DBWACLServer - introduction

MechWorks DBWACLServer

 

Architecture

DBWAclServer is a client-server way for controlling the ACL attributes of the files managed by MechWorksPDM.

It works as a replacement of the client-only service-based DBWServer.

The architecture of DBWAclServer is:

MechworksPDM ↔ DBWAclClient ← Remote procedure call → DBWAclServer ↔ Shared Files Archive

The files path are always passed in UNC format

Depending on the specific file server addressed by the UNC path, different DBWAclServer servers might be contacted.
Example:

ofile1: \\MyServer1\MySharedPath\myFile1.SLDPRT

ofile2: \\MyServer2\MySharedPath\myFile2.SLDPRT

oThe path to \\MyServer1 should invoke a DBWAclServer running on MyServer1

oThe path to \\MyServer2 should invoke a DBWAclServer running on MyServer2

DFS Namespaces

DBWAclServer and DBWAclClient must work correctly in environments where DFS Namespaces are used. In such an environment, network files are not accessed via the name of the physical server hosting them but rather via a logical namespace which may contain files from many different file servers.

To determine the correct DBWAclServer DBWAclClient checks if the current path is a DFS path and, if so, resolves the name of the server hosting the files, which is a DBWAclServer

DBWAclClient

The client is a COM object contained in a DLL. The functions provided by its interface are listed below.

As such, it is stateless and cannot keep session information. For that reason we change the API slightly and remove the functions Initialize and Terminate. Instead, the RPC connection from the client to the server is instantiated for each call individually and torn down once that call is finished. That makes it much easier to use DBWAclClient, and it also reduces the amount of work required for the client.

DBWAclServer

The server is a Windows system service contained in an executable that's located in

<installation folder>\bin\DBWAclServer\x86\

and which can be installed/uninstalled using the distributed batch file as described below.

Please note the utility DBWGZipR17.exe must be placed close to the service executable on each file server.

Once started, the service runs continuously listening for requests coming from each client node.

Syntax

DBWAclServer -install [-user:<username> -password:<password>]

install

installs the service

uninstall

uninstalls the service

user

<machine>\user or <domain>\user

password

the password related to the above user parameter

Required privileges

Privilege

Description

SeTakeOwnershipPrivilege

Take ownership of any file regardless of permissions and current owner

SeBackupPrivilege

Read any file regardless of permissions

SeRestorePrivilege

Delete any file regardless of permissions

SeImpersonatePrivilege

Impersonate the calling RPC thread’s user

Logging

DBWAclClient creates the file %TMP%\DBWAclClient_YYYYMMDD_HHMMSS.log where YYYYMMDD and HHMMSS are the date and the time of recording

DBWAclServer creates the file %ProgramData%\MechWorks\DBWAclServer\Logs\DBWAclServer.log

Protected file copy

If the following option is enabled

Environment→Remote Access→images_checkONUse DBWAclServer Protected File Copy
the field DBW_COMPANY_INFO:LOCAL_SERVER_NAME must be filled.

TRUSTED_DOMAIN

For users belonging to an Active Directory Domain different from the current one ( typically guest users coming from different locations of the Company, called for working on specific projects in the current Company ), with their Active Directory Domain declared as "trusted" for the current domain, it is now possible to override the default login domain assignment when using DBWAclServer, by declaring a new field named TRUSTED_DOMAIN in the DBWORKS_USERS table:

DBWORKS_USERS

Field name

Data type

Allow nulls

TRUSTED_DOMAIN

nvarchar(50)

images_checkON

If such field is not null for the currently logged in user, all the file ACL operations where the current user is involved (example: check-out of a document) will use the TRUSTED_DOMAIN (if not null) as argument for the DBWAclServer call.

FAQ

Can we activate the ACL Server for an existing environment?

Sure you can. Using a distributed script (LST\SYSTEM\AssignDBWServerACLFileState.vbs) it is possible to properly set rights on already existing archives.

I have read that the files path are always passed in UNC format; since I'm working now with Drive mapping (L:\archive), do I have to change paths names to UNC?

No. Nothing has to be changed, you can keep working as usual using network drives, the PDM will replace the mapped drive with the UNC path when performing a call to the ACL server.

Do we have to activate other tools for the ACL Server (eg.DBWARM)?

In order to use ACL Server, the PDM logged username must be the same as the Windows username; there are several ways to do so, but we strongly suggest to use DBWARM and get the user names form windows user names, there is a button "Get User List from Domain" in DBWARM tool to do so.

Do we have to activate other tools for the ACL Server (eg. Local Checkout Mode)?

It is not mandatory, DBWACL and LCM are two separate features. We suggest to set up just ACL Server to start. Then if you need to also enable LCM you can work on it later. They implement two different levels of security.

There is a Workstation and a Server base ACL Server. Is the server-based ACL Server the better choice (is it replacing the workstations ACL Server)?

DBWServer is the old\legacy service to enable security (local to the client). DBWACLServer is a client-server way for controlling the ACL attributes of the files managed by MechWorksPDM. It works as a replacement of the client-only service-based DBWServer.