Course11:Advanced - Kerberos

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

How innovaphone can act as a Kerberos Server

Overview

This book explains Kerberos and its usage in conjunction with innovaphone devices.

  • What is Kerberos?
  • How does it work?
  • What can I do with Kerberos?
  • How do I configure Kerberos?
  • Why should I always do it?

See also the innovaphone wiki article fish-help.png Concept Delegated Authentication

Protocol

Wikipedia says: "wikipedia.ico Kerberos is a computer network authentication protocol which works on the basis of "tickets" to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner".

In an innovaphone context, such nodes are innovaphone devices (gateways and phones) and browsers used for administration of such devices. In particular, it allows the authentication of administrators (which attempt to use a browser to get access to the device) to be implemented in a uniform manner, so that one administrator can login to all the devices with a single account and password. Instead of using the individual admin account and password configured in the device in question, the administrator would always use credentials which have been defined in the one device in the network which has been configured to be the kerberos server.

Kerberos has the ability to prevent passive eavesdropping and man in the middle attacks and is thus thought to be "secure".

How the Protocol works

The protocol uses tickets for authentication. Kerberos authenticates the server against the client and the client versus the server. Kerberos itself authenticates to the server and the client.

Kerberos Overview
  1. Client authentication
    • The user enters a username and password
    • The client requests a Ticket Granting Ticket (TGT) from the Authentication Server (AS) (no password is sent to the AS, just the user id)
    • If the user id is known to the AS, it sends a TGT to the client
    • If the password entered at the client matches the one the AS has stored for the user id, the client can extract a Client/TGS Session Key from the response

       
  2. Request ticket for service / application
    • When the client likes to request services from a Service Server (SS) , it sends messages to the Ticket Granting Service (TGS) requesting a Client-to-server ticket
    • The TGS sends back a Client-to-Server Ticket and a Client/Server Session Key
    • From this data, the client creates an Authenticator and sends it along with the Client-to-Server Ticket to the SS
    • The SS sends back a message that indicates the willingness to perform the service and also authenticates the SS to the client
    • When the client accepts the SS's identity, it performs the desired service requests
Sounds difficult?
The good news is, there is no real need to understand this! As long as it is configured right, it just works wide eyes!

The more important thing to understand is that in order for the kerberos process to succeed, the AS needs to know the credentials (that is, the user id and password) of the client. You may have wondered, why there are 2 instances involved, the AS and the TGS. Most often, both services are in fact implemented in the same box. However, the distinction allows kerberos to rely on a foreign system to manage user ids and passwords. Practically spoken, as Microsoft's Active Directory can work as a Kerberos AS, Windows user accounts and their passwords can be used!

Hint: Realm is an administrative district of a Kerberos server. All physical machines (so called Principals) must be member of such a realm.


Kerberos and innovaphone

So in the innovaphone scenario, who acts as AS, TGS and SS?

In most scenarios, the answer is quite simple: AS and TGS reside in the same box, which is the box that manages the user ids and passwords used for kerberos. On the other end, both the SS and the client reside in another box and the service to be used is the administration UI of the this other box. In other words, screenshot.png we have one box that manages the admin accounts for all boxes in the innovaphone installation. Btw: when we talk of box here, this refers to any type of innovaphone device, including telephones.

One thing however is still strange? If the box-to-be-administered is the client, then - given that this box does not have a keyboard - how does the user type in the account and password?

The answer is, of course, the user types it in to the browser!

So here we have a screenshot.png more complete picture.

As you might have guessed already from the protocol description, the client, that is the-box-to-be-administered, needs to know the password in clear. There are two important implications here:

  1. The browser does not talk kerberos to the box-to-be-administered! The box-to-be-administered does talk kerberos to the central box
  2. The browser needs a secure way to send the password to the box-to-be-administered

Because of this, the password is sent via HTTPS to the box-to-be-administered. And as a result, kerberos authentication to an innovaphone box only works when logging in with HTTPS. Keep this in mind, it will save you headaches later on!

Sounds strange to you? The reason is simply that vendor-independant kerberos support is not widely found in contemporary browsers. Because of this, a scheme that requires the browser to talk kerberos is not that useful.

Kerberos and Active Directory

Microsoft's Windows Active Directory Server can act as an Authentication Server (AS) in an innovaphone kerberos scenario. This allows you to allow users from the active directory to act as admins.

screenshot.png Active Directory as Kerberos AS

When looking at the drawing, there are 2 important issues to understand:
  1. The central box managing the devices needs to know and trust the AD
  2. All devices need to know both the central box and the AD

Setting up a trust between your AD and your innovaphone kerberos realm basically involves sharing a secret (in other words: both side need to know the same password for the relationship). This is done in the Trusted realms area of the fish-help.png General/Kerberos page.

In Windows, it is a bit more complicated and depends on the Windows AD version you run. This www.png Microsoft KB article may be a good start. Look for Create an external trust.

To have the potential boxes-to-be-administered know both the innovaphone and Windows Kerberos servers, they need to be defined in the Authentication Servers area of the fish-help.png General/Admin page. As this must be done on all devices, you should consider doing it via Update Manager as part of the staging process (see topic Advanced Operations in this course and fish-help.png How to configure Kerberos using commands in the wiki).


Authorization

With the protocol description and and the screenshot.png big picture in mind, you may wonder how the system can know if an existing user actually is allowed to do administrative work. That is, of course not any user that exists and can authenticate successfully is allowed to be an administrator! In other words, how does the authorization work?

When using users from the innovaphone Box


There are actually 2 ways to fish-help.png set up the Kerberos server on an innovaphone box:
  1. You can use explicit Kerberos users defined in the Additional Users area of the fish-help.png General/Kerberos page.
    In this case, you simply select the rights from the Authorization drop down (Administrator, Viewer, Join Realm)
  2. You can use the PBX users.
    Each eligible PBX user acts as a kerberos user (see the fish-help.png Delegated Authentication for details on which criteria must be met).
    In this case, the rights are derived from the rights given to the user in the PBX

When using users from the Active Directory

In fact, Kerberos really does not deal with Authorization and as a result, no rights can be inferred from the authentication process in a standardized way.

However, Microsoft's AD sends the users group memberships along with the Authentication Servers response. This allows us to infer rights for users from the AD group membership. In other words, a group can be defined in fish-help.png General/Kerberos and all users belonging to this group are then treated as admins. See fish-help.png Delegated Authentication in the wiki on details how this works.

Security Implications

It should be pretty obvious, that access to the devices should be controlled in a secure manner. One of the implications is that administrator should use personal accounts with individual passwords for this, not generic pseudo accounts such as "admin". For one, this allows to track down who has done what to the system and also, probably even more important, it allows you to grant and revoke access by just adding or removing accounts.

As a real-world installation can easily consist of several hundred devices (each phone is a device!), this would mean - without kerberos - to maintain all accounts with administration rights on hundreds of devices consistently. You need to do the settings on every device. Even more, if the passwords needs to be changed (for example because your best administrator left your company), you need to change it on each and any single device locally - and be sure not to forget one. Not a task you want to be in charge for!

Now, with assistance of the Kerberos technology, it´s possible to manage all those accounts it centrally. Thus the administration is drastically reduced. Customers using Microsoft AD can even rely on this.

So the bottom line is:
  • Administrative access to devices should never rely on the local admin account
  • This should be used only for disaster discovery and its password should be known for very few persons only
  • Every administrator should have an individual account
  • Kerberos should be used for the managament of these accounts

And of course: the standard user and password should always be changed from the default!

Configuration

For the kerberos system to work, you need to setup both the kerberos servers and all the clients.

The kerberos protocol relies on correct time on all servers and clients. So if one of them has no time or not the correct time, kerberos will not work! It is thus important to share the same clock on all devices. To achieve this, you may configure the same time server(s) in Time Server 1 and Time Server 2 in fish-help.png Services/NTP.

When you use Microsoft's Active Directory service, you can as well use the primary and secondary domain controllers as NTP source.

Servers

When using Kerberos, you most probably want to configure redundancy. This makes sure you always have access to a kerberos server. Keep in mind that with kerberos, if no server is available, you will have no administrational access to any device in your setup!

Your first decision thus is which boxes you will use as kerberos servers. In many cases, you will simply use your master PBX and its stand-by PBX as kerberos server and kerberos backup server.

When using Active Directory, then you need to know the IP address of your domain controller (primary kerberos server for the AS domain) and secondary domain controller (stand-by kerberos server for the AS domain).

Realm Names

Moreover, to configure kerberos, you need to decide which Kerberos servers you want to use:

  • Do you use the PBX as Kerberos Server?
  • Do you use the the stand alone Kerberos Server on the Gateway level?
  • Do you use Microsoft's Active Directory Service (AD) as Authentication Server?

In most cases, you will decide for either the PBX or the stand-alone Kerberos server, whereas theoretically, you could use both.

When you intend to use the PBX as a kerberos server, then this also defines the name of your kerberos realm. It is the PBX's system name as defined as System Name in fish-help.png PBX/Config/General.

When you use the stand-alone kerberos server, you can choose a realm name and define it as Realm in fish-help.png General/Kerberos. However, should you intend to use both servers (PBX and stand-alone), then you must make sure that both have different realm names!

When you use an Microsoft AD as an Authentication Server, then you need to fish-help.png determine its realm name (which again must be different from the realm name you use in the PBX or stand-alone server). This will usually be the internal DNS name used for your domain with all letters converted to uppercase.

Trust

If you use Microsoft's AD, then you need to establish a trust relationship between the AD and your kerberos server.

For the stand-alone kerberos server, this is done in the Trusted realms area in fish-help.png General/Kerberos. You will need to know the the IP address of the foreign server (that is, of your AD server) and you must assign a password for this relationship. The password must be known on both sides, so you will need to configure the same password when creating the trust relationship on the other (that is, Windows) side,

For the PBX-based kerberos server, you will find the same settings in the Trusted realms area of fish-help.png PBX/Config/Security.

User Rights

When you use the PBX-based Kerberos server, the rights for a user (that is, its authorization) is inferred from the Rights column of the fish-help.png PBX/Objects list. Users with the right Full PBX Administration are administrators in the Kerberos realm. Users with other rights are viewers.

When you use the stand-alone kerberos server, then the rights are configured directly along with the users in the Users area in fish-help.png General/Kerberos.

When you use the Active Directory server, the rights for the users fish-help.png may be inferred from the AD group membership.

Fort this, you need to fish-help.png determine the RID of the AD-groups you want to map to admin and viewer rights and define the mapping in the Trusted realms area in fish-help.png General/Kerberos (or the Trusted realms area in fish-help.png PBX/Config/Security if you use the PBX-based kerberos server).

The special Join Realm Right

Each device that shall use kerberos needs to be member of the kerberos realm. Normally, joining a realm is done by an administrator. Users with viewer rights only are not allowed to do this.

However, sometimes it is useful to have an account that may join a device in to a realm, but is not an administrator. This for example makes sense if devices shall be joined to the realm automatically during staging.

In the stand-alone kerberos server, you define the select the Join Realm right in the Authorization column of the user entry in the Users area in fish-help.png General/Kerberos.

When using the PBX-base kerberos server, the pre-defined user _KADMIN_ can be used for this. Its password must be set in the _KADMIN_ password area in fish-help.png PBX/Config/Security.


Clients

Setting up the clients is straight forward.

Keep in mind that even the kerberos servers used act as kerberos clients whenever someone tries to access the admin UI. So this chapter applies to servers too!

Finding the Kerberos Servers


Clients need to be able to access all the relevant kerberos servers. In our scenario, this will be

  • the primary kerberos server
  • the secondary kerberos server
  • the primary active directory server if AD is used
  • the secondary active directory server if AD is used

There are 2 options to find the servers. You can of course simply configure all of them in the Authentication Servers area in fish-help.png General/Admin.

Make sure that - if you use Microsoft's Active Directory (AD) - configure both the servers for your own kerberos domain, as well as the server for the AD domain! These will have two different domain names and thus 2 entries in the Authentication Servers list (with potentially an Address (primary server) and a Sec. Address (secondary server)).

However, the built-in kerberos client is able to find the right kerberos server (based on the realm) even if no servers at all are configured. If no server for a realm is configured, the client will try to fish-help.png locate a DNS SRV record that describes the kerberos service. Typically, your Active Directory server will have such a DNS SRV record.

The only thing left is that each client must be member of the realm. This can be done manually using the Join realm link in the Delegated Authentication area of fish-help.png General/Admin.

However, this can also be initiated automatically through fish-help.png commands or in update server scripts.

Diagnostics

Kerberos log-in failures are a little hard to debug.

Try the following:
  • inspect the event log. There are a number of events fired in case of problems (e.g. fish-help.png Event/0x000c0403, fish-help.png Event/0x000c0406 and fish-help.png Event/0x000c0407)
  • on the client, load the config line config add CMD0 /kerberos-trace (remember: the client is the box you want to log in to, not your browser)
  • on the server (where you have the kerberos accounts), load the config line config add KERBEROS /protocol-trace /trace
config add lines must be followed by
config write
config activate

(Overall Description) Latest V10 firmware (100811 or later) allow you to set these flags in the debug.xml page (i.e. http://172.31.31.1/debug.xml).

Here is a check list you should follow if authentication does not work:
  • on the kerberos server:
  • on the device you try to log-on to
    • fish-help.png General/Admin: Kerberos Realm correct (REALM1)
    • Host Name in fish-help.png General/Admin correct? must match the SerialNo in fish-help.png General/Info (should be ok by default)
    • Authentications Servers list in fish-help.png General/Admin includes your realm with correct IP address and port of your kerberos servers (if AD is used, these servers must be listed too!)
  • on both
    • check correct and synchronous time (NTP source on both sides)
Finally, make sure you try to log-in with HTTPS (as opposed to HTTP), as kerberos does not work with HTTP!

Deployment


Configure Kerberos using the Update Manager

The procedure of joining a Kerberos realm can be automated using an Update Manager script file. You can configure the Authorization servers and join the Kerberos realm by using the commands described in the wiki article fish-help.png How to configure Kerberos using commands.

It is recommended to use the _KADMIN_ account (for a PBX Kerberos server) or an Kerberos user with Join Realm Authorization (for a standalone Kerberos server) to Join the realm. This two user types were specially developed for this purpose, i.e. joining a realm using the Update Manager. The idea behind is that the update file is retrieved by the client using HTTP, in other words the Kerberos credentials are sent in plain text format over the LAN. If an attacker gets access to this data, he doesn't have the credentials of the admin user but can only use the hacked account to join this Kerberos realm.

Kerberos Login

After the Kerberos server and user configuration is finished, it´s possible to login with the previously created user accounts. The following information describe what you should consider.

A login with the aid of Kerberos works only with the secure HTTPS connection. For this scope it´s possible to activate the option Force HTTPS under fish-help.png Services/HTTP/Server.

Please use the following syntax for login.

  • REALM\user or
  • user@REALM

The realm is case-sensitive. Typically, names of Windows Kerberos realms don't contain lower-case letters.

For Windows domains, use the full domain name mapped to upper-case letters as realm, not the shorter NETBIOS name.