Home > RADIUS, ScreenOS > 2008R2 RADIUS Authentication for Juniper ScreenOS

2008R2 RADIUS Authentication for Juniper ScreenOS

If one is looking for a good reference for 2008 R2 and RADIUS authentication in general, I recommend this site (http://aaronwalrath.wordpress.com/2010/06/22/install-windows-2008-r2-nps-for-radius-authentication-for-cisco-router-logins/).  It captures every step for a Cisco device, but fundamentals are very close. A friend of mine had gone through this and captured notes to get me through the Juniper specific items and get it to the point where I could document it up.  (Thanks Robbie!).   I also did a little more digging into options that could be  used to give the RADIUS user “root” level privileges and use groups to give both “root” or “read/write” to still have the segmentation.

So we’ll assume that the NPS is configured as in the link above. We’re just creating a new policy.

1) Login to the NPS Role server


3) Give a POLICY NAME.  I chose to give mine RADIUS – ScreenOS.


Click NEXT

On the CONDITIONS screen, click ADD


Select WINDOWS GROUP and click ADD.


The next screen will ask you for the GROUP.  Click ADD GROUP.  In the entry box, enter the name of the group you want to have access to this device group/type.  As I’m making this policy for Juniper ScreenOS devices, I’ve made a group in AD of “RADIUS – ScreenOS”.  Click CHECK NAMES and click OK after.  Then click OK two more times.


Now we have a a CONDITION list  Click NEXT to select


This policy is going to GRANT access.  Select ACCESS GRANTED and click NEXT.


For the ScreenOS devices, I was told to remove the MS-CHAP-v2 and MS-CHAP options, and check “Unencrypted authenticated (PAP, SPAP)”.  Click NEXT.

We DID say unencrypted…. expect a warning:



We’re not going to modify any of the CONTRAINTS.  Click NEXT.




Scroll to the bottom and select VENDOR-SPECIFIC.  Click ADD.



Leave the selection on ENTER VENDOR CODE and enter 3224 (for Juniper).  Select YES, IT CONFORMS.  Click CONFIGURE SECURITY.


Enter 1 for the VENDOR-ASSIGNED ATTRBUTE NUMBER.  Change the Attribute Format to DECIMAL.  Enter the ATTRIBUTE VALUE of 1.  Juniper KB Article KB5688 (http://kb.juniper.net/InfoCenter/index?page=content&id=KB5688) shows the values.  1 is equal to ROOT, 2 for Read-Write, 4 for Read-Only, etc.  Click OK 3 times.

Back at the Add Vendor Specific Attribute, click CLOSE.


In the NEW NETWORK POLICY screen, you now see the attribute you added listed.


Click NEXT.



Back at Server Manager, right click on RADIUS CLIENT and click NEW.


4) In the NEW RADIUS CLIENT screen, fill in the FRIENDLY NAME (ie: hostname maybe – NW-SSG5A), ADDRESS (IP or DNS)  (ie:


At the bottom, enter a SHARED SECRET twice.   You’ll need this on the ScreenOS side later.  Click OK

5) Login to the ScreenOS device, with an existing LOCAL security defined ROOT level user (usually “netscreen”)

Click and expand CONFIGURATION –> AUTH –> AUTH SERVERS.  Click NEW in the top right corner:


Enter the following:

NAME = Some logical name that makes you happy to define these RADIUS settings – ie: NW_RADIUS
IP/DOMAIN NAME = The primary RADIUS server – ie:
BACKUP1 = The secondary RADIUS server – ie:
RADIUS –> SHARED SECRET = This is the same secret you entered in step 4 above.


Click OK to save.


Change the following:

ADMIN PRIVELEDGES = Get Admin From Local Auth Server
ADMIN AUTH SERVER = Local/NW_RADIUS (note the friendly name from the previous step)
ROOT = Accept Remotely Authenticated ROOT Privilege Admins



If you prefer to do your configuration from the command line, then what you want is:

set auth-server “NW_RADIUS” id 1
set auth-server “NW_RADIUS” server-name “”
set auth-server “NW_RADIUS” backup1 “”
set auth-server “NW_RADIUS” account-type admin
set auth-server “NW_RADIUS” radius secret “aL6xn12DN4uSoFs9KpCfyvvvUnnQJsn9uQ==”
set admin auth server “NW_RADIUS”
set admin auth remote root
set admin privilege get-external

For my environment I’m going to use use 1 for ROOT, as it’s a lab.  In a business environment, I might make 3 groups for each type.  Root for primary administrators, maybe tied to the Domain Admin account.  It shouldn’t be needed for anything as RADIUS will let us just drop a user into a group if we need to have root for some reason.  Read-Write is what most administrators would need, unless they’re changing settings.  But you might want a read-only config that can be used by scripting tools that might backup the config file or report on changes, etc.  (ie: CatTools)

And that’s it. You can now login using your domain credentials (assuming you’re a member of the chosen “RADIUS – ScreenOS” AD group).

Some things I have yet to confirm, as my lab isn’t large enough to confirm:

  • Does the secondary RADIUS server work as expected with failover?  Preliminary tests by disabling the NIC on the primary NPS says no, it does not.
  • Is there any issues with a second or more devices, based on the configuration in the NPS that specified NW-SSG5A?  Can you add an array of names there or will that cause all conditions to test as false and fail for everything?  Maybe you need one configuration per device – which could be cumbersome.

But at this point, you now have local authentication for your root “netscreen” user as a backup (keep that password in a safe, etc) and AD based RADIUS authentication for other users.

Categories: RADIUS, ScreenOS
  1. James
    March 26, 2013 at 10:05 AM

    I followed this article, but I am not able to connect using AD credentials. Any idea what could be wrong? I am able to ping the radius server from the firewall and ping the firewall from the radius server. I can only connect if I create a user account on the firewall, which defeats the purpose of using Radius.

    • March 26, 2013 at 10:19 AM

      James: I see you’re also the guy who linked to me from the Juniper forums (http://forums.juniper.net/t5/ScreenOS-Firewalls-NOT-SRX/Windows-2008-NPS-SSG5-accessing-shared-folder-still-prompts-for/td-p/51015), thanks. It seems that you’re trying to do a VPN connection as a user, and have the user authenticate their VPN. My steps are for RADIUS authentication of _administration_. All of my VPN experience with ScreenOS has been site to site IPSEC, using PSK or certificates, and no user termination. We always used RDP/Terminal Services farms for users connecting remotely, or a PPTP (ugh) VPN to an internal Windows server host. As such, I’m afraid I’m not a lot of help, if I’m correctly understanding that you want to use it for VPN authentication. That said, let’s see if we can’t get it working.

      First – is authentication for management working? Let’s confirm that the setup is able to do what we know it should do. If that doesn’t work, then getting VPN authentication to work as well, would be expected to fail. Can you login via SSH or HTTPS to the Juniper ScreenOS device with your AD credentials?

      Next, I’ve been doing a bit more Cisco work lately, and I do know there one expects to find a number of authentications – access, enable, VTY, etc. Equally, the RADIUS setup that is done on the NPS server specifies what the RADIUS is allowed to authenticate for.

      For example, from my post:
      # Configure SSH logins to use the RADIUSLIST specified above
      line ssh
      login authentication RADIUSLIST

      # Configure HTTP/HTTPS logins to use RADIUS first, then local
      ip http authentication radius local
      ip https authentication radius local

      We have explicitly told SSH/HTTP/HTTPS authentication to use RADIUS. We don’t tell VPN modules that they can use RADIUS on the SSG, and equally, we do not tell the NPS that the RADIUS attributes it can provide are for VPN, but for Management.


      I found this link in a quick search, and after looking at it I find a few things that might help you:

      1) There is a VSA that needs to be set to “3224” and set up as an attribute of 3/String/Juniper.VPN.Users
      2) it shows (graphically only, unfortunately, no CLI) the settings required for the Auth Server for VPN authentication on the ScreenOS device.

      Be very careful following my post for VPN users – you may have just given all of your VPN users admin access to the firewall instead! My post was only ever intended for administration, for the purposes of “what if an Administrator is fired – or hired< and how can we easily update this on 30 firewalls……"

  2. Marino
    November 26, 2013 at 12:57 PM

    Excellent article, worked like a charm.

    • November 26, 2013 at 1:00 PM

      Glad I could help. Just be sure you don’t try this exact method to allow VPN users to connect – you’d be giving those users admin rights. I saw a post somewhere linking to mine hoping for that to work! It would need a different vendor code to be for VPN auth…

  3. Todd
    May 13, 2014 at 3:53 PM

    Great article, worked great!! But as soon as it was implemented my IA team informed me that we are required to use encryption. Is that possible?

    • May 13, 2014 at 10:22 PM

      I can’t say for sure, I didn’t have to take it any further – but I can certainly understand the need. A quick look found me some JunOS details at: http://dice.neko-san.net/2012/08/linking-junos-authentication-to-active-directory-using-radius/ that indicate it can use MS-CHAPv2, using these options:
      set system authentication-order [ password radius ]
      set system radius-server secret “0C&2eTVBv8SMXwq1eo5!3fyBhh!u2gcBjGLcz@jIC4LPj8slrBC9V^j&0hMXUHRe”
      set system radius-options password-protocol mschap-v2
      This suggests that certainly it is possible, but it would depend on the vendor implementation. I don’t have a running ScreenOS device at the moment to look into it, but I think I could find one.

  4. Sam
    July 22, 2014 at 11:43 AM

    Thank you for this article.

    I was looking to configure a Radius wifi authentication for our company users via PEAP -MS-Chap2 on SSG5-W, when I came across your post. I am having an authentication problem. When I try to connect, it get stuck at ‘validating identity’. I configured a Enterprise CA, installed a certificate on users laptop and I thought I configured everything correctly on Windows NPS policy side but connection still doesn’t work. Will it be possible to post an article about WIFI radius authentication for company users so they can use the resources wirelessly? Thank you.

  1. May 20, 2012 at 3:01 PM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: