BMD
Österreich
BMD
Deutschland
BMD
Schweiz
BMD
Magyarország
BMD
Slovensko
BMD
Česko
BMD
International
1. General Information
2. Operation Systems
2.1. Operating system patches
2.2. The SSL protocols used
3. SQL Server
3.1. SQL CU
3.2. SQL point-to-point encryption
3.3. SQL account
3.4. SQL database encryption (TDE)
3.5. SQL backup encryption
4. BMD NTCS installation
4.1. User BMD
4.2. Adjusting the NTFS permissions
4.3. BMD Client service
4.4. Adjusting the BMD NTCS login process
4.4.1. Basic authentication (encrypted)
4.4.2. Basic authentication
4.4.3. Windows authentication
4.5. BMD NTCS SOAP user with minimal permissions
4.6. Adjusting the BMDNTCSSvc account
4.7. Auditing of the DMS directory
5. Adjusting BMD NTCS parameters
5.1. Encryption of the log files
5.2. Enabling encryption of the BMDNTCSSvc
5.3. Enabling the password policy
5.4. SMTP dispatch
6. Web Server
6.1. Two-factor authentication
6.2. SSL communciation for website
6.3. Removing and setting HTTP response headers
6.4. Anti-Malware Scan Interface for the databox
6.5. Changing the default website
6.6. Preventing login details from being saved
6.7 Configuring the web application behaviour
This guide is intended for making an existing BMD NTCS installation as secure as possible. It describes and recommends settings for both the operating system and for BMD NTCS.
This guide is aimed at experienced administrators. It is at the discretion of the customer as to which settings can be implemented without a negative effect on other software that might be in use. This guide is written for a system in which only the BMD NTCS software is used.
As for some measures, a secure environment is more important than gaining a certain level of comfort.
A prerequisite is that the latest Microsoft operating system is used on both the client and the server which are released according to the system requirements.
The operating system must be up to date with the latest patches and only software which is strictly necessary should be installed on it. For a holistic security concept, you also have to keep any additional software that has been installed up to date and close known security gaps.
All currently insecure protocols for SSL encryption should be disabled on the server. This especially applies to SSL 3.0, TLS 1 and TLS 1.1. In addition, encryption processes should be limited to processes which are considered secure.
It is recommended to either make the necessary settings using tools of third-party suppliers (https://www.nartac.com/Products/IISCrypto) or to adjust the settings via GPO or registry values (see https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protoc).
If the server is also used as a web server, you have to check the active protocols. There are various web services which allow you to do so easily (https://www.SSLlabs.com/ssltest/ and https://securityheaders.com/).
For the BMD NTCS clients to be able to communicate with the BMD server and the SQL Server via TLS 1.2 as well, you have to make sure that the latest SQL Native Client is installed. You can either download it directly from Microsoft (see KB3135244 - TLS 1.2 support for Microsoft SQL Server - Microsoft Support) or find a compatible version under \\ihr-bmd-server\bmdntcs_pgm\redist – the files SQLNCLI11_X64.MSI (for 64-bit Windows) and SQLNCLI11.MSI (for 32-bit Windows) are available there.
After installation, the SQL Server must be updated with all relevant service packs or cumulative updates. The BMD installation medium does not provide the latest CU by Microsoft.
You can download and install the latest CU on this page.
https://docs.microsoft.com/en-us/sql/database-engine/install-windows/latest-updates-for-microsoft-sql-server?view=sql-server-ver15
In order to encrypt communication between the SQL Server and the SQL Client, it is necessary to enable encryption on the server.
To do so, please follow the instructions by Microsoft:
https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/enable-encrypted-connections-to-the-database-engine?view=sql-server-ver15
It is recommended to use a public certificate or a certificate from an internal CA that is trusted by all the computers.
For the purpose of testing, you can use a self-signed certificate.
The BMD NTCS setup installs the SQL services under the account “Local System”. Since this account has extensive permissions on the system, you should use a separate SQL service account.
You should adjust the service account of both the SQL Server (MSSQL$BMD) and the SQL Agent (SQLAgent$BMD) accordingly.
For instructions on how to do this, please refer to:
https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/scm-services-change-the-service-startup-account?view=sql-server-ver15
If possible, it would be ideal to use a Managed Service Account for both accounts. This has the advantage that the operating system automatically changes the password of the account regularly, which makes for an additional security benefit.
You can find the respective instructions under the following link:
https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-ver15
To encrypt the entire database, you can use Transparent Data Encryption (TDE). TDE allows for automatic encryption of all data contents.
For SQL Server 2017 or earlier versions, this feature requires the Enterprise Edition. Starting with SQL Server version 2019 this feature is also available in the Standard Edition.
For instructions on how to enable TDE, please refer to the following link:
https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-ver15
You should always save the SQL backup in encrypted form. To do so, you have to adjust the respective SQL backup job to perform encryption when creating the backup.
Note: If the encryption (TDE) of the SQL database has been set up beforehand, the SQL backup is already encrypted as well.
The following additional steps are necessary:
https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/create-an-encrypted-backup?view=sql-server-ver15
It is then recommended to set up the SQL backup according to the specifications provided by BMD (see www.bmd.com/en/technical-documentation/setting-up-an-sql-backup-for-bmd-ntcs.html) and subsequently add encryption to the default backup jobs.
Please note that “appending” is not possible for encrypted backup files and the transaction log therefore cannot be backed up in the same backup file as the full backup. Therefore, either a separate backup file must be used for each trans log backup job (and overwritten daily) or alternatively a diff backup job is created that runs at 9:00, 12:00, 15:00 and 18:00 and overwrites the existing diff backup file.
Additional information: https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/backup-encryption?view=sql-server-ver15#Restrictions
The user BMD is created automatically when setting up the database and is similar to the account “administrator” in Windows. Already during installation, you should set a very complex password for this user which is not intended for day-to-day use.
Each BMD NTCS user must have their own database user, as it is not possible to track changes in the database unless every user is indicative of a natural person.
For administrative tasks in BMD NTCS, it is recommended to use a separate admin account. This allows for a clear distinction between daily tasks and administrative tasks (adjusting permissions, adjusting global parameters, etc.). Another advantage is that you can test adjustments of permissions with your “regular” account.
When you install BMD NTCS, two shares are created: BMDNTCS_PGM and BMDNTCS_PGMDATA. For these shares, access is not restricted in any way. You should therefore make the following adjustments after installation:
BMDNTCS_PGMDATA
This share contains all directories for which users who work with the BMD NTCS software need write permission. Among other things, log files and temporary files are created in this share. Furthermore, exported data are stored there, etc.
It is therefore advisable to create a separate group (e.g. group-ntcs-users). Please add all Windows accounts of the users who use the BMD NTCS software to this group. Then you have to adjust the NTFS permissions (including the share permissions) in such a way that only this group has write permission for the directory.
BMDNTCS_PGM
This share contains all necessary data which the BMD NTCS client needs to be executable. This is also where various global configuration files are located. Generally, BMD NTCS users only need read permission for this directory. BMD NTCS power users or administrators, however, need write permission. Write permission is for instance required to install BMD NTCS updates/patches or to perform administrative tasks. This includes among other things adjusting the files BMD.INI or BMDGLOBAL.INI. This is where SQL alias names, global settings for the BMD call centre, etc., are managed.
It is therefore recommended to limit the above-mentioned “group-ntcs-user” to read permission (for NTFS as well as for share permissions).
Additionally, you should create a separate group (e.g. group-ntcs-admin-users). To this group you have to add all Windows accounts of the users who perform the above-mentioned administrative tasks in the BMD NTCS software. Then you have to adjust the NTFS permissions (including the share permissions) in such a way that only this group has write permission for the directory.
The BMD NTCS software installs its own server called “BMD Client Service” on all clients and also on the server. Usually, this service is necessary to allow each user to run a complete update of the BMD NTCS Client on their workstation even without administrator permissions.
The process is as follows:
A user logs on to their workstation. This automatically runs the file C:\Program Files(x86)\BMDNTCS\BMDNTCSClients\“Servername“\BMDNetclient.exe which compares the status of the locally installed program to the server version. If there are any differences, BMDNetClient.exe attempts to update the local program status. In the course of this process, it might be necessary to install new components (.Net version, SQL Native Client) or to register certain DLLs. If the permissions of the user who is logged in are not sufficient for this, the task is transferred to the “BMD Client Service”. Since the BMD Client service runs under “Local System”, it has the extensive permissions needed to make the changes to the system.
For BMD NTCS 2021.24.01 or earlier versions, the BMD NTCS client is installed in “C:\ProgramData\BMDNTCS\BMDNTCSClients\...”. In this case, the users have Change permission and it is therefore possible to manipulate BMDNetClient.exe and to run a process under Local System.
As of BMD NTCS version 2021.24.02, the BMD NTCS client is installed in “C:\Program Files(x86)\BMDNTCS...”. Since the group of users does not have permission to change this folder, it is absolutely safe for the BMD Client service to be active and you should not deactivate it.
Prior to version 2021.24.01, the standard installation of the BMD NTCS software uses a login system with a shared SQL user (BMDSA) – user permissions within the BMD NTCS software are managed via a separate authorisation concept. This can be a risk to security, as the BMDSA user has both permission to connect to the SQL Server and DBOwner rights to the BMD database. Please note that as of the BMD NTCS version 2021.24.01 this login system is no longer used in new installations.
If you are still using the old login system, you additionally have the option to change the BMD NTCS login system. Start BMDDBUpdate.exe directly on the server. Log in with the BMD user and select "Change authentication method" under "Extras" → "Miscellaneous service routines". In the new window, you have to select "Basic authentication (encrypted)" and confirm with "Apply".
A new account with the respective permissions is created on the SQL server (BMD_%RandomID%) and the value SQLSERVER\INSTANZ:DATENBANK=ENCRYPTED is entered in BMD.INI in the section [BMD\ALIASCONFIG].
In addition, you should create the entry SQLCLIENT=DIRECT in the BMD.INI file in the section [BMD]. As a result, a proprietary access method will be used (which replaces the SQL Native Client or the OLE DB driver).
You can check the access mode in the section "Database" of the system information (? > Info > System information). "Configured: DIRECT" must be displayed.
This is also the preferred method for accessing the SQL server and should be used in environments where high levels of security are required.
Now you should deactivate the existing user BMDSA. After a successful test login to the BMD NTCS software, you should permanently delete this user.
You also have the option to work with two SQL accounts. One account is used to connect to the SQL server before the second account is used to establish connection to the database. Each account only has the respective permission which thus prevents abuse (key word: SQL Application Role).
Either the SQL Native Client or MSOLEDB is used for the access. Please note that encryption between the client and the SQL server must be configured separately (see section 3.2.).
To use this login system, you have to make the following adjustments:
Start BMDDBUpdate.exe directly on the server. Log in with the BMD user and select "Change authentication method" under "Extras" → "Miscellaneous service routines". In the new window, click "Accept" to confirm the activation.
This creates two new accounts on the SQL server and grants the respective permissions. In addition, the value „SQLSERVER\INSTANZ:DATENBANK“=EXTENDED is entered in BMD.INI in the section [BMD\ALIASCONFIG].
The new accounts can be viewed in the SQL Management Studio; they are created with a randomly generated SID.
Now you should deactivate the existing user BMDSA. After a successful test login to the BMD NTCS software, you should permanently delete this user.
Soon, however, support for this login system will be discontinued.
This login system is still available for special cases.
Start BMDDBUpdate.exe on the server. Log in with the BMD user and select “Change authentication method” under “Extras” → “Miscellaneous service routines”. In the new window, you have to take the following steps: Select “Windows authentication”, enter an already existing Windows group and confirm with “Accept”. The SQL Native Client is used to access the SQL Server.
This Windows group gets DB owner rights to the database on the SQL Server. In addition, the value „SQLSERVER\INSTANZ:DATENBANK“=WINDOWS is entered in BMD.INI in the section [BMD\ALIASCONFIG].
The users are thus accessing the SQL Server with their Windows accounts.
Please note that this configuration also allows the users direct access using SQL Management Studio or similar tools.
The following applies to all methods:
If web applications are used on a separate web server, the BMD NTCS update service should activate the new authentication method on this web server as well. If this is not the case, you have to add the respective [BMD\ALIASCONFIG] entry directly in the directory of the relative web application in the BMD.INI file.
Moreover, encrypted communication (irrespective of the login method) requires transport encryption to be enabled on the SQL Server (see section 3.2.).
In order to use BMD NTCS batch processing, you have to store a suitable operating system user with which task scheduling is accessed and BMD NTCS processes are started directly on the server. To ensure that the environment is as secure as possible, this user should only be granted the strictly necessary permissions and you should not use an administrator account.
Moreover, the BMDNTCSSOAPSvc on the server should be moved from the account “Local System” to a separate Windows account.
The following operating system permissions are required:
In addition:
BMD NTCS setup by default installs the service BMDNTCSSvc under “Local System”. Among other things, this service is responsible for saving and retrieving archive documents in the file system or it is used as an update service for the web application.
Since the account “Local System” has extensive permissions in the system, it is recommended that you run the service under a restricted account.
The following operating system permissions are required:
In addition:
The BMD NTCS Archive generally detects any manipulation of archived documents. However, it can be difficult to determine what caused a change of the files. This means that the files can be manipulated outside of the BMD NTCS software (by an administrator directly at the DMS server).
In order to monitor such access, you have to activate the relevant protocols on the operating system and protect them accordingly.
To do this, it is necessary to enable auditing on the folders to be monitored.
You have to enable the following auditing entries:
| File/Folder Changes | Everyone | Success and Failure | Create Files/Write Data Create Folders/Append Data Write Attributes Write Extended Attributes Delete Subfolders and Files Delete | This Folder, Subfolder and Files |
| Folder Permissions and Owner Changes | Everyone | Success and Failure | Take Ownership Change Permissions | This Folder, Subfolder and Files |
| File Read | Everyone | Success and Failure | List Folder/Read Data | Files only |
| Folder Read Failure | Everyone | Failure | List Folder/Read Data | This Folder, Subfolder |
This is to ensure that the changes in the file system are logged accordingly in the event log of the DMS server.
It is also recommended to use a software which saves these changes in an external database. The event log of the DMS server is overwritten regularly and the administrator can delete it manually. ADAuditPlus by Manage Engine is an example for a suitable tool for directory auditing (https://www.manageengine.com/products/active-directory-audit/). It monitors the respective directory access and saves the changes in a separate database. It is crucial that the DMS administrator does not have access to this database.
Many of the BMD NTCS log files are saved in the server share BMDNTCS_PGMDATA in the subdirectory LOG. These log files may, for instance, contain sensitive information. Therefore, it is recommended to save the log files in encrypted form. The advantage of this is that the log files can only be viewed with the BMD NTCS Log Viewer (TOOLS → Tools → Logs → Log files). Calling up the Log Viewer needs to be restricted accordingly in the BMD NTCS authorisation system.
You also have to enable encryption of the log files with the following parameter:
TOOLS → Tools → Settings → TOOLS parameters → Authorisation → General settings → Authorisation → Encrypt log files → Yes
In addition, you have to enter a password under “Password for log files”. This password is necessary, for example, if the log files have to be read on another system. For instance, in case the BMD support team has to analyse these log files, it needs the password.
As soon as BMD NTCS is restarted, the log files cannot be read in plaintext anymore.
The BMDNTCSSvc is used for instance to transfer archive documents from the BMD NTCS Archive to the client. The BMD NTCS Client establishes a TCP connection to the service on the server which then transfers the required files (or saves them in the archive on the server).
To enable encrypted transmission of this communication, please proceed as follows:
TOOLS → Tools → Settings → TOOLS parameters → Overall system → BMD NTCS service → Use secure access → 3 - TLS version 1.2
If necessary, you can increase the key length under the option “Server certificate”. The certificate is created at the next restart of BMDNTCSSvc and subsequently used by the clients.
For BMD NTCS installations which have been in use for some time, the password policy might not yet be enabled. It is essential that you enable it to ensure that all BMD NTCS users change their passwords regularly while maintaining the specified complexity.
To enable the password policy, proceed as follows:
Under TOOLS → Tools → Settings → TOOLS parameters → Authorisations → General settings → Password, the parameter "Apply password policies" must be set to 1 or 2.
You can also adjust the desired parameters for the password policy.
The BMD NTCS software offers various options for creating and sending emails. As for the different versions, you will always have to weigh between security and convenience. To run a system that is as secure as possible and for which it is not necessary to save the SMTP access data within BMD NTCS, you have to activate the following parameter:
TOOLS → Tools → Settings → TOOLS parameters → Overall system → General settings → Standard email → Mailing system for SMTP mail
You have to set this parameter to "2 - Directly via the email server with DefaultNetworkCredentials".
This requires that the email server in use can recognise and automatically authenticate the Windows user who is logged on locally, as is the case with a Microsoft Exchange server.
In addition, you have to globally store the SMTP server in the parameter and define the corresponding port. Set the parameter “Activate TLS for SMTP” to “3 – TLS version 1.2”. It is necessary that the SMTP server supports this.
As soon as the global data are stored, the users are able to send emails directly via SMTP from BMD NTCS. To this end, the email address stored in the employee master data is used. The respective Windows user used for starting BMD NTCS must also have authorisation for this email address on the mailing system.
As mentioned above, the advantage of this configuration is that no SMTP access data need to be stored in BMD NTCS.
A disadvantage is that asynchronous mail dispatch is not possible with this constellation. When using asynchronous mail dispatch, the BMDNTCSSoapService sends the emails via SMTP. These emails are saved in the database before they are transmitted. It is thus not necessary for the BMD NTCS application to wait for each email to be sent (e.g. standard letter). For this purpose, however, the SMTP data must be saved in the database.
A detailed explanation of the different SMTP settings is available (in German) in our online help under:
https://www.bmd.at/Portaldata/1/Resources/help/00.00/OES/Documents/1372702529000101160.html
Since using the BMD Web and BMD Com applications inevitably involves internet access, it is recommended to equip all BMD NTCS user accounts which have access to the web portals with two-factor authentication.
Details on setting up two-factor authentication are available (in German) in the BMD NTCS online help:
https://www.bmd.at/Portaldata/1/Resources/help/00.00/OES/Documents/1372780407000202280.html
Additionally, you have to check the parameter in order to make sure that the respective account is actually locked in the case of unsuccessful login attempts. You can find this parameter under TOOLS → Tools → Settings → TOOLS parameters → Authorisation → General settings → Login.
Here you have to set the parameter “Lock after n failed login attempts” to the desired value (recommendation <= 5).
A prerequisite for this is that the web server runs on a separate server in an isolated DMZ (further information in German: https://www.bmd.com/fileadmin/user_upload/bmd-com-technischer-aufbau.pdf).
It is not recommended to run the website for the BMD Web applications directly on the BMD server.
The website or the web server on which the BMD Web applications are operated may only be made accessible via SSL.
To do so, an appropriate certificate must be stored on the web server. It is highly recommended to use a public certificate and to make the website accessible under the same DNS name both internally and externally.
For testing, you can also use a self-signed certificate.
www.bmd.com/technische-dokumentation/erstellen-eines-selbstsignierten-zertifikats.html
You also have to deactivate all SSL protocols and encryption methods that are not considered secure (see 2.2. SSL protocols).
Moreover, you should enable Strict Transport Security on the web server in order to inform the client that the website may only be accessed via HTTPS.
Since Windows Server 2019, this can also be configured more comfortably via the GUI of the IIS manager.
After configuring the website, you should run an SSL test to ensure that the configuration has been carried out correctly. You can do this via ssllabs.com – your result should be grade A.
In order not to unnecessarily disclose information in case of external access, you should remove the respective response header. This prevents, for instance, immediate read-out of information on the web server or on whether .NET is used.
There are several ways to remove response headers which are described here:
We recommend “URL Rewrite” (https://www.iis.net/downloads/microsoft/url-rewrite).
Using it, you have to create the respective outbound rules. The header "RESPONSE_X-ASPNETMVC-VERSION", which is not part of the article, should ideally be added.
In addition, the following HTTP response headers should be defined:
You can use the following header to prevent the web server from calling URLs or scripts that have not been explicitly shared. To do so, you have to set a “Content-Security-Policy” header with the following content:
default-src 'self' 'unsafe-inline' my.site.commy.site.comlocalhostexternalsignature.moxis.cloud*.dynatrace.com data: ;script-src 'self' 'unsafe-eval' 'unsafe-inline' *.dynatrace.com blob: my.site.commy.site.comlocalhostexternalsignature.moxis.cloud;img-src 'self' 'unsafe-inline' data:
Please note: you need to replace “my.site.com” with the URL of the web application.
To ensure that all documents that are uploaded to BMD Com databox, BMD online application, BMD Web, etc., are scanned for malware, the AMSI (Anti-Malware Scan Interface) by Microsoft is used on the webserver.
For this reason, an antivirus software which also supports the AMSI needs to be active on the web server. You have to discuss this with the respective manufacturer.
Since Microsoft Windows Defender supports this interface, it can be used as well.
In case you are using Windows Defender, please note that it by default includes the web server process (w3wp.exe) in the integrated exclusions. This is why it is necessary to disable this exclusion when using Windows Defender.
For the necessary steps please refer to:
Caution!
It is absolutely necessary that you check if Windows Defender works. To do so, you can for instance upload an EICAR test file to the databox which the antivirus software must detect accordingly.
Similarly, the respective antivirus software has to create an alert or a log entry. When using Windows Defender, you can check this in the event log of the web server.
If you exclusively use a BMD application on the web server, we recommend you change the IIS default website. As a result, it is not apparent that you are using an “internet information server” when the base URL is called.
To do so, you have to specify an HTTP Redirect to the desired web application on the default website in IIS.
If you call https://myurl.mydomain.com, you will then automatically be redirected to https://myurl.mydomain.com/bmdweb.
You can set the following entry in the respective BMD.INI on the web server in the corresponding directory of the BMD web application:
[BMD\BMDCOM2] or [BMD\BMDWEB2]
HIDEPERSISTENTLOGIN=1
If you do so, the option “Remain logged in” will not be available in the login dialogue. In addition, autocomplete=off is set for user/password fields. The login details are then also no longer saved in the browser (or the browser is at least instructed not to save them).
Since the BMD web applications can basically be accessed for various purposes (REST interface, Windows authentication, etc.), it is possible to enforce a certain behaviour. This can for instance be useful if you want to prevent the web application to respond to REST enquiries.
You can define the following parameter in the BMD.INI of the web application:
[BMD\BMDWEB2]
HANDLEDREQUESTS=SSO
This parameter ensures that the web application does not allow normal logins.
If BMD Go is supposed to work with the same website, the parameter must be defined like this:
[BMD\BMDWEB2]
HANDLEDREQUESTS=SSO,REST
Follow us
