Testing replicated security files

Test the replicated security files to ensure that the properties are correct, and replication is working correctly.

Before you begin

About this task

After the SQL Server administrator configures replication for the security data at all sites, you need to check that:

The database properties are correct
Replication is working correctly
The audit log for the security data is working correctly (optional)

Procedure

Check that the security connection file has a site identifier:
1. In iBase Designer, log on as a security or system administrator.
2. Select File > Security File Properties, and enter a unique site identifier if required. To do this, you need write access to the security connection file.
Note: You should protect the security connection file by making it a read-only file or by setting appropriate security permissions. See Protecting the security connection file for details.
Test that replication is working:
This operation requires a security or system administrator at each site if you are unable to log on to the remote servers.
When you use the Security Manager for this test, you can refresh the groups and users displayed in the Security Manager by closing and reopening it. You should also consider the frequency with which updates are replicated between sites. Depending on your organization, the frequency might, for example, be anything from every minute to once a day.
1. At the publisher site, add a user and then close the Security Manager.
2. After a suitable interval, log on at the subscriber site and check that the new user is replicated to this site.
3. At the subscriber site, delete the user.
4. At the publisher site, after a suitable interval, redisplay the Security Manager and then check that the user is deleted.
5. Repeat these steps for any other subscriber sites in your iBase system.
  Contact your SQL Server administrator if there are any problems.
Add groups and users:
After you are satisfied that replication is working correctly, you can add groups and users. The access rights for the users who resolve conflicts, merge records, and perform batch edits and deletions are described in Managing Security.
You will not be able to set up or check the permissions for Data Access Control groups until the publication database exists.
Before you allow users to open any of the databases and start entering data:
- Check that there are no duplicate group or user names. See Handling Duplicate Group and User Names.
- If you are intending to record contact details for each user, predefine the location names. See Assigning a Location to Each User.
When you allow users to start entering data, you might want to ask the users to add their contact details to the database. Each user selects a predefined location from the Location list.
Test the security audit log.
The audit log for the security data is held in the security file and is configured in SQL Server as part of the security file. If you choose to replicate the audit log, check that the audit log is recording security related actions for other sites.
For example:
1. Open the security audit log for the publisher site. You do not need to open the publication database. You should see, for example, Database Opened actions for all the replicated security files.
2. Repeat this for each site.
Contact your SQL Server administrator if security actions are not being recorded.