Tuesday, 16 October 2012

Users & User Accounts in Junos

The following post will give an overview on user accounts within the SRX platform. When studying for this topic I wanted a clear understanding of the the framework so I could understand what options I had at my disposal to manage users and their access to a Junos device. User accounts are listed as a topic on the JNCIE-SEC exam blueprint. I hope having this framework knowledge will allow me to draft up a configuration for specific user requirements that might exist in a lab exam.

Root User
The root user account is pre-configured by default with no password. When proceeding through initial installation/configuration the system will instruct you to configure a password for this account. Authentication can be password or DSA/RSA key. As with other operating systems root accounts have complete access to this system.

Local Configurable User Accounts
Locally configured user accounts have the following parameters. Note: Items in bold are more relevant in typical configuration (in my opinion).
  • username: The username is how the account is referenced in the configuration. It must be unique on the device.
  • full name: This is optional, but can be the users full name / description.
  • UID: this is a unique numerical identifier for the username and can be a number between 100-64000. If no number is configured the system will auto generate one.
  • class: A user needs to belong in a class. The class defines the access this account will have to the system (it's discussed later in the next section).
  • authentication method: this outlines the method to authenticate this user (could be encrypted password string, DSA ssh key, RSA ssh key, plain-text-password) Note: the plain-test-password is auto-encrypted when entered)

Login Classes
A login class defines what the user has access to do once logged in. The parameters below can be used to create the desired access for a particular user. Note: Items in bold are more relevant in typical configuration (in my opinion).
  • access-start: This option sets the time of day access is allowed.
  • access-end: This option sets the time of day access ends.
  • allowed-days: This option sets days of the week access is allowed.
  • security role: This option defines a standards based security identifier to the class.
  • idle-timeout: This option sets the amount of time until the user is logged out if there is no activity.
  • login-alarms: This option will trigger an alarm upon login.
  • login-script: This option will run a specified script upon login.
  • login-tip: This option will present a CLI tip in the consol upon login
  • permissions: This statement allows 'read only' or 'read/write' permissions to be configured based on predefined permission bits or permission flags. Each top level CLI command has an associated 'read only' and 'read/write' permission bit. Their are also permission bits that cover general statements such as 'all' which includes all permissions, or 'view' which allow various commands system wide to view statistics  Here is a list of the available permissions --> Junos Access Privilege Levels Overview - Junos 11.1.
  • allowed-commands: Specific operation mode commands can be configured under this statement. Regex operators can be used to add multiple commands or match on specific conditions. Operational mode commands matching this statement will be permitted. Commands specified here take precedence over permission bits set on the same login class.
  • deny-commands: This statement functions the same as the one above (allowed-commands) except as the name implies commands matching this statement will be denied
  • allow-configuration: This statement functions the same as the 'allowed-commands' statement except configuration mode commands can be configured here. 
  • deny-configuration: This state functions the same as the 'deny-commands' statement except configuration mode commands can be configured here. 

Looking into the default Login Classes
Note: use the 'Junos Access Privilege Levels Overview' link above to get a description of the access associated with the permission bits when reviewing the default login classes below.
Operator: This login class contains clear, network, reset, trace and view permission bits.
Read Only: This login class contains the view permission bit.
Super-user: This login class contains the all permission bit.
Unauthorized: This login class contains no permission bits and therefore has no access.

RADIUS
RADIUS (Remote Authentication Dial In User Service) is a protocol that provides AAA (Authentication, Authorization and Accounting). Junos can use this protocol to allow for external systems to provide the user authentication. Radius can also be used to provide authorization with the use of attributes. Attributes can be very powerful. For example radius attributes can be used to apply permissions and allowed/deny commands to specific users and pass this information to the Junos device. This allows for centralized user management and can reduce individual user configurations on Junos devices.

TACACS+
TACACS+ (Terminal Access Controller Access-Control System Plus) is also a protocol that provides AAA. Like RADIUS this protocol can also be used to provide user authentication and authorization.

Authentication Order
Authentication order can be configured so that multiple methods of authentication can be simultaneously used. By default 'password' is used and this simply references user accounts configured on the system. A list can be configured using 'password' (local authentication), 'radius' and 'tacplus' (TACACS+) as authentication options. The order they are listed in the configuration is the order they will be processed. For example if the order was configured as [password radius ] a user would first be authenticated using local user accounts if this was unsuccessful a second attempt would be made to any available radius servers.
Additional Information: Ivan Ivanov made a good observation in his comments below the post. If only authentication servers are present in the authentication order and they become unreachable the SRX will attempt to authenticate the user name against locally configured users.

Configuration Examples
My next posts will focus on going through specific authentication examples along with configuration. Stay tuned.

Comments
Please feel free to comment, correct and ask questions on these blog posts using the comment window below the post. I am working through this content in preparation for the JNCIE-SEC exam and questions and comments will help myself along with anyone reading this material.

3 comments:

  1. Hi,

    One thing to add in regard to the authentication order.

    If you omit the 'password' it will still check the local users if the authentication servers are not reachable. But the difference is that it will check with the already entered user and password. It will not ask again for them. You can check it.

    You are doing great job with that blog!

    HTH,
    Ivan,

    ReplyDelete
  2. Hi Ivan, I did test the scenario you described by only having RADIUS in the authentication order and then powering down the RADIUS server. As you said it does check the local users as I was able to log in. I am thinking this would be useful if you wanted users to always use authentication servers and still have the ability to manage the device if the servers were unreachable.
    Thanks for the tip!
    Stefan

    ReplyDelete
  3. Hi Stefan,

    One small correction. It turned out that is opposite way. When you omit the password in the authentication list and the authentication server is not reachable the router asks you again for credentials and checks the local user data base. But when you have 'password' in the list as last and the authentication server is not reachable the router is checking automatically in local data base for the entered credentials.

    Thanks!
    Ivan,

    ReplyDelete