Tripp Lite 0 Idades Manual

							151
Chapter 9: Authentication
Perform the following procedure to configure the LDAP authentication me\
thod to be used whenever the Console Server or any 
of its serial ports or hosts is accessed:
• Select Serial and Network: Authentication and check LDAP or LocalLDAP or LDAPLocal or LDAPDownLocal  
• Enter the Server Address (IP or host name) of the remote Authentication server. Multiple remote servers may be 
specified in a comma-separated list. Each server is tried in successio\
n. 
• Enter the Server Password 
• Check the Server Protocol box if SSL is to be used and/or enforced for communications with the LDAP server\
. Console 
servers running firmware v3.11 and above offer three options for LDAPS\
 (LDAP over SSL):
o LDAP over SSL preferred will attempt to use SSL for authentication, but will fall back to LDAP without SSL if the 
authentication attempt fails. For example, LDAP over SSL may fail due to certificate errors or the LDAP server may not 
be contactable on the LDAPS port.
o LDAP over SSL only will configure the console server to only accept LDAP over SSL. If LDAP over SSL fails, you will 
only be able to log in to the console server as root.
o LDAP (no SSL) only will configure the console server to only accept LDAP without SSL. If LDAP without SSL fails, you 
will only be able to log in to the console server as root.
• The Ignore SSL Certificate Error check box allows you to ignore SSL certificate errors so that LDAP over SSL works 
regardless of certificate errors. Any certificate can be used—sel\
f-signed or otherwise—on the LDAP server without having 
to install any certificates on the console server. If this setting is not checked, you must install the CA (certificat\
e authority) 
certificate that the LDAP server’s certificate was signed with on\
to the console server. For example, the LDAP server will 
contain a certificate singed using the certificate ‘myCA.crt’.
Note: The certificate needs to be in CRT format and myCA.crt needs to be installed onto console server at ‘/etc/config/ldaps_
ca.crt’. The file name must also be ‘ldaps_ca.crt’. You will need to copy the file and file name manually to this locatio\
n using 
‘scp’ or: scp /local/path/to/myCA.crt root@console_server:/etc/config/ldaps_ca.crt
• Click Apply. LDAP remote authentication will now be used for all user access to Con\
sole Server and serially or network 
attached devices
LDAP  The Lightweight Directory Access Protocol (LDAP) is based on the X.500\
 standard, but is significantly simpler and    
  more readily adapted to meet custom needs. The core LDAP specification\
s are all defined in RFCs. LDAP is a protocol   
 used to access information stored in an LDAP server. Further information on configuring remote RADIUS servers can    
 be found at the following sites:
  http://www.ldapman.org/articles/intro_to_ldap.html
  http://www.ldapman.org/servers.html
  http://www.linuxplanet.com/linuxplanet/tutorials/5050/1/
  http://www.linuxplanet.com/linuxplanet/tutorials/5074/4/  
						

							152
Chapter 9: Authentication
9.1.5 RADIUS/TACACS user configuration 
Users may be added to the local Console Server appliance. If they are no\
t added and they log in via remote AAA, a user will 
be added for them. This user will not show up in the configurators unl\
ess they are specifically added, at which point they are 
transformed into a completely local user. The newly added user must authenticate via the remote AAA server, and will not have 
any access if it is down.
If a local user logs in, they may be authenticated/authorized from the r\
emote AAA server, depending on the chosen priority of 
the remote AAA. A local user's authorization is the union of local and remote privileg\
es.
Example 1:
User A is locally added, and has access to ports 1 and 2. He is also defi\
ned on a remote TACACS server, which says he 
has access to ports 3 and 4. The user may log in with either his local o\
r TACACS password, and will have access to ports 
1 through 4. If TACACS is down, he will need to use his local password, and will only be able\
 to access ports 1 and 2. 
Example 2:
User B is only defined on the TACACS server, which says he has access to ports 5 and 6. When he attempts to log in,\
 a 
new user will be created for him, and he will be able to access ports 5 \
and 6. If the TACACS server is down, he will not 
have any access.
Example 3:
User C is defined on a RADIUS server only. He has access to all serial ports and network hosts.
Example 4:
User D is locally defined on an appliance using RADIUS for AAA. Even if the user is also defined on the RADIUS server, he 
will only have access to those serial ports and network hosts he has bee\
n authorized to use on the appliance.
If a “no local AAA” option is selected, then root will still be authenticated locally. 
Remote users may be added to the admin group via either RADIUS or TACACS. Users may have a set of authorizations set 
on the remote TACACS server. Users automatically added by RADIUS will have authorization for all re\
sources, whereas those 
added locally will still need their authorizations specified.
LDAP has not been modified, and will still need locally defined user\
s. 
9.1.6 Group support with remote authentication
All Console Servers allow remote authentication via RADIUS, LDAP and TACACS+. With Firmware V3.2 and later, RADIUS 
and LDAP can provide additional restrictions on user access based on gro\
up information or membership.   For example, with 
remote group support, RADIUS and LDAP users can belong to a local group \
that has been setup to have restricted access to 
serial ports, network hosts and managed devices.
Remote authentication with group support works by matching a local group\
 name with a remote group name provided by 
the authentication service. If the list of remote group names returned b\
y the authentication service matches any local group 
names, the user is given permissions as configured in the local groups\
.
To enable group support to be used by remote authentication services: 
• Select Serial & Network: Authentication
• Select the relevant Authentication Method
• Check the Use Remote Groups button
9.1.7  Remote groups with RADIUS authentication
• Enter the RADIUS Authentication and Authorization Server Address and Server Password
• Click Apply
• Edit the Radius user’s file to include group information and restar\
t the Radius server
When using RADIUS authentication, group names are provided to the Consol\
e Server using the Framed-Filter-Id attribute.  This 
is a standard RADIUS attribute, and may be used by other devices that au\
thenticate via RADIUS.
To interoperate with other devices using this field, the group names ca\
n be added to the end of any existing content in the   
						

							153
Chapter 9: Authentication
attribute, in the following format:
:group_name=testgroup1,users:
The above example sets the remote user as a member of testgroup1 and use\
rs if groups with those names exist on the 
Console Server. Any groups which do not exist on the Console Server are ignored.
When setting the Framed-Filter-Id, the system may also remove the leading colon for an empty field. \
 To work around this, add 
some dummy text to the start of the string.  For example:
dummy:group_name=testgroup1,users:
• If no group is specified for a user, for example AmandaJones, then the user will have no User Interface and\
 serial port 
access but limited console access
• Default groups available on the Console Server include ‘admin’ for\
 administrator access and ‘users’ for general user 
access 
TomFraser    Cleartext-Password := ”FraTom70”
   Framed-Filter-Id=”:group_name=admin:”
AmandaJones Cleartext-Password := ”JonAma83” 
FredWhite Cleartext-Password := ”WhiFre62”
  Framed-Filter-Id=”:group_name=testgroup1,users:”
JanetLong Cleartext-Password := ”LonJan57”
  Framed-Filter-Id=”:group_name=admin:”
• Additional local groups such as testgroup1 can be added via Users & Groups: Serial & Network    
						

							154
Chapter 9: Authentication
9.1.8 Remote groups with LDAP authentication
Unlike RADIUS, LDAP has built in support for group provisioning, which m\
akes setting up remote groups easier. The console 
server will retrieve a list of all the remote groups that the user is a \
direct member of, and compare their names with local 
groups on the Console Server. 
Note: Any spaces in the group name will be converted to underscores.
For example, in an existing Active Directory setup, a group of users may \
be part of the “UPS Admin” and “Router Admin” 
groups.  On the Console Server, these users will be required to have access to a group “Router_Admin”, with access to port 
1 (connected to the router), and another group “UPS_Admin”, with access to port 2 (connected to the UPS). Once LDAP is 
setup, users that are members of each group will have the appropriate pe\
rmissions to access the router and UPS.
Currently, the only LDAP directory service that supports group provisioning is Mi\
crosoft Active Directory. Support is planned for 
OpenLDAP at a later time.
To enable group information to be used with an LDAP server:
• Complete the fields for standard LDAP authentication including LDAP Se\
rver Address, Server Password, LDAP Base DN, 
LDAP Bind DN and LDAP User Name Attribute
• Enter memberOf for LDAP Group Membership Attribute as group membership is currently only supported on Active 
Directory servers
• If required, enter the group information for LDAP Console Server Group DN and/or LDAP Administration Group DN
Note: When using remote groups with LDAP remote auth, you will need to have c\
orresponding local groups on the console 
server. In situations where LDAP group names can contain upper case and space \
characters, the local group name on the 
console server must be all lower case and any spaces must be replaced wi\
th underscrores. For example, a remote group 
on the LDAP server may be My Ldap Access Group, but needs a corresponding local group on the console server called 
my_ldap_access_group. For any group membership to be effective, the local group must specify\
 what the group member is 
granted access to.
A user must be a member of the LDAP Console Server Group DN group in ord\
er to gain access to the console and user 
interface. For example, the user must be a member of ‘MyGroup’ on the Active S\
erver to gain access to the Console Server.  
Additionally, a user must be a member of the LDAP Administration Group DN in order t\
o gain administrator access to the 
Console Server.  For example, the user must be a member of ‘AdminGroup’ on the Active Server to receive administration 
privileges on the Console Server.  
• Click Apply.  
						

							155
• Ensure the LDAP service is operational and group names are correct withi\
n the Active Directory
Chapter 9: Authentication
9.1.9  Idle timeout
You can specify amount of time in minutes the console server waits before\
 it terminates an idle ssh, pmshell or web connection.  
 
• Select Serial and Network: Authentication
• Web Management Session Timeout specifies the browser console session id\
le timeout in minutes. The default setting is 
20 minutes
• CLI Management Session Timeout specifies the ssh console session idle \
timeout in minutes. The default setting is to 
never expire
• Console Server Session Timeout specifies the pmshell serial console se\
rver session idle timeout in minutes. The default 
setting is to never expire  
						

							156
Chapter 9: Authentication
9.1.10  Kerberos authentication 
The Kerberos authentication can be used with UNIX and Windows (Active Directory) Kerberos servers. This form of authentication 
does not provide group information, so a local user with the same userna\
me must be created, and permissions set.
Note: Kerberos is very sensitive to time differences between the Key Distrib\
ution Center (KDC) authentication server and the 
client device. Please make sure that NTP is enabled, and the time zone i\
s set correctly on the console server.
When authenticating against Active Directory, the Kerberos Realm will be the domain name, and the Master KDC will be the 
address of the primary domain controller.
9.1.11  Authentication testing 
The Authentication Testing tab enables the connection to the remote authentication server to\
 be tested. 
9.2 PAM (Pluggable Authentication Modules) 
The Console Server supports RADIUS, TACACS+ and LDAP for two-factor authentication via PAM (Pluggable Authentication 
Modules). PAM is a flexible mechanism for authenticating Users. Nowadays, a numbe\
r of new ways of authenticating users 
have become popular. The challenge is that each time a new authentication scheme is develop\
ed, it requires all the necessary 
programs (login, ftpd, etc.) to be rewritten to support it.
PAM provides a way to develop programs that are independent of authentica\
tion schemes. These programs need 
"authentication modules" to be attached to them at run-time in order to \
work. Which authentication module is to be attached 
is dependent upon the local system setup and is at the discretion of the\
 local Administrator.
The Console Server family supports PAM to which we have added the following modules for remote authenticatio\
n:
RADIUS    - pam_radius_auth     (http://www.freeradius.org/pam_radius_auth/)
TACACS+  - pam_tacplus         (http://echelon.pl/pubs/pam_tacplus.html)
LDAP      - pam_ldap          (http://www.padl.com/OSS/pam_ldap.html)
Further modules can be added as required.
Changes may be made to files in /etc/config/pam.d/ which will persis\
t, even if the authentication configurator is run.
• Users added on demand:
 When a user attempts to log in, but does not already have an account on \
the Console Server, a new user account will be 
created. This account will not have any rights, and no password set. The\
y will not appear in the configuration tools.
 Automatically added accounts will not be able to log in if the remote se\
rvers are unavailable. RADIUS users are currently 
assumed to have access to all resources, so will only be authorized to l\
og in to the Console Server. RADIUS users will be 
authorized each time they access a new resource.
• Admin rights granted over AAA:
 Users may be granted Administrator rights via networked AAA. For TACACS, a priv-lvl of 12 of above indicates an 
administrator. For RADIUS, administrators are indicated via the Framed Filter ID. (See the example configuration files 
below, for example.)
• Authorization via TACACS for both serial ports and host access:
 Permission to access resources may be granted via TACACS by indicating an appliance and a port or networked host the 
user may access. (See the example configuration files below, for example.)  
						

							157
Chapter 9: Authentication
TACACS Example:
user = tim {
   service = raccess {
        priv-lvl = 11
        port1 = xxxxx/port02
        port2 = 192.168.254.145/port05
   }
   global = cleartext mit
}
RADIUS Example:
paul    Cleartext-Password := "luap"
         Service-Type = Framed-User,
         Fall-Through = No,
         Framed-Filter-Id=":group_name=admin"
The list of groups may include any number of entries separated by a comm\
a. If the admin group is included, the user will be 
made an Administrator.
If there is already a Framed-Filter-Id, simply add the list of group_names after the existing entries, incl\
uding the separating colon ":".
9.3 Secure Management Console Access
Selecting HTTPS Server in System: Services enables the Administrator to establish a secure browser connection 
Management Console: 
• Activate your preferred browser and enter https:// IP address. For  example, if the Console Server has been set up with an 
IP address of 200.122.0.12, you need to type https:// 200.122.0.12 in yo\
ur address bar 
• Your browser may respond with a message that verifies the security cert\
ificate is valid but notes that it is not necessarily 
verified by a certifying authority. To proceed you need to click yes if you are using Internet Explorer or se\
lect accept this 
certificate permanently (or temporarily) if you are using Mozilla Firefox. 
• You will then be prompted for the Administrator account and password as n\
ormal. 
When you have a secure HTTPS connection in place, the SSL secured icon will appear at the bottom of the browser screen. 
You can verify the level of encryption in place by clicking on this icon.\
 
When you first enable and connect via HTTPS, it is normal that you may receive a certificate warning. The defa\
ult SSL certificate 
in your Console Server is embedded during testing and is not signed by a\
 recognized third party certificate authority. Rather, it is 
signed by our own signing authority. These warnings do not affect the encryption protection you have agains\
t eavesdroppers.   
						

							158
Chapter 9: Authentication
9.4 SSL Certificate 
The Console Server uses the Secure Socket Layer (SSL) protocol for encrypted network traffic between itself and a conne\
cted 
user. During the connection establishment the Console Server has to expose i\
ts identity to the user’s browser using a 
cryptographic certificate. The default certificate that comes with t\
he Console Server device upon delivery is for testing purpose 
only and should not be relied on for secured global access.
 
The System Administrator should not rely on the default certificate as the secured global acces\
s 
mechanism for use through Internet
It is recommended you generate and install a new base64 X.509 certific\
ate that is unique for a particular Console Server.
To do this the Console Server must be enabled to generate a new cryptogra\
phic key and the associated Certificate Signing 
Request (CSR) that needs to be certified by a Certification Authority (CA).\
 A certification authority verifies that you are the 
person who you claim you are, and signs and issues a SSL certificate to you. To create and install a SSL certificate for the 
Console Server: 
• Select System: SSL Certificate and fill out the fields as explained below:   
						

							159
Common name   This is the network name of the Console Server once it is installed in t\
he network (usually 
the fully   
qualified domain name). It is identical to the name that is used to a\
ccess the Console Server 
with a web browser (without the “http://” prefix). In case the\
 name given here and the actual 
network name differ, the browser will pop up a security warning when the Console Server is \
accessed using HTTPS
Organizational Unit  This field is used for specifying to which department within an organi\
zation the Console 
Server belongs
Organization   The name of the organization to which the Console Server belongs
Locality/City    The city where the organization is located
State/Province  The state or province where the organization is located
Country    The country where the organization is located. This is the two-letter IS\
O code, e.g. DE for 
Germany, or US for the USA. (Note: the country code has to be entered in CAPITAL LETTERS)
Email   The email address of a contact person that is responsible for the Consol\
e Server and its 
security
Challenge Password  Some certification authorities require a challenge password to authori\
ze later changes on 
the certificate (e.g. revocation of the certificate). The minimal \
length of this password is 4 
characters
Confirm Challenge Password  Confirmation of the Challenge Password
Key length    This is the length of the generated key in bits. 1024 Bits are supposed \
to be sufficient for 
most cases. Longer keys may result in slower response time of the Consol\
e Server during 
connection establishment
 o Once this is done, click on the button Generate CSR which will initiate the Certificate Signing Request generation.   
    The CSR can be downloaded to your administration machine with the Download bu\
tton
 o Send the saved CSR string to a Certification Authority (CA) for certification. You will get the new certificate from  
    the CA after a more or less complicated traditional authentication proce\
ss (depending on the CA)
 o Upload the certificate to the Console Server using the Upload button as shown below
After completing these steps the Console Server has its own certificat\
e that is used for identifying the Console Server to its 
users.
Note: Information on issuing certificates and configuring HTTPS from the\
 command line can be found in Chapter 15 - 
Advanced
Chapter 9: Authentication  
						

							160
Chapter 10: Nagios Integration
Nagios is a powerful, highly extensible open source tool for monitoring \
network hosts and services. The core Nagios software 
package will typically be installed on a server or virtual server, the central Nagios server.
Tripp Lite Console Servers can operate in conjunction with a central/upst\
ream Nagios server to provide distributing monitoring 
of attached network hosts and serial devices. The Console Servers can em\
bed the NSCA (Nagios Service Checks Acceptor) 
and NRPE (Nagios Remote Plug-in Executor) add-ons. This allows them to\
 communicate with the central Nagios server, 
eliminating the need for a dedicated Slave Nagios server at remote sites\
.
The Console Servers embed a basic set of distributed monitoring add-ons \
and can be uploaded with additional customizable 
distributed monitoring.
Note: If you have an existing Nagios deployment, you may wish to use the Con\
sole Server in a distributed monitoring server 
capacity only. In this case and if you are already familiar with Nagios, skip ahead t\
o section 10.3.
10.1  Nagios Overview
Nagios provides central monitoring of the hosts and services in your dis\
tributed network. Nagios is freely downloadable, 
open source software. This section offers a quick background of Nagios a\
nd its capabilities. A complete overview, FAQ and 
comprehensive documentation are available at: http://www.nagios.org 
Nagios forms the core of many leading commercial system management solut\
ions such as GroundWork: http://www.
groundworkopensource.com
Nagios takes some time to install and configure, but once it is up and\
 running, it provides an outstanding network monitoring 
system. With Nagios you can: 
• Display tables showing the status of each monitored server and network s\
ervice in real time 
• Use a wide range of freely available plug-ins to make detailed checks of\
 specific services,  e.g., don't just check if a 
database is accepting network connections, check that it can actually va\
lidate requests and return real data
• Display warnings and send warning e-mails, pager or SMS alerts when a se\
rvice failure or degradation is detected
• Assign contact groups who are responsible for specific services in spe\
cific time frames