Help Center

Local Navigation

BlackBerry Manuals & Help  >  Administrator Documentation  >  BlackBerry Enterprise Server 5 Security  >  Security Technical Overview BlackBerry Enterprise Server - 5.0.2

Data that the BlackBerry Configuration Database stores

The BlackBerry® Configuration Database stores the following information:

  • name of each BlackBerry® Enterprise Server
  • unique SRP authentication keys and unique SRP IDs, or UIDs, that each BlackBerry Enterprise Server uses in the SRP authentication process to open a connection to the wireless network
  • IT policy private keys of the IT policy key pairs that the BlackBerry Enterprise Server generates for each BlackBerry device
  • PIN of each BlackBerry device
  • read-only copies of each device transport key
  • copy of your organization’s user directory
  • a semi-permanent reference to user data using the Novell® GroupWise® MessageID in the database synchronization tables that are named MBMailSync, MBCalendarSync, MBPIMSync, and MBFolderSync (BlackBerry® Enterprise Server for Novell® GroupWise® only)

The BlackBerry Enterprise Server components that do not connect to a messaging server can access the information that the BlackBerry Configuration Database stores.

Best practice: Protecting the data that the BlackBerry Configuration Database stores

Best practice

Description

Audit connections to the Microsoft® SQL Server®.

Consider the following guidelines:
  • At a minimum, write failed connection attempts to the Microsoft SQL Server log file and review the log file regularly.
  • When possible, save log files to a different hard disk drive than the one that the data files are stored on.

Delete unsecured, old setup files.

Consider deleting Microsoft SQL Server setup files that might contain plaintext, credentials encrypted with weak public keys, or sensitive information that the Microsoft SQL Server logged to a Microsoft SQL Server version-dependent location during the Microsoft SQL Server installation process.

Microsoft distributes the Killpwd tool, which is designed to locate and delete passwords from unsecured, old setup files in your organization’s environment. For more information, visit support.microsoft.com to read article KB263968.

Limit the permission level of the Microsoft SQL Server.

Consider associating each Microsoft SQL Server service with a Windows® account that the service derives its security context from.

Microsoft SQL Server permits the sa account and, in some cases, other user accounts to access operating system calls based on the security context of the account that runs the Microsoft SQL Server service. If you do not limit the permission level of the Microsoft SQL Server, a potentially malicious user might use these operating system calls to attack any other resource that the account has access to.

Make the Microsoft SQL Server port numbers that are monitored by default on your organization’s firewall unavailable.

Consider configuring your organization’s firewall to filter packets that are addressed to TCP port 1433, addressed to UDP port 1434, or associated with named instances.

Protect the sa account using a password.

Consider assigning a password to the sa account on the Microsoft SQL Server, even on servers that require Windows authentication. The password is designed to prevent an empty or weak password for the sa account from being exposed if an administrator of the database resets the Microsoft SQL Server for mixed mode authentication.

Protect the Microsoft SQL Server installation from Internet-based attacks.

Consider the following guidelines:
  • Require Windows Authentication Mode for connections to the Microsoft SQL Server to restrict connections to Windows user accounts and domain user accounts, and turn on credentials delegation. Windows Authentication Mode does not require you to store passwords on the computer.
  • Use stronger authentication protocols, required password complexity, and required expiration times.

Use a secure file system.

Consider the following guidelines:
  • Use NTFS for the Microsoft SQL Server because it is more stable and recoverable than FAT file systems, and NTFS permits security options such as file and directory ACLs and EFS.
  • Do not change the permissions that the Microsoft SQL Server specifies during the Microsoft SQL Server installation process. The Microsoft SQL Server creates appropriate ACLs on registry keys and files if it detects NTFS.
  • If you must change the account that runs the Microsoft SQL Server, decrypt the files that you could access using the old account and encrypt them again for access using the new account.

Use Microsoft SQL Server Management Studio.

Consider the following guidelines:
  • Use Microsoft SQL Server Management Studio to change the account that is associated with a Microsoft SQL Server service, if required. Microsoft SQL Server Management Studio configures the appropriate permissions on the files and registry keys that the Microsoft SQL Server uses.
  • Do not use the Microsoft Management Console Services applet to change the account that is associated with a Microsoft SQL Server service. To use this applet, you must manually change the Windows registry, the permissions for the NTFS file system, and Windows user rights.

For more information, visit support.microsoft.com to read article KB283811.

Next topic: How the BlackBerry Enterprise Solution protects IT policies
Previous topic: Where the BlackBerry Enterprise Server stores messages and user data in the messaging environment

Was this information helpful? Send us your comments.