Switching

Unfortunately I don't have an EX4550 to hand, so I just setup a quick test using freeradius, and an SRX, just to see what is needed for just read-only access.

I put my configuration into an apply group, and the configuration that I used is shown below.

scan-user@SRX-Node1> show configuration groups globalsystem {    authentication-order [ radius password ];    radius-server {        192.168.0.35 {            port 1812;            accounting-port 1813;            secret /* SECRET-DATA */; ## SECRET-DATA            timeout 3;            retry 3;            source-address 192.168.0.212;        }    }    login {        class networkscan {            permissions [ view view-configuration ];        }        user scan-user {            uid 2003;            class networkscan;        }    }}

That was the only setup that I required to provide read-only access to the configuration and show commands for the scan-user.

Only thing I noticed was that in your configuration, you had view-configurations which is incorrect as far as I know, and should be view-configuration.  I had no need to add allow-commands or allow-configuration.

cli authorization shows the following results.

scan-user@SRX-Node1> show cli authorizationCurrent user: 'scan-user   ' class 'networkscan'Permissions:    view        -- Can view current values and statistics    view-configuration-- Can view all configuration (not including secrets)Individual command authorization:    Allow regular expression: none    Deny regular expression: none    Allow configuration regular expression: none    Deny configuration regular expression: none

Let me know if I can assist any further.

asharp, thanks for the info.

I actually checked my configurations and noticed I had the correct config (view-configuration) but I mistyped it in this forum. Thanks for catching that.

I'm still troubleshooting the issue. This is what I did thus far:

Unfortunately I don't have an EX4550 to hand, so I just setup a quick test using freeradius, and an SRX, just to see what is needed for just read-only access.

I put my configuration into an apply group, and the configuration that I used is shown below.

scan-user@SRX-Node1> show configuration groups globalsystem {    authentication-order [ radius password ];    radius-server {        192.168.0.35 {            port 1812;            accounting-port 1813;            secret /* SECRET-DATA */; ## SECRET-DATA            timeout 3;            retry 3;            source-address 192.168.0.212;        }    }    login {        class networkscan {            permissions [ view view-configuration ];        }        user scan-user {            uid 2003;            class networkscan;        }    }}

That was the only setup that I required to provide read-only access to the configuration and show commands for the scan-user.

Only thing I noticed was that in your configuration, you had view-configurations which is incorrect as far as I know, and should be view-configuration.  I had no need to add allow-commands or allow-configuration.

cli authorization shows the following results.

scan-user@SRX-Node1> show cli authorizationCurrent user: 'scan-user   ' class 'networkscan'Permissions:    view        -- Can view current values and statistics    view-configuration-- Can view all configuration (not including secrets)Individual command authorization:    Allow regular expression: none    Deny regular expression: none    Allow configuration regular expression: none    Deny configuration regular expression: none

Let me know if I can assist any further.

Very strange, I'll be the first to admit that my experience with Radius is very very limited, to the point that either someone else has configured it, or it isn't being used!  So it was a fun experience just to spin-up a Docker container with Radius and configure it with an SRX cluster that is on my desk.

The issue you are getting, especially when an account that starts off with super-user access, is then configured on Radius not to have super-user access, but the account still has super-user access... appears to me that Radius is still working on old data, and when the switch is requesting AAA it's getting the old information back.  What happens if you restart Radius?  Does authentication work as expected or is there still super-user access?

Regards.

asharp, thanks for the info.

I actually checked my configurations and noticed I had the correct config (view-configuration) but I mistyped it in this forum. Thanks for catching that.

I'm still troubleshooting the issue. This is what I did thus far:

Unfortunately I don't have an EX4550 to hand, so I just setup a quick test using freeradius, and an SRX, just to see what is needed for just read-only access.

I put my configuration into an apply group, and the configuration that I used is shown below.

scan-user@SRX-Node1> show configuration groups globalsystem {    authentication-order [ radius password ];    radius-server {        192.168.0.35 {            port 1812;            accounting-port 1813;            secret /* SECRET-DATA */; ## SECRET-DATA            timeout 3;            retry 3;            source-address 192.168.0.212;        }    }    login {        class networkscan {            permissions [ view view-configuration ];        }        user scan-user {            uid 2003;            class networkscan;        }    }}

That was the only setup that I required to provide read-only access to the configuration and show commands for the scan-user.

Only thing I noticed was that in your configuration, you had view-configurations which is incorrect as far as I know, and should be view-configuration.  I had no need to add allow-commands or allow-configuration.

cli authorization shows the following results.

scan-user@SRX-Node1> show cli authorizationCurrent user: 'scan-user   ' class 'networkscan'Permissions:    view        -- Can view current values and statistics    view-configuration-- Can view all configuration (not including secrets)Individual command authorization:    Allow regular expression: none    Deny regular expression: none    Allow configuration regular expression: none    Deny configuration regular expression: none

Let me know if I can assist any further.

Very strange, I'll be the first to admit that my experience with Radius is very very limited, to the point that either someone else has configured it, or it isn't being used!  So it was a fun experience just to spin-up a Docker container with Radius and configure it with an SRX cluster that is on my desk.

The issue you are getting, especially when an account that starts off with super-user access, is then configured on Radius not to have super-user access, but the account still has super-user access... appears to me that Radius is still working on old data, and when the switch is requesting AAA it's getting the old information back.  What happens if you restart Radius?  Does authentication work as expected or is there still super-user access?

Regards.

asharp, thanks for the info.

I actually checked my configurations and noticed I had the correct config (view-configuration) but I mistyped it in this forum. Thanks for catching that.

I'm still troubleshooting the issue. This is what I did thus far:

Unfortunately I don't have an EX4550 to hand, so I just setup a quick test using freeradius, and an SRX, just to see what is needed for just read-only access.

I put my configuration into an apply group, and the configuration that I used is shown below.

scan-user@SRX-Node1> show configuration groups globalsystem {    authentication-order [ radius password ];    radius-server {        192.168.0.35 {            port 1812;            accounting-port 1813;            secret /* SECRET-DATA */; ## SECRET-DATA            timeout 3;            retry 3;            source-address 192.168.0.212;        }    }    login {        class networkscan {            permissions [ view view-configuration ];        }        user scan-user {            uid 2003;            class networkscan;        }    }}

That was the only setup that I required to provide read-only access to the configuration and show commands for the scan-user.

Only thing I noticed was that in your configuration, you had view-configurations which is incorrect as far as I know, and should be view-configuration.  I had no need to add allow-commands or allow-configuration.

cli authorization shows the following results.

scan-user@SRX-Node1> show cli authorizationCurrent user: 'scan-user   ' class 'networkscan'Permissions:    view        -- Can view current values and statistics    view-configuration-- Can view all configuration (not including secrets)Individual command authorization:    Allow regular expression: none    Deny regular expression: none    Allow configuration regular expression: none    Deny configuration regular expression: none

Let me know if I can assist any further.

Andy,

Unfortunately, the radius server is on production so it can't be restarted without affecting other systems.

Very strange, I'll be the first to admit that my experience with Radius is very very limited, to the point that either someone else has configured it, or it isn't being used!  So it was a fun experience just to spin-up a Docker container with Radius and configure it with an SRX cluster that is on my desk.

The issue you are getting, especially when an account that starts off with super-user access, is then configured on Radius not to have super-user access, but the account still has super-user access... appears to me that Radius is still working on old data, and when the switch is requesting AAA it's getting the old information back.  What happens if you restart Radius?  Does authentication work as expected or is there still super-user access?

Regards.

asharp, thanks for the info.

I actually checked my configurations and noticed I had the correct config (view-configuration) but I mistyped it in this forum. Thanks for catching that.

I'm still troubleshooting the issue. This is what I did thus far:

Unfortunately I don't have an EX4550 to hand, so I just setup a quick test using freeradius, and an SRX, just to see what is needed for just read-only access.

I put my configuration into an apply group, and the configuration that I used is shown below.

scan-user@SRX-Node1> show configuration groups globalsystem {    authentication-order [ radius password ];    radius-server {        192.168.0.35 {            port 1812;            accounting-port 1813;            secret /* SECRET-DATA */; ## SECRET-DATA            timeout 3;            retry 3;            source-address 192.168.0.212;        }    }    login {        class networkscan {            permissions [ view view-configuration ];        }        user scan-user {            uid 2003;            class networkscan;        }    }}

That was the only setup that I required to provide read-only access to the configuration and show commands for the scan-user.

Only thing I noticed was that in your configuration, you had view-configurations which is incorrect as far as I know, and should be view-configuration.  I had no need to add allow-commands or allow-configuration.

cli authorization shows the following results.

scan-user@SRX-Node1> show cli authorizationCurrent user: 'scan-user   ' class 'networkscan'Permissions:    view        -- Can view current values and statistics    view-configuration-- Can view all configuration (not including secrets)Individual command authorization:    Allow regular expression: none    Deny regular expression: none    Allow configuration regular expression: none    Deny configuration regular expression: none

Let me know if I can assist any further.

Understood.   Are you able to run radtest to see what the response is from Radius.  It would be interesting to see what is being sent.

e.g.  This is just my labsetup here, and I have used vendor specific attributes to include Juniper-Deny-Commands, rather than configure them directly on the Junos device.  I'm just interested to see what type of response you get before and after you have made changes to Radius.

radtest -x scan-user mypassword 192.168.0.35 0 mysecretpasswdSent Access-Request Id 44 from 0.0.0.0:fe91 to 192.168.0.35:1812 length 79	User-Name = "scan-user"	User-Password = "mypassword"	NAS-IP-Address = 192.168.0.35	NAS-Port = 0	Message-Authenticator = 0x00	Cleartext-Password = "mypassword"Received Access-Accept Id 44 from 192.168.0.35:714 to 192.168.0.35:65169 length 51	Juniper-Deny-Commands = "configure|start|request"

Andy,

Unfortunately, the radius server is on production so it can't be restarted without affecting other systems.

Very strange, I'll be the first to admit that my experience with Radius is very very limited, to the point that either someone else has configured it, or it isn't being used!  So it was a fun experience just to spin-up a Docker container with Radius and configure it with an SRX cluster that is on my desk.

The issue you are getting, especially when an account that starts off with super-user access, is then configured on Radius not to have super-user access, but the account still has super-user access... appears to me that Radius is still working on old data, and when the switch is requesting AAA it's getting the old information back.  What happens if you restart Radius?  Does authentication work as expected or is there still super-user access?

Regards.

asharp, thanks for the info.

I actually checked my configurations and noticed I had the correct config (view-configuration) but I mistyped it in this forum. Thanks for catching that.

I'm still troubleshooting the issue. This is what I did thus far:

Unfortunately I don't have an EX4550 to hand, so I just setup a quick test using freeradius, and an SRX, just to see what is needed for just read-only access.

I put my configuration into an apply group, and the configuration that I used is shown below.

scan-user@SRX-Node1> show configuration groups globalsystem {    authentication-order [ radius password ];    radius-server {        192.168.0.35 {            port 1812;            accounting-port 1813;            secret /* SECRET-DATA */; ## SECRET-DATA            timeout 3;            retry 3;            source-address 192.168.0.212;        }    }    login {        class networkscan {            permissions [ view view-configuration ];        }        user scan-user {            uid 2003;            class networkscan;        }    }}

That was the only setup that I required to provide read-only access to the configuration and show commands for the scan-user.

Only thing I noticed was that in your configuration, you had view-configurations which is incorrect as far as I know, and should be view-configuration.  I had no need to add allow-commands or allow-configuration.

cli authorization shows the following results.

scan-user@SRX-Node1> show cli authorizationCurrent user: 'scan-user   ' class 'networkscan'Permissions:    view        -- Can view current values and statistics    view-configuration-- Can view all configuration (not including secrets)Individual command authorization:    Allow regular expression: none    Deny regular expression: none    Allow configuration regular expression: none    Deny configuration regular expression: none

Let me know if I can assist any further.

Andy,

I don't believe I can do 'radtest' on Windows NPS; that is what my radius is on currently. I'll look into it though.

Understood.   Are you able to run radtest to see what the response is from Radius.  It would be interesting to see what is being sent.

e.g.  This is just my labsetup here, and I have used vendor specific attributes to include Juniper-Deny-Commands, rather than configure them directly on the Junos device.  I'm just interested to see what type of response you get before and after you have made changes to Radius.

radtest -x scan-user mypassword 192.168.0.35 0 mysecretpasswdSent Access-Request Id 44 from 0.0.0.0:fe91 to 192.168.0.35:1812 length 79	User-Name = "scan-user"	User-Password = "mypassword"	NAS-IP-Address = 192.168.0.35	NAS-Port = 0	Message-Authenticator = 0x00	Cleartext-Password = "mypassword"Received Access-Accept Id 44 from 192.168.0.35:714 to 192.168.0.35:65169 length 51	Juniper-Deny-Commands = "configure|start|request"

Andy,

Unfortunately, the radius server is on production so it can't be restarted without affecting other systems.

Very strange, I'll be the first to admit that my experience with Radius is very very limited, to the point that either someone else has configured it, or it isn't being used!  So it was a fun experience just to spin-up a Docker container with Radius and configure it with an SRX cluster that is on my desk.

The issue you are getting, especially when an account that starts off with super-user access, is then configured on Radius not to have super-user access, but the account still has super-user access... appears to me that Radius is still working on old data, and when the switch is requesting AAA it's getting the old information back.  What happens if you restart Radius?  Does authentication work as expected or is there still super-user access?

Regards.

asharp, thanks for the info.

I actually checked my configurations and noticed I had the correct config (view-configuration) but I mistyped it in this forum. Thanks for catching that.

I'm still troubleshooting the issue. This is what I did thus far:

Unfortunately I don't have an EX4550 to hand, so I just setup a quick test using freeradius, and an SRX, just to see what is needed for just read-only access.

I put my configuration into an apply group, and the configuration that I used is shown below.

scan-user@SRX-Node1> show configuration groups globalsystem {    authentication-order [ radius password ];    radius-server {        192.168.0.35 {            port 1812;            accounting-port 1813;            secret /* SECRET-DATA */; ## SECRET-DATA            timeout 3;            retry 3;            source-address 192.168.0.212;        }    }    login {        class networkscan {            permissions [ view view-configuration ];        }        user scan-user {            uid 2003;            class networkscan;        }    }}

That was the only setup that I required to provide read-only access to the configuration and show commands for the scan-user.

Only thing I noticed was that in your configuration, you had view-configurations which is incorrect as far as I know, and should be view-configuration.  I had no need to add allow-commands or allow-configuration.

cli authorization shows the following results.

scan-user@SRX-Node1> show cli authorizationCurrent user: 'scan-user   ' class 'networkscan'Permissions:    view        -- Can view current values and statistics    view-configuration-- Can view all configuration (not including secrets)Individual command authorization:    Allow regular expression: none    Deny regular expression: none    Allow configuration regular expression: none    Deny configuration regular expression: none

Let me know if I can assist any further.