This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
I can get it to authenticate. But I've read some posts on ACS 4.2 and authorization, but I don't find anything similar.
I want to control down to what commands the authenticated user can run. I want the defintion to come from
the ACS server, or at least control it from the ACS server. I want to minimize the changes on the JunOS side,
but if it can't be easily done, I'll change the JunOS side.
Well, I got something to work. I let TACACS do the authentication, I changed the remote user to
be readonly/tier1. Then I have to create an account for each admin that is tier3/readwrite.
Not pretty, but it works.
There must be a more elegant solution?
Please see my post at the following thread:
I have detailed information on JUNOS TACACS mappings from the ACS 5.x configuration side to the JUNOS user class mappings.
I'm not an expert in Juniper AAA so if would please indulge me. I'm thinking three groups FullAccess, RO, and LimitedAccess. There will be many many users in each group. Does this mean that not only do I have to create these three classes but I also have to create ALL the user accounts on each JunOS device as well? I'd like to be able to use the ACS user identity database instead (so that I one central repository for accounts info).
I gave up. The example screenshots were of 4.2 and I tried to get that to work with no luck.
It would be nice to give people the correct tier from TACACS, but i have a workaround.
I have ACS 5.2 and JUNOS 10.6.x I setup 2 classes eng-class and ops-class with read/write and read-only permission
here is my configuration on JUNOS
set system login class eng-class idle-timeout 15
set system login class eng-class permissions all
set system login user engineer full-name “Regional Engineering”
set system login user engineer uid 2001
set system login user engineer class eng-class
set system login user engineer authentication plain-text-password xxxxxxx
set system login class ops-class idle-timeout 15
set system login class ops-class permissions view view-configuration
set system login user operator full-name “Regional Operations”
set system login user operator uid 2002
set system login user operator class ops-class
set system login user operator authentication plain-text-password xxxxxxx
set system authentication-order tacplus password
set system tacplus-options no-cmd-attribute-value
set system tacplus-options service-name junos-fwr-exec -------------------> is this command still needed in ACS 5.2?
set system tacplus-server xxxx.xxx.xxx.xxx secret xxxxxxxx
set system tacplus-server xxx.xxx.xxx.xxx timeout 5
set system tacplus-server xxx.xxx.xxx.xxx source-address xxx.xxx.xxx. - can i use fxpo out-of-band mgmt IP?
set system accounting events login
set system accounting events change-log
set system accounting events interactive-commands
set system accounting destination tacplus server xxx.xxx.xxx.xxx secret xxxxxxx
set system accounting destination tacplus server xxxx.xxx.xxx.xxx timeout 5
I saw some implementation they only using one template i.e "remote' user template with permission all, then the authorization was inherited from ACS whether to have a read-only or read write access. is this a better implementation? Can you show how to do it in JUNOS and ACS 5.2?
I do not have a template for you to use, I was providing assistance on the ACS side. Based on your last questions, the approach looks like a good approach.
*Please rate helpful posts*
You don't need to do one or other. The remote clause is the default if no tier is assigned.
In our case, we specify the readonly cases explicitly, since it changes less frequently, and allow our admins readwrite
by default via remote. That way, we don't have to add admins on each router when they come on board. Of course
we still authenticate via TACACS in either case, we don't have local passwords except for our emergency ones.
Yeah, I really tried that 4.2 link and translate it to 5.2 to get it to map users to tiers, but I had a limited time
window to work on it. The solution to specify the readonly accounts explictily and readwrite implicitly suited
Thanks Eugene, Tarik,
I have implemented this, but below are the results.
1. i can manage to login that belong to engineer account read-write.
2. i cant login using accounts thet belong to operator read-only.
3. Also for Juniper Web management interface, tacacs is not working.
do you have any idea?