Exam objective 2.1, 'User Accounts and Authentication', is about controlling who can log into a Juniper device and what they can do once they get in. Imagine leaving your front door wide open with a sign that says 'come on in, do whatever you want' — that is a network device with no user accounts. This chapter makes sure you are the one locking that door and handing out keys to the right people.
Jump to a section
A simple way to picture User Accounts and Authentication
The security guard at the front desk of a corporate office building. Their job is to check every person who walks through the main entrance, but they don't treat everyone the same. When you first got hired, you visited the security office, gave them your photo ID and employment contract, and they created a badge for you. That badge has your name, your photo, and a little chip inside that stores what areas you're allowed to enter.
Now, every morning you tap that badge against the reader at the main door. The reader checks your badge's chip against a central computer that has a list of all active employees. If your badge is valid and you're on the list, the door clicks open. Simple. But here is where it gets clever: your badge doesn't give you the run of the whole building. The security computer knows you work in accounting, so your badge opens the ground floor accounting office, the break room, and the toilets. It does NOT open the server room on floor three, the CEO's penthouse, or the research lab in the basement. Those areas require a different security clearance.
If you ever leave the company, the security guard deactivates your badge in the central computer. The next time you try to tap in, the door stays locked. You no longer have any access. If a visitor comes, they get a temporary badge that only works during business hours and only opens the lobby and the meeting room they are booked into. The security guard never has to memorise every employee's face or permissions. The badge system handles it automatically. That is exactly how user accounts and authentication work on a Juniper router.
Every Juniper device running Junos OS, whether it is a router, a switch, or a firewall, needs a way to know who is touching it. Without user accounts, anyone who could physically connect a cable or reach the device over the network would have total, unrestricted power. They could shut down the entire network, delete the configuration, or steal sensitive data. That is a disaster. User accounts solve this problem by forcing every person to prove who they are before they get any access.
There are three main pieces to this puzzle: authentication, authorisation, and accounting. Authentication is the 'who are you?' step. It is the process of checking a username and password (or another credential) against a stored record. If the username exists and the password matches, the device says 'yes, you are who you claim to be'. Authorisation is the 'what are you allowed to do?' step. Once the device knows who you are, it looks up your permissions. Can you change the configuration? Can you only look at settings? Can you reboot the device? Accounting is the 'what did you do?' step. The device can log every command you type, every configuration change you make, and every time you log in or out. On Junos, accounting is optional but very useful for security audits.
Let us start with the most basic element: the local user account. A local user account is stored directly on the device itself, in its configuration file. It is like having a paper list of names and passwords taped to the side of the router. You create one using the 'set system login user' command. Each local user account must have at least two things: a username and an authentication method. The authentication method is how you prove your identity. The most common method is a password. You can set a plain-text password, but Junos will automatically encrypt it using a one-way hash. A hash is a mathematical transformation that turns a password into a scrambled string of characters. It is 'one-way' because you cannot reverse the process to get the original password. This means even if someone steals the configuration file, they cannot learn the passwords.
But a password alone is not enough. You also need to tell Junos what a user is allowed to do. That is where login classes come in. A login class is a pre-defined set of permissions. Think of a login class as a job role: a 'viewer' can only look at the configuration and status, a 'operator' can perform basic troubleshooting and reset interfaces, a 'super-user' has full access to everything. Junos comes with several built-in login classes. The most common ones are: \ - 'super-user': full read and write access to everything on the device, including the ability to change the configuration, reboot the system, and manage other user accounts.\ - 'operator': can view the configuration and status, run troubleshooting commands like 'ping' and 'traceroute', and clear certain statistics. Cannot change the configuration.\ - 'read-only': can only view the configuration and status. Cannot change anything or run most troubleshooting commands.\ - 'supervisor': similar to super-user but cannot change the system's root password or delete log files.\ When you create a local user account, you must assign it to one of these classes, or you can create your own custom login class with a precise combination of permissions. This is like creating a custom badge that opens only the specific doors you choose.
Authentication can happen in different ways. The simplest is using a local password stored on the device. But in larger organisations with many devices, it is a nightmare to manage passwords on every single router. If an employee quits, you would need to log into every device to delete their account. That is why Junos supports remote authentication servers. A remote authentication server is a central computer that stores all user accounts and passwords. When someone tries to log into a Juniper device, the device forwards the credentials to the remote server. The server checks them and replies with 'login allowed' or 'login denied'. There are two main protocols for this: RADIUS and TACACS+. RADIUS is an open standard protocol that combines authentication and authorisation into one packet. TACACS+ is a Cisco-developed protocol that separates authentication, authorisation, and accounting into separate packets, giving more granular control. Junos supports both. You configure a 'radius-server' or 'tacplus-server' under the 'system' hierarchy.
There is also the concept of authentication order. You can tell the device to try local authentication first, and if that fails, fall back to a remote server. Or you can try the remote server first, then fall back to local. This provides resilience. If the remote server is down, users can still log in using their local accounts. You configure this using the 'authentication-order' statement. The default order is 'password' (meaning local password authentication), but you can change it to 'radius', 'tacplus', or a combination like '[radius password]'.
Finally, there are a few other important details. The 'root' account is the super-admin account created automatically when the device is first booted. You must set a password for the root account during initial configuration. Unlike other accounts, the root account cannot be deleted. You can also set a 'login banner' — a message displayed to every user before they log in. This is often a legal warning. And you can set 'idle timeout' — if a user remains inactive for a set number of minutes, the device automatically logs them out. This is a security measure to prevent unauthorised access if someone walks away from a terminal.
Connect to the Device
You must first access the Juniper device, typically via a console cable, SSH, or a management interface. This step establishes a connection so you can enter configuration mode. Without this, you cannot create user accounts.
Enter Configuration Mode
Type 'configure' (or 'conf') to enter the Junos CLI configuration mode. All changes to user accounts and authentication are made here. The device will not let you modify the running configuration from operational mode.
Create the User Account with a Login Class
Use the command 'set system login user <username> class <class-name>' to create the user and assign a login class. The login class defines permissions. If you skip the class assignment, the account will exist but be unusable because no privileges are granted.
Set the Authentication Method
Use 'set system login user <username> authentication plain-text-password' to set a password. The device will prompt you to enter and confirm the password. This step is critical because without an authentication method, the user cannot prove their identity to log in.
(Optional) Configure Remote Authentication
If you want to use a central RADIUS or TACACS+ server, configure the server details with 'set system radius-server <ip> secret <key>' (or 'tacplus-server') and then set 'set system authentication-order radius'. This step centralises user management and is essential in larger networks.
Commit the Configuration
Type 'commit' to save and apply all changes. Until you commit, the configuration is only staged in memory. If the device reboots before a commit, all changes are lost. The commit makes the user accounts and authentication settings permanent.
Test the User Account
Log out of the device and try to log back in with the new username and password. This verifies that the account was created correctly and that the login class grants the expected level of access. If it fails, check the authentication order and password.
Let us put this into a concrete scenario. You are the first IT person at a small company that is growing fast. The company has just bought three Juniper SRX firewalls to secure its network. The boss says: 'I want to be able to log into these things, and I want the junior network engineer to be able to look at things but not break anything. And if anyone leaves, I want to delete their access quickly.' That is exactly what user accounts and authentication are for.
Step one: you rack the firewalls, power them on, and perform the initial configuration. This includes setting the root password. You type 'set system root-authentication plain-text-password' and then enter a very strong password. The root account is now locked down. No one can log in as root unless they know that password.
Step two: you create a local user account for your boss. You decide to give them 'super-user' access because they want full control. You type: \ - 'set system login user boss class super-user'\ - 'set system login user boss authentication plain-text-password' and then enter the password.\ Now your boss can log in with the username 'boss' and whatever password you set.
Step three: you create an account for the junior engineer. They only need to monitor the network, not change anything. You assign them the 'read-only' class. You type: \ - 'set system login user jane class read-only'\ - 'set system login user jane authentication plain-text-password' and then enter the password.\ Now Jane can log in and use 'show' commands to see the configuration and interface status, but if she tries to type 'set' to change anything, the device will reject the command.
Step four: the company grows to 50 employees and buys 10 more Juniper devices. Managing passwords on every device individually becomes painful. You set up a RADIUS server on a Linux machine in the server room. You install free RADIUS software (like FreeRADIUS) and create user accounts for all IT staff. Then, on each Juniper device, you configure it to use that RADIUS server for authentication. You type: \ - 'set system radius-server 192.168.1.100 secret MySecretKey'\ - 'set system authentication-order radius'\ Now when anyone logs into any Juniper device, the device sends their credentials to the RADIUS server. If a person leaves the company, you delete their account from the RADIUS server once, and they lose access to all devices immediately. No more logging into 10 devices.
Step five: you want to see who is logging in and what they are doing. You enable accounting. You configure the RADIUS server to also receive accounting packets. Now, every time a user logs in, runs a command, or logs out, the device sends a log entry to the RADIUS server. If something goes wrong — like someone accidentally shuts down a critical interface — you can look at the logs to see exactly which user did it and at what time.
This is the real-world workflow. It is not theoretical. Every network administrator does this on their first day on the job.
The JNCIA-JUNOS exam tests Objective 2.1 with specific, predictable question patterns. You will see multiple-choice and multiple-answer questions. Some questions ask you to pick the correct command to create a user. Others ask you to identify the effect of a given login class. Traps are everywhere. Here is what you need to know cold.
First, memorise the built-in login classes and their exact permissions. The exam loves to ask: 'Which login class allows a user to view the configuration but NOT change it?' The answer is 'read-only' (not 'operator', because operator can also run some troubleshooting commands that modify state, like clearing counters). Another classic: 'Which login class has full read and write access?' Answer: 'super-user'. They might try to trick you with 'supervisor' — remember that supervisor cannot change the root password or delete log files.
Second, know the command structure cold. Questions will ask: 'Which command creates a local user account named admin with super-user access?' The correct command starts with 'set system login user admin class super-user'. They might show you a command that says 'set system login class admin' — that is wrong because 'login class' is a different part of the hierarchy for defining custom classes, not for assigning a class to a user.
Third, understand the difference between authentication and authorisation. A frequent trap: 'Which protocol separates authentication and authorisation?' The answer is TACACS+. RADIUS combines them. They will give you a scenario where a company needs to audit commands per user, and ask which protocol supports that. TACACS+ separates accounting, so it is the correct choice.
Fourth, know the authentication order configuration. The exam will test: 'What is the default authentication order on Junos?' The answer is 'password' (local password). If you configure 'authentication-order [radius password]', the device tries RADIUS first; if the RADIUS server does not respond, it falls back to local. If you configure just 'radius', and the RADIUS server is unreachable, the device will reject the login attempt — no fallback.
Fifth, be aware of the root account specifics. The root account cannot be deleted. Its password is set using 'set system root-authentication plain-text-password'. The exam might ask: 'What happens if you try to delete the root user?' Trick: there is no 'delete system login user root' that permanently removes it — the root account always exists. You can only change its authentication method.
Here is a summary of the key exam topics: \ - Command syntax for creating local users ('set system login user <name> ...') \ - Command syntax for assigning a login class ('class <class-name>') \ - Built-in login classes: super-user, operator, read-only, supervisor, and their permissions \ - Custom login classes: how to define them with 'set system login class <name> ...' \ - Authentication methods: plain-text-password, ssh-rsa, ssh-dsa (public key authentication) \ - Remote authentication: RADIUS vs TACACS+ \ - Authentication order configuration \ - Root account configuration and limitations \ - Accounting configuration basics \
The exam will also test subtle points like: the difference between 'set system login user bob authentication plain-text-password' (you are prompted to enter the password) versus 'set system login user bob authentication encrypted-password <hash>' (you paste a pre-encrypted hash). The trap is that beginners think you can paste a plain-text password after 'encrypted-password' — but the device expects an already-encrypted hash.
A local user account must be assigned to a login class to determine what commands that user can run.
The root account is built into Junos and cannot be deleted, only its authentication method can be changed.
The default authentication order on Junos is 'password', meaning the device checks the local password database first.
TACACS+ separates authentication, authorisation, and accounting into three distinct packets, while RADIUS combines authentication and authorisation.
The 'operator' login class allows running troubleshooting commands like ping and traceroute, not just read-only viewing.
Setting 'authentication-order radius' without a fallback means if the RADIUS server is unreachable, login is completely denied.
The 'encrypted-password' option requires you to provide a pre-hashed string, not a plain-text password.
These come up on the exam all the time. Here's how to tell them apart.
Local User Account
Stored on the Juniper device itself in the configuration file.
Must be manually managed on every device individually.
Best for small networks with few devices.
Remote Authentication (RADIUS/TACACS+)
Stored on a central server separate from the Juniper device.
Managed from one central point; changes apply to all devices using that server.
Best for large networks with many devices.
RADIUS
Combines authentication and authorisation into one packet.
Uses UDP as the transport protocol.
Encrypts only the password in the packet, not the entire payload.
TACACS+
Separates authentication, authorisation, and accounting into three different packets.
Uses TCP as the transport protocol.
Encrypts the entire packet payload.
super-user Login Class
Full read and write access to all configuration and commands.
Can change the configuration, reboot the device, and manage user accounts.
Equivalent to a system administrator.
operator Login Class
Can view configuration and run troubleshooting commands like ping and traceroute.
Cannot change the configuration at all.
Equivalent to a help-desk technician who only monitors.
Authentication (Who are you?)
Verifies the identity of the user through credentials (password, SSH key).
Occurs first in the login process.
If authentication fails, the user is denied entry entirely.
Authorisation (What can you do?)
Determines which commands and actions the user is allowed to perform.
Occurs after authentication is successful.
If authorisation denies an action, the user is prompted with 'permission denied'.
Mistake
The root account is just like any other user account, so I can delete it if I want.
Correct
The root account is special and cannot be deleted. You can only change its authentication method. If you try to delete it, the device will reject the command.
Newcomers assume all accounts are equal because the command syntax looks similar. They do not realise root is built into the system as the ultimate fallback account.
Mistake
If I assign a user to the 'operator' class, they can only view the configuration and cannot run any commands.
Correct
The 'operator' class can run troubleshooting commands like 'ping', 'traceroute', and 'show' commands. They can also clear certain interface statistics. They cannot change the configuration.
The name 'operator' sounds like a passive role, but it actually grants limited troubleshooting powers. People underestimate what it can do.
Mistake
RADIUS and TACACS+ are interchangeable, so I can use either one for the same purpose with the same results.
Correct
RADIUS combines authentication and authorisation into one packet, while TACACS+ separates them into three separate packets. This means TACACS+ allows more granular control over authorisation and accounting.
Both protocols serve a similar overarching purpose (centralised authentication), so beginners think they are identical. The exam specifically tests the differences.
Mistake
Setting 'authentication-order radius' means the device will try RADIUS first, and if it fails, it will fall back to local passwords.
Correct
If you set 'authentication-order radius' with no fallback, the device only uses RADIUS. If the RADIUS server is unreachable, the login attempt fails. You must explicitly list 'password' after 'radius' to enable fallback.
The word 'order' implies a sequence, but beginners think 'radius' alone implies 'try this, then try local'. The exam loves this trap.
Mistake
When I configure 'set system login user bob authentication encrypted-password', I can type Bob's plain-text password and the device will encrypt it for me.
Correct
The 'encrypted-password' option expects you to provide an already-hashed string. If you type a plain-text password there, the device will treat the plain text as if it were the hash, and login will fail. Use 'plain-text-password' if you want the device to prompt for and encrypt the password.
The wording 'encrypted-password' sounds like it should do the encryption for you. The actual behaviour is counterintuitive.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can create as many user accounts as you need, and each one can be assigned to the same or different login classes. The login class just defines the permissions; the username identifies the individual.
You can recover it by booting the device into single-user mode (recovery mode) via the console, which requires physical access to the device. Once in that mode, you can reset the root password without knowing the old one.
Yes. Instead of or in addition to a password, you can configure an SSH public key for a user using 'set system login user <name> authentication ssh-rsa <key>'. This allows passwordless login via SSH key pairs.
'set system login' is used to create and manage non-root user accounts and login classes. 'set system root-authentication' is specifically for setting the password or SSH key for the built-in root account.
Yes. Use 'set system login class <custom-name> permissions <permission-set>'. You can define a custom set of permissions, like allowing 'interface' control but not 'system' control, by listing the exact permission flags you want.
Yes. RADIUS authenticates the user and can pass authorisation information (like which login class to assign) via RADIUS attributes. If the RADIUS server does not send a login class, the user may be denied access or fall into a default class, depending on your configuration.
You've finished User Accounts and Authentication. Continue through the JNCIA-JUNOS study guide to build a complete picture of the exam.
Done with this chapter?