HP 3600 (JG306a) RADIUS

[xayrex]

Hi, 

Need help in setting up ssh and Web access through the RADIUS server.
The server role acts windows 2012r2 (NPS), there are no problems in dealing with another series of switches (e3800).
On HP 3600 Switch (gj306a) authentication is performed, but only with privilege level 0.

user-interface vty 5 15
authentication-mode scheme
user privilege level 3

did not help.

Through ssh can not execute the command "super"

What am I missing?

[xayrex]

Without RADIUS, local root does not have permission to access via SSH
Through the Web Access full

[Ian Vaughan]

Howdy,

If you do a search through the forums on this site with the search terms  "RADIUS" and "admin" you will find quite a few good posts. 

As you probably know by now there is a world of difference between 3800 series switches and 3600 models.

This post is one from a couple of weeks ago discussing the very same privilege levels derived from VSA (vendor specific attributes) that you add to the RADIUS server for different flavours of Comware switches.

Hope that gives you some ideas. Let us know how you get on and if you get to the bottom of your immediate issue.

Please use the Kudos button if you are reading this and find it useful / informative / amusing :-)

Thanks

Ian

[xayrex]

Thanks for the tip, it shifted me away, but the result still does not.

Of course I used a search before creating threads.

Now the big question is what attributes to send this series of switches that would go through to identify oneself and control the level of privileges?
What vendor attributes I look for?

I tried:

Both methods of this topic.  One of my switches configured in the same way through the web interface is identical. (For reference, the second set similarly via CLI)

And this fot telnet(especially for the included telnet on one of the switches) 

and a certain number of attempts to mixed based on intuition

[xayrex]

Also I tried it

[Ian Vaughan]

OK,

Given that the web, telnet and ssh services for admin users should all use the same "login" access the "user experience" should be just the same i.e. if you get manager access on web for a given login you should get the same access under ssh as well with the same credentials.

Time for the nuclear option -

Wireshark in one window

and

NPS event log in the other

on the Windows NPS server.

# Login using your test credentials for the RADIUS authenticated web access.

# Login using same credentials for RADIUS authenticated ssh access.

What, if anything, is different?

## I've just enabled the web management on a Comware 5 switch and created a "monitor" priv level 1 user and that user is able to effectively act as a manager in the Web GUI. The priv levels are rigourously enforced at the CLI level but they don't apply to the web management service.  In that light only Priv level 3 users should ever be given Web access as part of their service profile. "Normal" users should only be granted SSH service access so that they are bound by the privelege model and aren't allowed to escalate their own access to management & configuration functions.

##I think that your uplift for Priv 3 access via the RADIUS VSA etc is still not quite right but comparing the Web GUI with SSH is not a fair test if that service doesn't use the privelege levels.

So,

Did you set up a nice shiny new "domain" for your RADIUS access configuration or did you just reconfigure the "system" default domain?

If you have redirected the system domain away from the local RADIUS db to a remote one the local user login isn't going to give you privileged access. I'm surprised it gives you any access unless you co-incidentally have the same username/password combo in the remote RADIUS server as well.

Setting the "local" service as a secondary AUTH source is a good idea but it will only work when the primary (remote RADIUS) is unavailable.

I found that it works quite well if you set up a new "domain" config on the switch with your genuine domain name and build it up such that any user logging in with his or her user@domainname.local credentials is effectively intercepted and authenticated by the remote radius server bound to that particular "domain" 

Any user logging in as just plain old "user-name" doesn't match the domainname.local and therefore falls through to be serviced by the "system" default still pointing at the local password database behind the local RADIUS server. Thats the only way I've had it working for "login" so that I could use both local and remote AUTH servers concurrently. You can use "mandatory domain" on ports if you want to force auth by a particular AUTH scheme but I've only used that for "lan-access" not "login".

Hope that gives you some ideas.

Many thanks

Ian

[xayrex]

I will try to give you more information.
On commutators only one local user with privilege level 3. Before all opened Web access only. At one I opened ssh and telnet (for the test) using the console access. I checked using a local account, stopping the NPC.
On the switches set a new ISP Domain, which corresponds to the domain of the company.
One of commutators configured via WEB similarly to the first post of the topic. The second through the console CLI.
On the NPS server, from the very beginning has been installed Wireshark, see the handshake in which the switch transmits the server that this is a user attempts to perform entrance, the server returns a response which gives full access and see the couple to raise the level of privileges, different depending on how I set up a policy for the a server for various attempts.
The main questionnaire for me which pairs expect these switches?
The logs on the server, all events are displayed correctly 6278 and 6272.

If need I can provide snapshots of what you want.

Thank you very much for your help.

[xayrex]

I did it!

My mistake was that the switch has been configured the Service Type - Standard
It was originally set Service Type - Advanced, but could not even get on a switch, the installation of the Service Type - Standard helped, now I understand that it was the wrong decision.

Continue to raise the privilege level were used vendor specific s of this guide.

Vendor ID 2011, attribute ID 29 will let you specify the user level to apply, using the following values:

0 H3C-Visitor
1 H3C-Monitor
2 H3C-Manager
3 H3C-Administrator

Now it works correctly domain authentication on switches web interface. The rest is not touched, because it posed such a problem.

The next step is https instead nttp.

Thanks for help, it was a very useful and important for me.