> For the complete documentation index, see [llms.txt](https://jncia-workbook.gitbook.io/workbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jncia-workbook.gitbook.io/workbook/junos-basics/20-aaa.md).

# 20) AAA

### Pre-Work

If you made any changes, you can quickly revert the lab using the **load\_config\_on\_nodes.py** script.

```
python3 load_config_on_nodes.py --lab_dir three-routers --config_filename basic.addressing.cfg
```

### Lab

Connect to R1, and configure a RADIUS server for authentication:

* RADIUS server IP `10.0.0.50`
* RADIUS secret `radiuspassword1`
* Timeout interval should be `2 seconds`, with `2 attempts` before declaring the server unreachable

When users attempt to authenticate, the RADIUS server should be tried first. If the RADIUS server rejects the attempt, the user session is not allowed. If the RADIUS server is unreachable, the local database should be attempted.

### Answer

<details>

<summary>Expand to reveal</summary>

```
set system radius-server 10.0.0.50 secret radiuspassword1
set system radius-server 10.0.0.50 retry 2
set system radius-server 10.0.0.50 timeout 2
set system authentication-order [ radius ]
```

</details>

### Explanation

<details>

<summary>Expand to reveal</summary>

AAA configuration on Junos is quite straightforward. One thing to be aware of is the behavior of including `password` in the `authentication-order`. On Junos, all specified methods are attempted until authentication is successful. Therefore:

* If `password` is included, the local user database is checked, even if RADIUS or TACACS reject the credentials.
  * `set system authentication-order [ radius tacplus password ]`
* If `password` is not included, the local user database is still checked if RADIUS or TACACS are not available. But if RADIUS or TACACS reject the credentials, then the local user database is not checked.
  * `set system authentication-order [ radius tacplus ]`

\
If we set logging to the messages file with level any/any, we can see that RADIUS is tried and fails upon login, falling back to the local user database:

```
set system syslog file messages any any
commit
exit
monitor start messages
```

```
Jul 14 19:49:50  R1 sshd[25201]: Added radius server 10.0.0.50 (10.0.0.50)
Jul 14 19:49:50  R1 sshd[25201]: sendmsg to 10.0.0.50(10.0.0.50).1812: h->try:0 serv->num_tries:0, serv->max_tries:2 tries_per_addr:2, nleft:2, cur_addr:0
Jul 14 19:49:50  R1 sshd[25201]: sendmsg to 10.0.0.50(10.0.0.50).1812 failed: No route to host
Jul 14 19:49:50  R1 sshd: PAM_RADIUS_SEND_REQ_FAIL: Sending radius request failed with error (Tried all servers unsucessfully).
Jul 14 19:49:50  R1 sshd: PAM_UNIX_AUTH_SERV_PROB: Detected authentication server problem.
Jul 14 19:49:50  R1 sshd: PAM_UNIX_TRY_LOC_PASSWD_AUTH: will attempt local password authentication.
Jul 14 19:49:50  R1 sshd: PAM_UNIX_LOC_PASSWD_AUTH: local password authentication of user 'admin', succeeded
Jul 14 19:49:50  R1 sshd: PAM_USER_LOCK_AUTH_STATUS: (pam_sm_authenticate): DEBUG: PAM_AUTH_STATUS: success 
Jul 14 19:49:50  R1 sshd: PAM_USER_LOCK_ACTUAL_USER: (pam_sm_authenticate): DEBUG: PAM_ACTUAL_USER: admin 
Jul 14 19:49:50  R1 sshd: PAM_USER_LOCK_USER: (pam_sm_authenticate): DEBUG: PAM_USER: admin 
Jul 14 19:49:50  R1 sshd: PAM_USER_LOCK_USER: (pam_sm_acct_mgmt): DEBUG: PAM_USER: admin 
Jul 14 19:49:50  R1 sshd: PAM_USER_LOCK_ACTUAL_USER: (pam_sm_acct_mgmt): DEBUG: PAM_ACTUAL_USER: admin 
Jul 14 19:49:50  R1 sshd[25201]: Accepted password for admin from 192.168.1.121 port 54512 ssh2
Jul 14 19:49:50  R1 devd[10902]: Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/4'
Jul 14 19:49:50  R1 devd[10902]: Pushing table
Jul 14 19:49:50  R1 devd[10902]: Processing notify event
Jul 14 19:49:50  R1 devd[10902]: Popping table
Jul 14 19:49:50  R1 mgd[25205]: UI_PERMS_DEBUG: ddl_local_perms: Local permbits: ffffffffffffffff
Jul 14 19:49:50  R1 mgd[25205]: UI_AUTH_EVENT: Authenticated user 'admin' assigned to class 'j-super-user'
Jul 14 19:49:50  R1 mgd[25205]: UI_LOGIN_EVENT: User 'admin' login, class 'j-super-user' [25205], ssh-connection '192.168.1.100 54512 10.0.0.15 22', client-mode 'cli'
Jul 14 19:49:50  R1 mgd[25205]: UI_PERMS_DEBUG: ddl_local_perms: Local permbits: ffffffffffffffff

```

\
Also be aware that authorizing TACACS/RADIUS-authenticated users works differently from IOS "privilege levels." On Junos, we have three options for authorizing remotely-authenticated users:

* Create a local user with the same username, and configure the class. You can omit the password, as authentication will happen via TACACS/RADIUS.
  * This is generally the least-preferred method, as you have to manage all users locally.
* Create a user called `remote` and configure the class. By default, if the remotely-authenticated user is not present in the local config, the local user named `remote` is used for permissions.
  * The disadvantage here is that you cannot give different groups of remote users different permission levels.
* Create a local user for a group of users, for example called `noc`, and configure the class. (Again, do not configure a password). With TACACS, pass the attribute `local-user-name` set to `noc`. With RADIUS, use `Juniper-Local-User-Name` set to `noc`.
  * There is no configuration locally on the router to differentiate a "group" user from a "single" user. You just configure the `noc` user locally as if it was a normal user.

</details>

### Further Reading

<https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/junos-os-authentication-order.html>

<https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/user-access-radius-authentication.html>

<https://codingpackets.com/blog/juniper-aaa>

<https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/junos-os-user-authentication-overview.html#id-configuring-local-user-template-accounts-for-user-authentication>
