|
<< Click to Display Table of Contents >> Navigation: DBWACLServer > DBWACLServer - introduction |
MechWorks DBWACLServer
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
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
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.
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.
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 |
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 |
•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
If the following option is enabled
Environment→Remote Access→
Use DBWAclServer Protected File Copy
the field DBW_COMPANY_INFO:LOCAL_SERVER_NAME must be filled.
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) |
|
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.
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.