In an earlier post I was having trouble getting core-dumps off an SRX as a non-root user. I thought I’d be able to do a ‘start shell’ and then simply ‘su’ to root – from there it’d be plain sailing. But no… The problem lay in the authentication order we had configured on the box.
There are several options for the authentication order in Junos:
Basically our unit was configured with the line:
set system authentication-order radius
This tells the system to use the external RADIUS server for all authentication. Only if the RADIUS server is not there (i.e. no response) does the local username/password database get consulted. So in our case, when I tried to ‘su’ to the root user, it would query the RADIUS server (which had no root user configured) and receive a deny message. Since there had been a RADIUS response, that was the end of the matter.
This is by design: it is assumed that RADIUS is authoritative at all times unless the SRX is not on the network. Only when disconnected from the network is the local database used.
We couldn’t add a ‘root’ user to RADIUS because it was doing authentications for all sorts of other devices. So an alternative method for getting root access was to add ‘password’ to the authentication order:
set system authentication-order [ radius password ]
What happens now is the system tries to authenticate the root user using RADIUS and gets a deny. It then moves on to the second authentication method – the local database. This obviously succeeds.
We don’t really want to leave it like this, so the password method was only added for long enough to get the core files off the device. We prefer to leave the root user’s account for emergency purposes only, relying on the central control that RADIUS gives us for day-to-day authentication.