Course12:Advanced - Kerberos
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
Protocol
Wikipedia says: " 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.
- 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
-
- 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
-
The good news is, there is no real need to understand this! As long as it is configured right, it just works!
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, 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 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:
- The browser does not talk kerberos to the box-to-be-administered! The box-to-be-administered does talk kerberos to the central box
- 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
Active Directory as Kerberos AS
When looking at the drawing, there are 2 important issues to understand:
- The central box managing the devices needs to know and trust the AD
- 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
In Windows, it is a bit more complicated and depends on the Windows AD version you run. This 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
Authorization
When using users from the innovaphone Box
There are actually 2 ways to set up the Kerberos server on an innovaphone box:
- You can use explicit Kerberos users defined in the Additional Users area of the
General/Kerberos page.
In this case, you simply select the rights from the Authorization drop down (Administrator, Viewer, Join Realm) - You can use the PBX users.
Each eligible PBX user acts as a kerberos user (see theDelegated 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
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!
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
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
When you use Microsoft's Active Directory service, you can as well use the primary and secondary domain controllers as NTP source.
Servers
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
When you use the stand-alone kerberos server, you can choose a realm name and define it as Realm in
When you use an Microsoft AD as an Authentication Server, then you need to 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
For the PBX-based kerberos server, you will find the same settings in the Trusted realms area of
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
When you use the stand-alone kerberos server, then the rights are configured directly along with the users in the Users area in
When you use the Active Directory server, the rights for the users may be inferred from the AD group membership.
Fort this, you need to 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
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
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
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
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 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
However, this can also be initiated automatically through commands or in update server scripts.
Diagnostics
Try the following:
- inspect the event log. There are a number of events fired in case of problems (e.g.
Event/0x000c0403 ,Event/0x000c0406 andEvent/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 write
config activate
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:
-
General/Kerberos : realm is correct? (if you use stand-alone kerberos) - users exist with correct passwords? (either in
General/Kerberos orPBX/Objects - is the device to be logged in in the Hosts list in
General/Kerberos orPBX/Config/Security - on the device you try to log-on to
-
General/Admin : Kerberos Realm correct (REALM1) - Host Name in
General/Admin correct? must match the SerialNo inGeneral/Info (should be ok by default) - Authentications Servers list in
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)
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
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 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.