Monday Apr 04, 2011

Controlling Rights Synchronization in IRM 11g


synch icon

A colleague recently asked how you can control the periodic synchronization of rights and audit data in IRM 11g – and what are the defaults? What factors should you consider when deciding whether the default synch schedule is right for your organisation, and how does synching impact the performance of the client and the server in large deployments? What exactly is synchronized on each occasion?

By default, synchronization occurs Monday to Friday between the hours of 9am and 5.30pm. The admin UI for the synch schedule is pretty self-explanatory…

synch schedule

Each IRM Desktop evaluates that time window according to its local time zone, so if you have users scattered around the world, they will each synch during their respective working days. You’ll note that the time window is quite large – a full working day. This ensures that the server is not hit by large peaks of requests in large deployments. There is usually no great urgency to get the synch done at a particular time, so we set a broad window.

Each IRM Desktop will pick a random time during each time window – again so that they don’t all try at once – and automatically tries again at intervals in the event of failure. If the network is disconnected at the time, the IRM Desktop will watch for the next connection and try again. All of this is transparent to the user.

What exactly gets synchronized? Synchronization is a two-way activity. The server provides the client with a fresh statement of the user’s rights and resets the offline periods so that the user rarely, if ever, hits the expiry time. In most configurations, this provides the user with a cached copy of ALL of their rights. Our classification model makes this viable even at large scale – there might be thousands or millions of documents, but they are usually organised for policy purposes into a few classifications, and each user has rights to a few classifications. So, each IRM Desktop only needs to receive a small amount of policy information in order for the user to have access to thousands of documents. There is no need for a user to be sent any information about classifications that they do not have any right to use, so the set of information sent to each user is usually quite small.

The server can also take the opportunity to inform the client of a change to the synch schedule, and to remind the client of the correct time from the server’s perspective.

In return, the client provides the server with the audit trail generated by its user since the previous synch event. This means that the server gets regular updates about offline usage of sensitive information. Some solutions only provide audit trail for events that involve contacting the server – so offline use is often invisible.

So why might you change the defaults? The most common reason is simply that your working week might not be Monday to Friday. If you have users in the Middle East, for example, you might configure the schedule accordingly. Alternatively, if you have a service in which rights rarely change, or you are not particularly worried about how quickly policy changes propagate out to users, you might reduce to a weekly schedule rather than daily – but the amount of traffic generated by synching is pretty modest so most customers stick with the defaults.

Another reason would be if you are not using the out-of-the-box classification model. If you are managing rights file-by-file or using some other model that involves a lot of policy configuration, then there might be a lot of information to synch to each user.

Another might be that it is REALLY important that policy changes be propagated rapidly or that audit trail be collected more frequently – so you might configure a lot of smaller windows during each day. Or you might modify some or all roles to achieve similar effects. You increase the traffic, but gain greater control and visibility.

Also, if appropriate, you can configure some or all roles to disable offline auditing. This reduces the amount of data that the client needs to send to the server. This might be useful if users are using a lot of sealed content and you are not too interested in the audit trail. Again, you choose which roles to exempt from auditing.

Thus, out-of-the-box we provide a powerful mechanism for ensuring timely propagation of policy changes and frequent upload of offline audit data – but we also give you a variety of controls to play with if needed.


Monday Apr 19, 2010

Protecting offline IRM rights and the error "Unable to Connect to Offline database"

One of the most common problems I get asked about Oracle IRM is in relation to the error message "Unable to Connect to Offline database". This error message is a result of how Oracle IRM is protecting the cached rights on the local machine and if that cache has become invalid in anyway, this error is thrown.


Offline rights and security

First we need to understand how Oracle IRM handles offline use. The way it is implemented is one of the main reasons why Oracle IRM is the leading document security solution and demonstrates our methodology to ensure that solutions address both security and usability and puts the balance of these two in your control.


Each classification has a set of predefined roles that the manager of the classification can assign to users. Each role has an offline period which determines the amount of time a user can access content without having to communicate with the IRM server. By default for the context model, which is the classification system that ships out of the box with Oracle IRM, the offline period for each role is 3 days. This is easily changed however and can be as low as under an hour to as long as years. It is also possible to switch off the ability to access content offline which can be useful when content is very sensitive and requires a tight leash.


So when a user is online, transparently in the background, the Oracle IRM Desktop communicates with the server and updates the users rights and offline periods. This transparent synchronization period is determined by the server and communicated to all IRM Desktops and allows for users rights to be kept up to date without their intervention. This allows us to support some very important scenarios which are key to a successful IRM solution.

  • A user doesn't have to make any decision when going offline, they simply unplug their laptop and they already have their offline periods synchronized to the maximum values. Any solution that requires a user to make a decision at the point of going offline isn't going to work because people forget to do this and will therefore be unable to legitimately access their content offline.
  • If your rights change to REMOVE your access to content, this also happens in the background. This is very useful when someone has an offline duration of a week and they happen to make a connection to the internet 3 days into that offline period, the Oracle IRM Desktop detects this online state and automatically updates all rights for the user. This means the business risk is reduced when setting long offline periods, because of the daily transparent sync, you can reflect changes as soon as the user is online. Of course, if they choose not to come online at all during that week offline period, you cannot effect change, but you take that risk in giving the 7 day offline period in the first place.
  • If you are added to a NEW classification during the day, this will automatically be synchronized without the user even having to open a piece of content secured against that classification. This is very important, consider the scenario where a senior executive downloads all their email but doesn't open any of it. Disconnects the laptop and then gets on a plane. During the flight they attempt to open a document attached to a downloaded email which has been secured against an IRM classification the user was not even aware they had access to. Because their new role in this classification was automatically synchronized their experience is a good one and the document opens.

More information on how the Oracle IRM classification model works can be found in this article by Martin Abrahams.



So what about problems accessing the offline rights database?

So onto the core issue... when these rights are cached to your machine they are stored in an encrypted database. The encryption of this offline database is keyed to the instance of the installation of the IRM Desktop and the Windows user account.


Why? Well what you do not want to happen is for someone to get their rights for content and then copy these files across hundreds of other machines, therefore getting access to sensitive content across many environments. The IRM server has a setting which controls how many times you can cache these rights on unique machines. This is because people typically access IRM content on more than one computer. Their work desktop, a laptop and often a home computer. So Oracle IRM allows for the usability of caching rights on more than one computer whilst retaining strong security over this cache.

So what happens if these files are corrupted in someway? That's when you will see the error, Unable to Connect to Offline database. The most common instance of seeing this is when you are using virtual machines and copy them from one computer to the next. The virtual machine software, VMWare Workstation for example, makes changes to the unique information of that virtual machine and as such invalidates the offline database.


How do you solve the problem?

Resolution is however simple. You just delete all of the offline database files on the machine and they will be recreated with working encryption when the Oracle IRM Desktop next starts. However this does mean that the IRM server will think you have your rights cached to more than one computer and you will need to rerequest your rights, even though you are only going to be accessing them on one. Because it still thinks the old cache is valid. So be aware, it is good practice to increase the server limit from the default of 1 to say 3 or 4. This is done using the Enterprise Manager instance of IRM.



So to delete these offline files I have a simple .bat file you can use;

Download DeleteOfflineDBs.bat

Note that this uses pskillto stop the irmBackground.exe from running. This is part of the IRM Desktop and holds open a lock to the offline database. Either kill this from task manager or use pskillas part of the script.

Wednesday Jan 13, 2010

Offline Access Management for IRM Encrypted Documents


Perhaps the most frequent of frequently-asked-questions about IRM was put to me recently by one of my Irish colleagues:

If you have to get IRM decryption keys and access rights from an IRM server, how does that impact offline access to documents and offline creation of new documents? How do I ensure that business users can keep working when they are on customer premises, or sitting on a plane, or simply disconnected from the net for whatever reason?

All IRM solutions have, on the face of it, a similar answer: keys and rights may be cached for offline use for a defined period. Your cached rights enable you to keep working, but not indefinitely.

Offline access issues resolved? Well the devil is in the detail - and we believe that Oracle IRM offers the best available balance of security, usability, and manageability.

How so? First, let's consider how most solutions handle offline periods.

How Most Solutions Manage Offline Periods

With most solutions, every document is evaluated separately. So, when you first open Document-A, you contact the server and obtain the keys and rights for Document-A, and typically you are permitted to cache them for the offline period defined for Document-A. The clock starts ticking immediately for Document-A.

You then want to open Document-B, and you need to contact the server again because opening Document-A has no bearing on whether you can open Document-B - even if the two documents are supposedly subject to the same policy. Having been authorised to open Document-B, the clock starts ticking for Document-B. And likewise for Document-C and so on for each document you access. So, you have contacted the server several times, and now have cached rights and keys for several documents, and independent timers running for each.

The repeated communication with the server highlights a key shortcoming of most solutions. Users need to be online to gain access to each document on first use - and again when revisiting documents after the expiry of their offline periods. This constant per-document evaluation generates a lot of network traffic, and takes place even if exactly the same policy is defined for each document. Each document needs to be evaluated individually.

The fact that each document has its own timer makes it difficult for users to be confident that they will be able to work offline, and causes frustration when some documents turn out to be inaccessible even though the user knows that they are authorised.

Of course, user frustration leads to users bypassing a solution if they can - for example, by choosing not to protect documents due to the inconvenience this entails, or copying information out of documents so that they have an unprotected copy to work with.

But it doesn't end there. The natural user response to the inconvenience of the offline rights expiry is to specify a long offline period for documents that they protect. Long offline periods means less frequent inconvenience.

This pragmatic user behaviour reduces security for two reasons:


  • Users may continue to use cached rights for a considerable period after rights are revoked on the server
  • Routine policy changes take a considerable time to propagate out to all affected users because they may only refer back to the server once their cached rights have expired, which might be weeks after a policy change is configured


Most customers want to know that policy changes will be effective in a short space of time, but the user pressure for a long offline period conflicts with this requirement. Indeed, the fact that many solutions invite users to specify offline periods to suit themselves is a security and management shortcoming for many customers.

Another consequence of unpredictable, per-document timers is that users may have to make manual preparation to go offline. Rather than simply go offline, you might be expected to do a manual synchronisation step first, or required to explicitly notify the server that you are about to go offline and want to be able to work on certain documents. In practice, users won't remember to do this, and those who do remember will not appreciate the added chore.

Other attempts to address this issue involve nominating particular folders in which you will keep the documents that you want to be able to use offline, and have the IRM client software pro-actively manage rights caching for those documents. Sadly, again, users tend not to cope well with mechanisms that require them to keep things in particular locations, and there is a scalability issue if large numbers of users keep large numbers of documents in such folders.

Further, with most solutions you can only apply one offline period to each document, and some solutions require you designate documents as usable offline or only online. There is often no mechanism to differentiate between users according to role. So, if you want to offer a lengthy offline period to your most trusted users, you may have no choice but to give the same period to less trusted users.

As a related issue, with some solutions, a user will find they also need to be online when they want to apply protection to a new document. Setting up the policy and keys for the new document requires communication with the server. This leads to more frustration and, inevitably, leads to documents remaining unprotected.

So, How Does Oracle IRM Differ?

Firstly, Oracle IRM allows a single timer to run for all of the documents in a given classification. This immediately improves the predictability of the user experience. When you open Document-A, you start a timer for all documents in the same classification.

This massively reduces network traffic, and means that you do not need to be online every time you try to access a new document. Worst case, you need to be online when you encounter a new classification of document - there are far fewer of those, and we address even that potential frustration as described below.

Next, the offline period is defined as part of a user's role in each classification - different users get different offline periods for the same documents. So, your most trusted users can be given a role with a lengthy period, while less trusted users can be given a role with a short period.

Crucially, our policy model makes the entire policy set small enough for the IRM Desktop to support regular rights synchronisation for ALL of a user's rights IN ADVANCE of the user actually trying to open any documents, and to synchronise any policy changes pro-actively rather than when the offline period expires for various pieces of content.

In practice, this typically means that policy changes are propagated within 24 hours rather than several days or weeks. And this synchronisation is for ALL documents - not just the ones that the user has remembered to keep in a particular folder, or has nominated in some other way. Synchronisation a transparent process, making the solution significantly more user friendly. Users don't need to do any preparation to use content offline - they just pull the cable and go.

Automated synchronisation also means that whatever your offline period might be for a particular classification, it is regularly "refreshed" so that you don't have to worry about your rights expiring at an inconvenient time. So there is no conflict between users wanting a long offline period and security officers wanting a short offline period.

Finally, our solution does not routinely invite users to choose the offline periods to suit themselves. Offline periods are defined as part of a policy framework. This reduces variability, and removes a potential conflict between users and security officers.


For many solutions, particularly when used at scale, offline access creates significant frustrations and challenges for both business users and security officers. Oracle IRM's unique approach makes it significantly easier to balance usability, security, and manageability even for large scale deployments.

By the way, anyone using the IRM evaluation service is subject to a 3 day offline period, with daily synchronisation during office hours. The majority of those users will be blissfully unaware of this - which is precisely the point.

I hope this article has helped you understand Oracle's position on one of the most frequently asked questions. If you have any questions, feel free to drop us a line.


Oracle IRM protects and tracks your sensitive information no matter where it goes. It combines business friendly encryption with role based usage rights and auditing.

11g quick guide


« June 2016