Scannex ip.buffer User Manual
© UK 2007-2021 Scannex Electronics Ltd. All rights reserved worldwide.
FTP
When FTP is linked to RADIUS then any channel that is set to deliver by “FTP Server” will
be checked against RADIUS. When the user logs in the FTP server will contact the RADIUS
server to determine which channel that user should access. The Filter-Id value is searched
for the first “F” value – so there should only be one “F” value in the returned Filter-Id
string. Consequently, if “
F3
” is received for a given user, then that user will log into
channel 3.
Pass-through and TCP Server Delivery
When RADIUS is not used, both of these services only ask for a password. When the TCP/IP
socket connects the user is shown a “Password:” prompt. However, when linked to RADIUS
we need both a username and password from the client.
Hence, when either of these services is set to refer to RADIUS the end user should use the
form “
user
:
password
” when replying to the “
Password:
” prompt.
If you enter just a password, then the RADIUS client will assume a username of
“ipbuffer_
boxname
_
serviceid
”,
e.g. “ipbuffer_Scannex_P1” for pass-through 1.
e.g. “ipbuffer_Scannex_T3” for TCP Server channel 3.
Other considerations
Unless the RADIUS server can create a NAS-Iden User-Name to Filter-Id matrix then
the inclusion of a user on the RADIUS server will allow access to the specified resources on
all ip.buffers that refer to that RADIUS server.
The inclusion of programmable NAS-Identifier and NAS-IP-Address values should provide for
enough flexibility to manage either groups of ip.buffers or individual ip.buffers at the
RADIUS server. However, for some RADIUS servers, it may be that providing administrative
web-access is all that is practical. This is the main reason for allowing each of the four
services to choose where their authentication is taken.
Page 43
Scannex ip.buffer User Manual
© UK 2007-2021 Scannex Electronics Ltd. All rights reserved worldwide.
FTP
When FTP is linked to RADIUS then any channel that is set to deliver by “FTP Server” will
be checked against RADIUS. When the user logs in the FTP server will contact the RADIUS
server to determine which channel that user should access. The Filter-Id value is searched
for the first “F” value – so there should only be one “F” value in the returned Filter-Id
string. Consequently, if “
F3
” is received for a given user, then that user will log into
channel 3.
Pass-through and TCP Server Delivery
When RADIUS is not used, both of these services only ask for a password. When the TCP/IP
socket connects the user is shown a “Password:” prompt. However, when linked to RADIUS
we need both a username and password from the client.
Hence, when either of these services is set to refer to RADIUS the end user should use the
form “
user
:
password
” when replying to the “
Password:
” prompt.
If you enter just a password, then the RADIUS client will assume a username of
“ipbuffer_
boxname
_
serviceid
”,
e.g. “ipbuffer_Scannex_P1” for pass-through 1.
e.g. “ipbuffer_Scannex_T3” for TCP Server channel 3.
Other considerations
Unless the RADIUS server can create a NAS-Iden User-Name to Filter-Id matrix then
the inclusion of a user on the RADIUS server will allow access to the specified resources on
all ip.buffers that refer to that RADIUS server.
The inclusion of programmable NAS-Identifier and NAS-IP-Address values should provide for
enough flexibility to manage either groups of ip.buffers or individual ip.buffers at the
RADIUS server. However, for some RADIUS servers, it may be that providing administrative
web-access is all that is practical. This is the main reason for allowing each of the four
services to choose where their authentication is taken.
Page 43