Reference8:Delegated Authentication

Applies to

All devices with firmware version 8 and later.

Overview

Each device has its own administrator/viewer accounts.

In version 8 and later a single device can act as an authentication server for the rest of the devices. User accounts that are managed on the authentication server can be used to login on each device in the installation. You can also configure devices to accept user accounts from a Windows domain.

How it works

Version 8 devices can use Kerberos to authenticate users that are not managed locally but on a remote Kerberos server.

Kerberos

A Kerberos server manages users and services for a realm that is specified by a distinct name. It shares a secret password with each user and each service. Users can obtain a ticket for a service from the Kerberos server if they proove that they know their own password. Services can then authenticate users by validating tickets instead of passwords. Therefore many devices can be accessed using the same user credentials but only the Kerberos server and the user have to know it.

Logging in

The main idea of how the centralized login process works in version 8 is the following:

1. The browser sends user name and password to the box, using HTTP basic authentication.
2. The box then uses Kerberos to obtain a ticket on behalf of the user from the Kerberos server for its own web server.

If that was successful the password is valid and the user is authenticated.

Cross realm authentication

Cross-realm authentication means that users from one realm/domain can login to services from another realm/domain. To do so, the realms have to trust each other and have a shared secret password to decrypt ticket from the other realm. The picture shows how cross-realm authentication is used to login with a Windows domain user at an innovaphone box.

1. The browser sends user name and password of a Windows domain user to the box, using HTTP basic authentication.
2. The box authenticates with the user credentials against the Windows Kerberos server and gets back a ticket-granting ticket.
3. The box uses the ticket-granting ticket to get a ticket for the innovaphone Kerberos server.
4. The box uses the cross-realm ticket to obtain a ticket on behalf of the user from the innovaphone Kerberos server for its own web server.

If that was successful the password is valid and the user is authenticated.

Authorization

Tickets issued by an innovaphone Kerberos server contain some information whether the user is an administrator or a viewer.

Configuration

Configuration is done using the General/Admin page from the web administration interface. See: Reference8:Configuration/General/Admin

Setting up the Kerberos server

1. Enter the name of the Server Realm.

Now the Kerberos server is running and provides authentication for the local user accounts of the box.

Setting up the client devices

Note: The box that hosts the Kerberos server might also be a client device and have to join the realm.

1. Configure the Server Locations of the Kerberos servers of all involved realms. Don't forget servers that are needed for cross-realm authentication.
2. Join the desired Kerberos realm. To do that you will need some administrator credentials from that realm.

Now the device can authenticate users of the realm.

Setting up cross-realm authentication

1. On the server device, specify the Trusted Realms, the corresponding passwords and the methods of authorization mapping.
2. Configure the Server Location on each client device.

There are different methods of mapping authorization between realm:

• None (works only with innovaphone servers)
• Grant administrator access to all users
• Grant viewer access to all users
• Map the Windows domain group membership from the ticket to administrator or viewer rights

If you use the latter, please specify the RID of the groups that shall have administrator or viewer rights, respectively.

Determining the RID of a Windows domain group

The RID (relative ID) of a Windows domain group is the last numeric part of the domain group SID (secure ID).

The easiest way to determine it for a group you are a member of is using the following command:

   whoami /groups /sid

   [Group  1] = "DOMAIN\Domain-Users"  S-1-5-21-854245398-616249376-725345543-513
   [Group  2] = "DOMAIN\Admins"  S-1-5-21-854245398-616249376-725345543-1180

In this example the RID for DOMAIN\Domain-Users is 513 and the RID for DOMAIN\Admins is 1180.

Using it

Logging in with the web browser

To distinguish between local users and users of a Kerberos realm, the name of the realm has to be prepended to the user name, separated by a backslash ('\')

Example:

• Local user: admin
• Remote user: REALM\radmin

Security considerations

Use HTTPS

As HTTP basic authentication transmits plaintext passwords, the use of HTTPS is mandatory. Please disable normal HTTP access to the devices or enable Force HTTPS.

Use local users only for recovery purposes

Although the old local user accounts of devices can still be used to login, this should not be done.

We recommend to choose a different secure administrator password for each device. After Single Sign-On has been configured, the list of admin passwords should be locked away and used only for recovery purposes. For normal configuration only user accounts from the Kerberos realm should be used to access devices.

We recommend that because it is much easier to change the password of or delete a compromised user account on the Kerberos server than changing the local administrator passwords on each device.