Tagged with security - Visokio Forums

Security: Authentication on Omniscope Web Server?

stavro — Thu, 25 Dec 2014 01:24:36 -0500

Hi,

How can I create an authentication page which will be shown when we click to mobile web server page? Also all users shouldn't access to all reports. Can you explain it detailed.

Security: Connecting via Proxy Server requiring Authentication.

antonio — Mon, 18 Jun 2012 12:59:28 -0400

Sometimes users experience the following error while trying to open a file or importing a source from DataManager:

"HTTP/1.0 407 Proxy Authentication Required"

When you need to open a file on a remote server through a Proxy server that requires authentication, then you have to provide Omniscope with the Proxy server authentication credentials. To do this select
Settings > Advanced > Default Proxy Authentication
and insert username and password. These credentials will be valid for the whole Omniscope session.

Note that proxy server authentication is different from remote server authentication. If the remote server requires authentication then you will receive the following message:

Unauthorised (HTTP error 401)

To resolve this, depending on the dialog, tick "Requires authentication" and insert the username and password.

Security: Server SSL Error-handshake alert:unrecognized_name

Veaceslav — Fri, 27 Jun 2014 05:30:44 -0400

Server SSL Error - handshake alert: unrecognized_name

You may get this SSL error if the server you are trying to access has not been properly configured.

For security reasons SNI extension has been enabled by default in Java 7. However, if you trust the server you are trying to connect you may want to disable SNI extension.

jsse.enableSNIExtension is a java system property. Server Name Indication (SNI) is a TLS extension, defined in RFC 4366. It enables TLS connections to virtual servers, in which multiple servers for different network names are hosted at a single underlying network address.

Some very old SSL/TLS vendors may not be able to handle SSL/TLS extensions. In this case, set this property to false to disable the SNI extension.

To disable SNL extension you need to do the following:

1. Open 'installconfig.properties' file located at {YOUR_OMNISCOPE_INSTALLATION_PATH}

{YOUR_OMNISCOPE_INSTALLATION_PATH} - this is where Omniscope is installed on your machine (e.g. C:\Users\slavvi\AppData\Local\Visokio Omniscope app)

2. Edit the file to add this line:
ADDITIONAL_JVM_ARGS=-Djsse.enableSNIExtension=false

3. Restart Omniscope

Note: After setting this property, you may get the following error if the server you want to access does not have a certificate issued by a certified authority:
The server you are connecting to does not have a valid certificate from an authorised authority
To resolve this error please read the following post:
http://forums.visokio.com/discussion/2613/security-the-server-you-are-connecting-to-does-not-have-a-valid-certificate
However, you will be unable to execute step 2 outlined in that forum post unless you disable the SNI extension while executing that command. Here is how that command may look like:
java -Djsse.enableSNIExtension=false InstallCert server-storing-my-iok-files.com:443

Security: Server you are connecting to does not have a valid certificate?

Veaceslav — Thu, 26 Jun 2014 08:07:06 -0400

Server SSL error - The server you are connecting to does not have a valid certificate from an authorised authority

Here is what you need to do to enable Omniscope access the url you have (e.g. "https://server-storing-my-iok-files.com/"):

1. Download InstallCert.zip archive and unzip it (it contains two java class files: InstallCert$SavingTrustManager.class, InstallCert.class), put both of them in a folder (e.g. c:\your_path\)

2. Open command prompt (cmd.exe) and change current dir to the folder containing the class files from step 1 (e.g. cd c:\your_path\) then execute this command:

java InstallCert server-storing-my-iok-files.com:443

Note: if you don't have java installed, use the java executable located at:

- {YOUR_OMNISCOPE_INSTALLATION_PATH}\x86\bin\java (if you have a 32 bit OS)
- {YOUR_OMNISCOPE_INSTALLATION_PATH}\x64\bin\java (if you have a 64 bit OS)

{YOUR_OMNISCOPE_INSTALLATION_PATH} - this is where Omniscope is installed on your machine (e.g. C:\Users\slavvi\AppData\Local\Visokio Omniscope app)

(to check whether you have a 32-bit or 64-bit OS: open Control Panel -> System and check 'System type:')
The command may look like this: "{YOUR_OMNISCOPE_INSTALLATION_PATH}\x64\bin\java" InstallCert server-storing-my-iok-files.com:443

If you get the SSL error - handshake alert: unrecognized_name while executing this command please read this post: handshake alert: unrecognized_name

3. You will be asked 'Enter certificate to add to trusted keystore or 'q' to quit: [1]', press 1 then press ENTER
Note: After executing step 3, this message will be displayed in the console:
Added certificate to keystore 'jssecacerts' using alias 'server-storing-my-iok-files.com-1'
which means that this particular certificate will be trusted by java applications if 'jssecacerts' keystore is provided

Notice that 'jssecacerts' file has been created in the folder you executed the command (e.g. c:\your_path\)

4. Open 'installconfig.properties' file located at {YOUR_OMNISCOPE_INSTALLATION_PATH}

5. Edit the file to add this line:
ADDITIONAL_JVM_ARGS=-Djavax.net.ssl.trustStore="c:\your_path\jssecacerts"

6. Restart Omniscope

Note 1: You will get this error if you miss step 5 or the path to 'jssecacerts' is wrong:
java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Note 2: If -Djavax.net.ssl.trustStore="c:\your_path\jssecacerts" points to a directory instead of a file or to a non-existent path, all SSL connections will fail (regardless whether the certificates have been authorised by the most trusted authorities, SSL connections will NOT work at all) and the same error will be displayed:
java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Note 3: There can be only one path set to -Djavax.net.ssl.trustStore="c:\your_path\jssecacerts". If you need more than one trust stores, you need to merge them into a single file and set that file to javax.net.ssl.trustStore property. If this is the case, the simplest solution is to use steps 1-3 mentioned above to add each individual URL. Each entry will be appended to the same jssecacerts file.

Security: Mobile Web Server user permissions

antonio — Mon, 28 Oct 2013 15:04:16 -0400

Omniscope Mobile web server allows you to configure per folder authorisation/permissioning configuration.

To enable this feature, just create a folder.xml configuration file and put it into your sharing folder (or subfolder).
You can start by using the folder.xml.default file, present into the mobile sharing folder, as template.

Remember, the settings present into the folder.xml file will override the default anonymous/folder permissions, and the default users credentials and permissions. As a note for system administrators, folder.xml works like Apache .htaccess file.

Here follows the main aspects you have to knowledge to properly configure the folder.xml file:

Permissions

These are permissions you can set on a folder or per user basis:

listDirectory : allow users to list existing files and subfolders
downloadFile : allow users to download the IOK files
viewInMobile : allow users to launch the Omniscope Mobile app for the existing IOK files
fileManagement : allow users to upload IOK files, rename and delete resources, create new folders in the folder
getStatic : allow users to get/access static resources from the folder, and to customise default styles (e.g. logo, icons, css files)
viewServerState : allow users to view the server state through a monitoring page

N.B. A missing permission in the configuration is equivalent to deny

User Credentials

To specify user credentials is required you specify:

username : in clear text
password : hash encrypted string using MD5 algorythm. As reference you can use this link to generate the hash.

folder.xml file structure

Anonymous section
The element describes the unauthenticated permissions, and is also used as default values for per-user permissions.
Unauthenticated public access will be given these permissions. Any false/missing permissions will require authentication.
Users section
The element describes the credentials and the permissions per user, and is made by the following elements/attributes:
- Enabled : whether or not the user is enabled.
- Credentials : the user username and password
- Permissions: the user permissions that will override the anonymous ones

folder.xml example

Common use cases:

Anonymous access not allowed, Admin user full permissions, Guest users browse and play IOK files
Anonymous can browse folders, no Admin user, Guest users browse and play IOK files

Security: Group Permissions

Veaceslav — Tue, 27 May 2014 07:02:09 -0400

Mobile Web Server Authentication

Group Permissions

Mobile Server authentication has been redesigned to include LDAP/Active Directory (AD) authentication and Single-Sign-On (SPNEGO) mechanisms.

Each server request goes through a security check first and if it is authorized, the request is processed and a proper response is sent back to the client.

Authorization permissions may be added to anonymous users and authentication groups. Permissions cannot be added for each individual user. To make sure a user has specific permissions you need to create a group with those permissions and add the user to that group.

Omniscope Mobile web server allows you to configure per folder authorization/permissioning configuration.

To enable this feature, just create a folder.xml configuration file and put it into your sharing folder (or subfolder).
You can start by using the folder.xml.default file, present into the mobile sharing folder, as template.

Remember, the settings present into the folder.xml file will override the default anonymous/folder permissions, and the default authentication groups and permissions. As a note for system administrators, folder.xml works like Apache .htaccess file.

Editing tip for folder.xml

Instead of manually editing the folder.xml file we suggest you copy an existing folder.xml into the correct folder and then use Omniscope Mobile Web Server UI main toolbar (Settings > Edit folder.xml configuration...) to edit the folder.xml.

Permissions

Here follows the main aspects you have to knowledge to properly configure the folder.xml file.

These are permissions you can set on a folder or per group basis:

listDirectory : allow users to list existing files and subfolders
downloadFile : allow users to download the IOK files
viewInMobile : allow users to launch the Omniscope Mobile app for the existing IOK files
fileManagement : allow users to upload IOK files, rename and delete resources, create new folders in the folder and save. Also used to control if mobile is in "Viewer" mode.
getStatic : allow users to get/access static resources from the folder, and to customise default styles (e.g. logo, icons, css files)
viewServerState : allow users to view the server state through a monitoring page
exportData : allow users to export a view's data as a CSV file.

N.B. A missing permission in the configuration is equivalent to deny

folder.xml file structure

Anonymous section
The element describes the unauthenticated permissions, and is also used as default values for per-group permissions.
Unauthenticated public access will be given these permissions. Any false/missing permissions will require authentication.
Groups section
The element describes the authentication group and its permissions, and is made by the following elements/attributes:
- Enabled : whether or not the group is enabled. Disabled groups are not considered during authentication
  Note: If the enabled attribute is missing the group will be enabled by default. A group is disabled only if the enabled attribute is present and is set to false
- Name: specifies the group name e.g. Data Analysts, Guests, Administrators, Employees, etc
- Permissions: the group permissions that will override the anonymous ones
- Mechanisms: a list of authentication mechanisms to be used when authenticating users for this group e.g. LDAP Query, List Of Users, SPNEGO (Single-Sign-On)
  - ListOfUsers: defining a list of users, e.g. :
    
    Credentials element has two attributes: username and password (the MD5 encrypted password).
    To generate password MD5s, visit this link
  - ldapQuery: LDAP Query mechanism enables Omniscope Server to query an LDAP/AD server to validate user credentials
    Attributes:
    - distinguishedName: LDAP group distinguished name E.g. CN=Users,DC=example,DC=com
    - url: A full URL pointing to your LDAP/AD server
      Example 1: 'LDAP://ldapserver.example.com:389'
      where LDAP is protocol name, ldapserver.example.com is the LDAP/AD server and 389 is the default port for LDAP protocol
      Example 2: 'LDAPS://ldapserver.example.com:636' where LDAPS is LDAP over SSL protocol,
      ldapserver.example.com is the LDAP/AD server and 636 is the default port for LDAPS protocol
    - ignoreSslIssues: false most of the time. Set true only if your LDAP/AD server has not been configured to use a trusted certificate and you are using LDAPS protocol
    - securityAuthentication: Security authentication type supported by your LDAP/AD server. By default, LDAP/AD server uses a simple security type. However, you should contact your administrator to check whether you need to use a different type (CRAM-MD5, or DIGEST-MD5, or none)
    - principalNameFormat: can have only one the the following values:
      1. {Name} : User's simple name will be used to authenticate. e.g. 'username' and 'password' will be used
      2. DOMAIN\{Name}: User's simple name will be added the DOMAIN name automatically e.g 'EXAMPLE.COM\username' and 'password' will be used to authenticate the user
      3. {Name}@DOMAIN: User's simple name will be appended the DOMAIN name automatically e.g. 'username@EXAMPLE.COM' and 'password' will be used to authenticate the user
    - principalDomain: must be set only if 'principalNameFormat' contains a domain name, otherwise it will be disregarded. e.g. 'EXAMPLE.COM'
  - spnegoMechanism: a Single-Sign-On authentication mechanism e.g.:
    
    spnegoMechanism element has a list of user names to be verified once users authenticate successfully on LDAP/AD server and are assigned group permissions (roles).
    WARNING: spnegoMechanism will be disregarded during authentication if SPNEGO global settings are not set in config.xml

folder.xml example



  
		fileManagement="false" getStatic="false" viewServerState="false" 
	exportData="false" />
  
  
	
	  
				fileManagement="false" getStatic="false" viewServerState="false" 
		exportData="false" />
	  
	  
		
		  
			
		  
		
					distinguishedName="CN=Users,DC=example,DC=com" 
			url="ldap://ldapserver.example.com:389" 
			ignoreSslIssues="false" 
			securityAuthentication="simple" 
			principalNameFormat="{Name}@DOMAIN" 
			principalDomain="example.com">

Common use cases:

Anonymous access not allowed, Admin user full permissions, Guest users browse and play IOK files

fileManagement="false" getStatic="false" viewServerState="false" exportData="false" /> fileManagement="true" getStatic="true" viewServerState="true" exportData="true" /> getStatic="true" />
Anonymous access not allowed, admin users authenticating with their LDAP accounts, employees browse and play IOK files and authenticate with their LDAP accounts, a new employee user authenticating with List Of Users mechanism if an LDAP account is not yet available and a user authenticating with a Single-Sign-On (SPNEGO) mechanism

fileManagement="false" getStatic="false" viewServerState="false" exportData="false" /> fileManagement="true" getStatic="true" viewServerState="true" exportData="true" /> distinguishedName="CN=Administrators,DC=example,DC=com" url="ldap://ldapserver.example.com:389" ignoreSslIssues="false" securityAuthentication="simple" principalNameFormat="{Name}@DOMAIN" principalDomain="example.com"> fileManagement="false" getStatic="true" viewServerState="false" exportData="false" /> distinguishedName="CN=Users,DC=example,DC=com" url="ldap://ldapserver.example.com:389" ignoreSslIssues="false" securityAuthentication="simple" principalNameFormat="{Name}@DOMAIN" principalDomain="example.com">

Security: List Of Users authentication

Veaceslav — Mon, 26 May 2014 06:12:43 -0400

Mobile Web Server Authentication

List Of Users authentication mechanism

Besides Single-Sign-On (SPNEGO) and LDAP Query mechanisms which authenticate users that are stored and managed on other servers like LDAP, Omniscope Mobile server may be configured to validate Omniscope users by manually adding custom users on server. Those users are stored in Omniscope Server configuration files (config.xml, folder.xml).

Configuration steps

Open Edit Default folder configuration dialog (Visokio Omniscope Server window -> Mobile Web Server section -> Config button -> Permissions section -> Default folder configuration -> Edit)
Make sure to properly edit anonymous permissions first (actions that are allowed for anonymous users will not use authentication).
Add a new group (or edit an existing group)
- Note: Disabled groups are not considered during authentication
Edit group permissions
For group mechanisms click the Add button and select List of users.
Add users.

Legacy Omniscope users

List Of Users authentication mechanism is a replacement for the legacy Omniscope users. Old configuration files are converted automatically.

Users are grouped automatically based on their permissions and whether users are enabled or disabled.

E.g.
Legacy users:

User 1 with permissions A, enabled
User 2 with permissions B, enabled
User 3 with permissions A, enabled
User 4 with permissions A, disabled
User 5 with permissions A, enabled

Are automatically converted to:

Group 1 with permissions A, enabled having User 1, User 3, User 5
Group 2 with permissions A, disabled having User 4
Group 3 with permissions B, enabled having User 2

Security: Single-Sign-On (SPNEGO) Configuration

Veaceslav — Fri, 23 May 2014 10:32:45 -0400

Mobile Web Server Authentication

Single-Sign-On (SPNEGO) Mechanism

SPNEGO (Single-Sign-On) mechanism allows users to authenticate automatically with their LDAP/Active Directory (AD) account without asking them for credentials. Having a proper setup, authorized users never type their credentials in any dialog or form. Unauthorized users, however, are either prompted for credentials or are denied server access.

Users are stored and managed by an LDAP/AD server
Omniscope Mobile server is configured to ask the LDAP/AD server to validate user tokens

Configuration

At least three machines are involved in a Single-Sign-On setup:

LDAP/AD server (e.g. computer name ldapserver)
A machine running Omniscope server (e.g. computer name omniscopeserver)
A client machine having a browser installed (Chrome, Firefox, Internet Explorer, etc) (e.g. computer name browserA)

Note: Single-sign-on does not work when the client (browser) runs on the same machine as Omniscope server (or LDAP/AD)

The machines must be on the same intranet network,
on the same domain (e.g. example.com),
DNS properly setup such that they all can nslookup each other by name (e.g. nslookup omniscopeserver finds the machine running omniscope server)

LDAP/AD machine - Windows Server OS (2003, 2008, 2012, etc)
- Create a dedicated LDAP user on the domain, e.g. omniscopeuser@example.com with password YourPassword (choose a stronger password), make sure the password never expires
- In command prompt execute:
  setspn -A HTTP/omniscopeserver.example.com omniscopeuser
  
  where example.com is your network domain
  omniscopeserver is the name of the machine running Omniscope server
  omniscopeuser is user logon name of the dedicated LDAP user
  HTTP/omniscopeserver.example.com has never been mapped before with other user. If it has, you need to remove it first:
  setspn -D HTTP/omniscopeserver.example.com otheruser
- In command prompt, execute the second command (make sure to use capital letters exactly as shown in the command):
  ktpass -princ HTTP/omniscopeserver.example.com@EXAMPLE.COM -pass YourPassword -mapuser omniscopeuser@EXAMPLE.COM -out omniscopeuser.HTTP.keytab -crypto RC4-HMAC-NT -kvno 0
  - where example.com is your network domain
  - HTTP/omniscopeserver.example.com - Kerberos service principal name for SPNEGO
  - omniscopeuser - the dedicated SPNEGO user that has been created on the LDAP server
  - YourPassword - password of the dedicated SPNEGO user
  - RC4-HMAC-NT - cryptosystem to use when sending SPNEGO tickets
  - kvno - Key version number
Obviously, LDAP/AD needs to have regular users defined, users that are about to use Omniscope at least. For the purpose of this tutorial we will consider that
there is a user clientA@example.com with password ClientPassword
Omniscope server machine
- Start Omniscope server
- On Mobile Web Server service section click Config, scroll down to Default folder configuration and click Edit
- Edit SPNEGO global settings, for principal name type:
  HTTP/omniscopeserver.example.com
  and edit the password for that LDAP account ('YourPassword')
- Click OK to close editing SPNEGO global settings
- Either create a new group with new permissions, or edit an existing group
- Add a new authentication mechanism and choose SPNEGO mechanism
- Make sure you add all user names for the users that will be allowed to authenticate automatically (e.g. clientA, no domain needs to be included in the name)
- Click OK to close each dialog and click Save and apply to save the configuration
- Omniscope server does not need to be restarted manually
Client Machine - The browser has to be configured to use Single-Sign-On and trust omniscopeserver machine
- For Internet Explorer
  - Open Internet Options
  - In Security tab select Local intranet and click Sites button - make sure all check boxes are selected:
    Automatically detect intranet network,
    - Include all local intranet sites not listed in other zones,
    - Include all sites that bypass the proxy server,
    - Include all network paths
    Then click Advanced button and add the name of the omniscopeserver or the full name (with domain) as it is going to be used to access the omniscope server from the browser
    Note: The browser cannot use Single-Sign-On when accessing the omniscopeserver by IP instead of name, and the name has to be added to the zone
  - Click Close then OK to close the Local intranet dialogs
  - Click Custom Level... button, scroll down to User Authentication and select Automatic logon with current user name and password then click OK to close the dialog
  - In the Advanced tab of the Internet Options dialog scroll down to Security section and make sure Enable Integrated Windows Authentication option is selected. (It should be selected by default)
  - Click OK to close Internet Options dialog
  - Restart Internet Explorer
  - Test it: open http://omniscopeserver you should be able to use omniscope server if you have the right permissions (group permissions that you set up on Omniscope server)
- Google Chrome
  - Google’s Chrome browser shares the same configuration with Internet Explorer. Once the trusted URL is added in Internet Explorer, Chrome works with SPNEGO. Chrome does not have a configuration mechanism.
- Mozilla Firefox
  - In the address bar type:
    about:config
    
    and search for trusted. The required key is a comma separated parameter named network.negotiate-auth.trusted-uris - edit it to include 'omniscopeserver' as well

Security: Heartbleed bug CVE-2014-0160?

donald — Tue, 15 Apr 2014 13:54:37 -0400

This relates to the vulnerability listed for OpenSLL summarised by CVE-2014-0160 generally called the 'Heartbleed' security bug.

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

Visokio Omniscope
We do not believe that Omniscope is affected by this vulnerability.

Omniscope is written in Java and we have not received any reports that Java is affected by this vulnerability.

We have tested Omniscope mobile server with external Heartbleed checkers and no vulnerability was reported.

However, if you are presenting content hosted on Omniscope mobile server via a front end proxy or load balancer such as Apache or Nginx you should check the version of OpenSSL used on those products and take appropriate action. You are advised to do your own security and penetration testing.

The main Visokio website, KnowledgeBase and Forums are using a version of OpenSSL that is NOT affected by this vulnerability.

Downloads from our website are delivered through a third party content delivery network through http: and are not affected by this vulnerability.

Our activation server is not affected by this vulnerability.

Our alpha and staging test sites for our Omniscope mobile Alpha partners are not affected by this vulnerability.

Security: Web Server SSL configuration

antonio — Mon, 30 Sep 2013 08:53:33 -0400

Mobile Web Server now includes HTTPS support, and works out of the box with a self-signed certificate located into the omniscope-server install folder (named keystore.jks.default).

If you want to use your own fully validated SSL certificate, you need to configure the path and the password of the keystore file containing the certificate.

To generate keys and certificates, follow one of these two guides:
Generate a Self Signed Certificate using Java Keytool
Generate a Trusted Certificate

Security: Overview of Omniscope file-based security options

tjbate — Thu, 04 Jul 2013 14:31:20 -0400

Omniscope reporting solutions can employ many independent layers of file/data security settings, far more than other file-based 'reporting documents' like Excel. Omniscope also makes use of network identity-based and/or web-server/directory-based (Active Directory and LDAP) authentication options. However, unlike an SQL database held in the cloud, if the network/identity-based security is breached, mere possession of a copies of IOK files does NOT mean they can be opened and the data by unauthorised parties, because Omniscope also has layers of file-based security options.

It is good practise to always time-limit IOK files containing important data. If the files fall into the wrong hands, even if they are unlocked and otherwise unsecured, the proprietary Omniscope encryption and compression should hold the unauthorised users off the data for a few days until the IOK file 'times out', at which point no one can gain access to the data, no matter how much hacking they employ (assuming you use the Omniscope option to set the files to confirm the date/time independently from an Internet source outside the machine running the file. If you don't use this option, time-limiting can be defeated by changing the system clock on the machine running the file).

The best security is multiple, independent, layered security spanning both network/identity based, and file-based security. Omniscope permits file level security options to be added on top of network-based security to achieve multi-level security you can tailor. Omniscope file security options are outlined here:

http://www.visokio.com/file-security

Running analytics and reporting projects on instantly-available virtual, cloud-based, high-RAM machines makes a lot of sense, but many are reluctant to do this because they fear that their data in the cloud can be stolen. If you use an SQL database as the source in the cloud, this is much more likely than if you use a set of Omniscope IOK files as the source, provided you fully employ the range of layered independent security options Omniscope supports.

Deployment: WebStart - security issue?

walsh — Thu, 29 Nov 2012 17:56:26 -0500

We've recently had an update of our desktop software and, since then, I haven't been able to run my reports with WebStart. I get an error message:

Unsigned application requesting unrestricted access to system
Unsigned resource: http://downloads.visokio.com/omni27...

I don't pretend to understand the detailed message, but it contains the lines:

which looks like the sort of thing that would give our IT Risk people a major problem. Is there really a requirement for "*all* permissions" on my machine?

Edit 3rd Dec: I've spoken with some support people here and, although they weren't able to help directly, they mentioned that the "Unsigned" parts of the error message (newly highlighted above) may cause a problemwith our systems here.

Edit 5th Dec: Fwiw, the aforementioned "update of our desktop software" contained the following: Upgrade JRE to the new version 6u33

Security: How to share reports via Internet?

Kefsid — Fri, 13 Jan 2012 06:48:16 -0500

I wanna display my reports to our clients via Internet like kefsid.com/report but first they need to log in with their password and at the same time some of the data must be filtered according to their username so that they ll not be able to see the others data.

Is it possible?

Security: Time limiting files?

Paul — Wed, 20 Apr 2011 12:27:20 -0400

Using the Professional version, is it possible to set an expiration date for a file such that it won't open after a specified date/ I'd like to send a potential client a file but wouldn't like them to have usage of it forever.

Security: Domain locking from Desktop?

Kiddo29 — Thu, 20 Oct 2011 09:40:37 -0400

Hi there,

Quick one. I wanted to domain lock an iok file but in version 2.6 i cant seem to find an option for it. On your website it says for 2.5 go to save as and tic the box which says domain lock but there isn't one in 2.6.

Could you direct me to where this option is in 2.6 please?

Thanks

Security: Owner-locked option is greyed out in Desktop version 2.6?

elitem — Tue, 14 Jun 2011 11:00:08 -0400

I'm trying to protect a file by making it an "owner-locked" file, so that other users can't save or export.
I go to File -> File Security -> and there's an option to Password Protect the file, or Owner-lock. The latter is greyed out.

How can I lock the file?
Thanks