Zero Touch Provisioning

What it is

Zero touch provisioning is a way to bring a device into service without anyone typing its configuration by hand.

The device powers on, finds a source for its settings, and configures itself. It cuts the time and the typing errors of a manual build. The same idea applies to network devices and to ISE nodes.

How it works

A new device needs a minimum day zero configuration, and everything else can follow from a central source.

The day zero configuration

A day zero configuration holds only what is needed to be reachable and to join the system. For an ISE node that means a hostname, an IP address with mask and gateway, DNS, a domain name, NTP, a time zone, and an admin account.

With the normal install you type these into the setup wizard on the console. In an automated build you supply them in another way, so no one has to attend the console.

Automating an ISE node build

The common ways to give a new ISE node its day zero settings are:

• Virtual machine template properties. When you deploy the template, you fill in the settings, and the node reads them at first boot.
• Cloud instance user data. On a public cloud, the instance takes the settings from the data you attach when you launch it.
• Cloned or scripted builds. Automation tools create the node and pass the same values.

After the node boots, you still register it from the primary PAN. Registration, personas and certificates follow the normal steps. Automation saves the console work, not the deployment design.

Provisioning network devices

For switches and wireless controllers, the zero touch idea is to plug in a new device and have it fetch its configuration. A common pattern is:

1. The device boots with no configuration.
2. It gets an IP address by DHCP. The DHCP reply can carry the address of a provisioning server.
3. It contacts the server and downloads a template.
4. The template includes the AAA settings that point the device at ISE.

Cisco platforms have their own tools for this. On Catalyst switches the usual one is Plug and Play, which can run from a controller such as Catalyst Center. The details differ by platform and release, so check the product guide.

The ISE side of a new device

A device that gets its configuration automatically still has to be known to ISE. If ISE does not have it in the network devices list, the PSN rejects its RADIUS requests.

You can add devices by hand, import them from a file, or add them in bulk. You can also use network device groups to keep the policy tidy. The shared secret in ISE has to match the key the template puts on the device.

Switch(config)# aaa new-model
Switch(config)# radius server ISE-PSN1
Switch(config-radius-server)# address ipv4 10.1.1.11 auth-port 1812 acct-port 1813
Switch(config-radius-server)# key SECRET
Switch(config-radius-server)# exit
Switch(config)# aaa group server radius ISE-GRP
Switch(config-sg-radius)# server name ISE-PSN1

This IOS XE snippet is the kind of block a provisioning template carries. The key SECRET is a placeholder.

Keeping the secret safe

A template that contains a shared secret must be stored with care. Use a different secret per device group where you can, so one leaked secret does not expose all devices. Change the secret in both places at once, since a mismatch causes authentication to fail.

Checking the result

After a new device comes up, check it from both sides. On the device, look at the RADIUS server state. On ISE, look at the live logs for requests from the device.

Switch# show aaa servers
Switch# show authentication sessions

If ISE logs a request from an unknown device, the device is missing from the list or its address is wrong.