• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting
    
    
  
  

LDAP Query Mechanism

• Users are stored and managed by an LDAP/Active Directory (AD) server
• Omniscope Mobile server is configured to query the LDAP/AD server

Prerequisites

• LDAP distinguished name (e.g CN=Users,DC=example,DC=com)
• LDAP URL and port (e.g. LDAP://ldapserver.example.com:389)
• LDAP security authentication type (e.g. simple, or CRAM-MD5, or DIGEST-MD5, or none)
• Local domain name (e.g. example.com)
• Whether your LDAP/AD server has been configured to use your trusted certificate (only if you want to use LDAPS instead of LDAP which does not need that information)

Configuration

1. Start Omniscope Mobile server
   
   
   
   
2. On Mobile Web Server service section click Config, scroll down to Default folder configuration and click Edit
   
   
   
   
3. Either create a new group with new permissions, or edit an existing group
   
   
   
   
   
   
4. Edit LDAP settings
   
   
   
   
   • Type LDAP distinguished name (e.g CN=Users,DC=example,DC=com), it should match the distinguished name configured on your LDAP server
   • Optional: on the LDAP/AD server create a dedicated user to be used only by Omniscope Mobile server to authenticate users and add this user in the LDAP/AD Dedicated User section
     Setting a dedicated user will help authenticate other users by their account name (which may be composed of their first name and last name). By default, users are authenticated using their account id (sAMAccountName) only
     
   • Type LDAP URL
     This is 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 the 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 the LDAPS protocol
   • Check Ignore Ssl certificate issues only if necessary (your LDAP/AD server has not been configured to use your trusted certificate and you want to use LDAPS protocol instead of LDAP )
   • Select the 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 like CRAM-MD5, or DIGEST-MD5, or none
   • Select principal name format. Choosing DOMAIN\{Name} or {Name}@DOMAIN will enable Omniscope server to prepend/append the domain name automatically if the user did not type it already
   • Type your local domain name to be appended to usernames automatically when authenticating users. This field will be disregarded if you selected {Name} for principal name format field
   
   

LDAP Filter

• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting

Single-Sign-On (SPNEGO) Mechanism

• 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:

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

• 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)

1. 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
   
   
2. 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
     
   
   
3. 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
       
       
     
     
   
   

• Group permissions
• Authentication mechanisms
  
  • List of users mechanism
  • LDAP query mechanism
  • SPNEGO (Single-Sign-On) mechanism
    
    • SPNEGO Troubleshooting
    
    
  
  

Mobile Web Server Authentication

A realm defines a protection space. Realms allow the protected resources on the server to be partitioned into a set of protection spaces, each with its own authentication and authorization settings.

By default, all protected resources on the server are configured in the config.xml file. This is the (Home) realm. Specific folders may be manually configured to have their own set of permissions and authentication groups. For more information about folder permissions read this post.

Server permissions may be configured for anonymous users and for authentication groups.

A group may have a list of authentication mechanisms and server permissions.

For instance, the server may be configured to have a group named 'Data Analysts' with permissions to:
- List directory
- View in mobile
- Export view data
and authenticate users through LDAP Query and List Of Users.

Authentication mechanisms

List Of Users

List Of Users mechanism let's you define custom Omniscope users that are stored and managed by the Omniscope Mobile server. No third party servers/services are involved. Users are manually added/edited/removed by an administrator of the server.

A user name and a password has to be added for each individual user. Read this post for more information about List Of Users mechanism configuration.

LDAP Query

LDAP Query authentication mechanism let's you configure Omniscope Mobile server to query an LDAP server to validate user credentials.

• Users are stored and managed by an LDAP/AD server
• Omniscope Mobile server is configured to query the LDAP/AD server

To learn how to configure Omniscope server to use LDAP Query read this post.

SPNEGO (Single-Sign-On) Mechanism

SPNEGO (Single-Sign-On) mechanism allows users to authenticate automatically with their LDAP/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
• LDAP/AD user password is never sent to Omniscope server
• Omniscope Mobile server is configured to ask the LDAP/AD server to validate user tokens

How does SPNEGO work ?

The browser negotiates with the LDAP/AD server and gets a temporary ticket which is further used to generate temporary unique tokens that are included in every client/browser request sent to Omniscope Mobile server. The tokens contain no information about client user name, password, or any other sensitive data, they are simple strings that can be verified only by the LDAP/AD server. Whenever Omniscope Mobile receives requests having SPNEGO tokens, Omniscope Mobile asks the LDAP/AD for token validation and if the token is valid, LDAP/AD provides only the user name associated with that token. Omniscope server checks whether this user is authorized to be served the requested resource and proceeds accordingly.

To learn how to configure Omniscope server to use SPNEGO mechanism read this post.

Authentication Groups

A group may have multiple authentication mechanisms. Each mechanism will be used during authentication until the user authenticates successfully. If no group authorizes the action that has been requested by the user, the access will be denied.

You may want to temporarily disable groups instead of deleting them and then adding them back later when needed. Disabled groups are disregarded during authentication.