Cisco – Passwordless Kerberos management of Cisco devices


Does anyone have any experience of using Kerberos as an authentication mechanism for managing a Cisco IOS based network? This article seems to indicate it's possible, but my Kerberos knowledge is limited to that of a user on centrally managed UNIX/Linux systems. Before I spend hours trying to lab this up, I thought I would ask for advice here.

Specifically, given a functioning Kerberos authentication infrastructure, is it possible to configure Cisco devices to accept forwarded Kerberos credentials from a *NIX or Windows machine where I have already authenticated and have a valid Kerberos ticket? It would be really nice not to have to type my password every single time I log in to a device.

If this is possible, some further extensions:

  1. Is it possible to use Kerberos for authentication, but to continue to use TACACS+ groups for authorisation?

  2. Under what conditions will a device configured to use Kerberos authentication fall back to locally defined passwords?

  3. What implications does using Kerberos have for performing RMAs/hardware replacements? (e.g., if using SSH only as a means of management, if a device is replaced, SSH keys must be regenerated manually and old known_hosts entries on management stations must be removed, etc)

  4. When using Kerberos authentication, will a user still be prompted for a password when elevating from EXEC mode to privileged EXEC (enable) mode?

Best Answer

A long time ago, yes, I did get it to work with some Cisco terminal servers I set up. However, I no longer use it for very simple reasons, not the least of which is, when the network has gone to hell, the fewer moving parts I need to have up in order to log into a router, the better.

The quick answers from memory:

  1. Yes.
  2. I believe there was either an explicit ordering or implicit one. Somewhere. I seem to remember local passwords working in preference to remote ones.
  3. Kerberos requires you to place data on the IOS gear (the machine's SRVTAB) which you will want to change if the gear is swapped out, and remove the old key from your Kerberos database. However, this is a change that users (via telnet) won't see a change.
  4. If memory served, the enable password was not Kerberos-capable.

Once again, this is all from memory, several years old at least.