Reference8:Delegated Authentication

From innovaphone wiki
Jump to navigation Jump to search
There are also other versions of this article available: Reference8 (this version) | Reference10

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 PBX or 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:

Login kerberos basic.png

  1. The browser sends user name and password to the box, using HTTPS 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 tickets from the other realm. This password has to be configured on both Kerberos servers. The picture shows how cross-realm authentication is used to login with a Windows domain user at an innovaphone box.

Login kerberos basic crossrealm.png

  1. The browser sends user name and password of a Windows domain user to the box, using HTTPS 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.

HTTPS for encryption

The box needs username and password in the clear to delegate authentication. Basic authentication is used to send that information from the web browser to the box. This message exchange has to be encrypted using HTTPS.

In order to protect user passwords from eavesdropping and to stay compatible with existing configurations at the same time, our devices implement the following behaviour if Kerberos is enabled.

HTTP

  • No change to the normal behaviour
  • Digest or Basic authentication is offered
  • Local users from the box, only

HTTPS

  • Basic authentication, only
  • Local users and remote Kerberos users.

As a consequence you have to use HTTPS if you want to login with a Kerberos user account.

Authorization

Tickets issued by an innovaphone Kerberos server contain some information whether the user is an administrator or a viewer. When it comes to cross-realm authentication with a Windows domain the innovaphone Kerberos server can map between Windows group memberships and administrator rights.

Kerberos servers on the innovaphone platform

V8 gateways are capable of hosting multiple Kerberos servers at a time.

Stand-alone Kerberos server

Each gateway can host a single Kerberos server that can be configured freely.

The PBX as a Kerberos server

Each PBX also provides for Kerberos authentication for its users without additional configuration:

  • The System Name of the PBX is the name of the realm.
  • Users with both a password and rights defined can be used for delegated authentication.
  • The Name of the user object in the PBX can be used as the user name for authentication.
  • Users with the right Full PBX Administration are administrators in the Kerberos realm. Users with other rights are viewers.
  • LDAP replication also works with the Kerberos information.
  • There is a special user called _KADMIN_ that can be used to add devices to the realm but not to login to the user interface.

Configuration

Important Note: Every device that will use kerberos should have a valid NTP server wich is in sync with the other devices

Setting up the Kerberos server

The Kerberos server of a PBX is configured using the PBX/Security page (see Reference8:Administration/PBX/Security).

Configuration of the stand-alone Kerberos server is done using the General/Kerberos page (see Reference8:Configuration/General/Kerberos).

  1. Enter a LDAP password. This password is used to encrypt keys in the LDAP directory of the server.
  2. Configure the name of the realm.

Now the server is running. You can now create and manage user accounts.

Setting up the client devices

Configuration of the clients is done using the General/Admin page from the web administration interface (see Reference8:Configuration/General/Admin).

  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. You will need the credentials of an user account of that realm with administrator or join realm rights in order to do that.

Now the device can authenticate users from the realm for HTTPS connections. You can deactivate the local user accounts on the device, if needed.

Note: The box that hosts the Kerberos server might also be a client device and have to join 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:

  • keep (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.

Other way to get an SID of some specific group (even if current logged in user is not a member of this group):

$(New-Object System.Security.Principal.NTAccount("DOMAIN\Domain-Users")).Translate([System.Security.Principal.SecurityIdentifier]).Value
S-1-5-21-854245398-616249376-725345543-513

Determining the Realm-Name of a Windows Domain

As described in [1] the Realm-Name is always the upper case version of the domains DNS name. E.g. if domain name is mycompany.local, the Realm-Name will be MYCOMPANY.LOCAL.

NetBIOS Domain Name can not be used as a Realm-Name!

Prerequisites for Windows groups

You can use a Windows group for authorization if

  • it is in the domain of the users
  • it is a global security group
  • it does not contain nested groups

Configuring a Windows Server for cross-realm authentication

  • Set up the trust relationship between your Kerberos realm and the Windows domain. [1]
  • Enable DES-CBC-MD5 encryption, if needed. [2]

Using it

Once configured you can use Kerberos user accounts for logging in to the administation interface of boxes using your web browser.

Use HTTPS for Kerberos users

Delegated authentication works only with HTTPS connections. Using HTTP the boxes accept only local user accounts.

User names

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 (\). Alternatively you can prepend the realm to the user name separated by an at (@).

Example:

  • Local user: admin
  • Remote user: REALM\username or username@REALM

Mind that realm names are case sensitive and that they are usually written in upper case letters.

Security considerations

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.

References

Known Problems

Due to UDP packet size limitation it could happen that on Windows Users with big number of Groups assigned (usually 150 or more, depending on number of nested groups) the Windows Kerberos Server generate an error

"KRB5KRB_ERR_RESPONSE_TOO_BIG (52)

A workaround at the moment would be to reduce number of assigned Groups on the User that tries to authenticate.