Sec/User Mgmt: Configure PAM Login Capability

Document created by RSA Information Design and Development on Sep 19, 2017Last modified by RSA Information Design and Development on Oct 2, 2017
Version 3Show Document
  • View in full screen mode
  

This topic explains how to configure NetWitness Suite to use Pluggable Authentication Modules (PAM) to authenticate external user logins.

PAM login capability involves two separate components:

  • PAM for user authentication
  • NSS for group authorization

Together they provide external users the capability to log on to NetWitness Suite without having an internal NetWitness Suite account, and to receive permissions or roles determined by mapping the external group to a NetWitness Suite security role. Both components are required for a login to succeed.

External authentication is a system-level setting. Before configuring PAM, carefully review all of the information here.

Pluggable Authentication Modules

PAM is a Linux-provided library responsible for authenticating users against authentication providers such as RADIUS, Kerberos, or LDAP. For implementation, each authentication provider uses its own module, which is in the form of an operating system (OS) package such as pam_ldap. NetWitness Suite uses the OS-provided PAM library, and the module that the PAM library is configured to use, to authenticate users.

Note: The PAM provides only the ability to authenticate.

Name Service Switch

NSS is a Linux feature that provides databases that the OS and applications use to discover information like hostnames; user attributes like home directory, primary group, and login shell; and to list users that belong to a given group. Similar to PAM, NSS is configurable and uses modules to interact with different types of providers. NetWitness Suite uses OS-provided NSS capabilities to authorize external PAM users by looking up whether a user is known to NSS and then requesting from NSS the groups of which that user is a member. NetWitness Suite  compares the results of the request to the NetWitness Suite External Group Mapping and if a matching group is found, the user is granted access to log on to NW with the level of security defined in the External Group Mapping.

Note: NSS does not provide authentication.

PAM and NSS Combination

Both PAM (authentication) and NSS (authorization) must succeed in order for an external user to be allowed to log on to NetWitness Suite. The procedure for configuring and troubleshooting PAM is different than the procedure for configuring and troubleshooting NSS. The PAM examples in this guide include Kerberos, LDAP, and Radius. The NSS examples include Samba, LDAP, and UNIX. The PAM and NSS module combination used is determined by site needs.

Process Overview

To configure PAM login capability, follow the instructions in this document to complete each step:

  1. Configure and test the PAM module.
  2. Configure and test the NSS service.
  3. Enable PAM in NetWitness Server.
  4. Create group mappings in NetWitness Server.

Prerequisites

Before beginning the setup of PAM, review the procedure and gather the external authentication server details depending on the PAM module you want to implement.

Before beginning the setup of NSS, review the procedure, identify the group names that you will use in the External Group mapping, and gather the external authentication server details, depending on the NSS service being used.

Before beginning setup of PAM in NetWitness Suite, identify the group names that you will use in the External Group mapping. When mapping roles, the role in NetWitness Suite must match a group name that exists in the external authentication server.

Configure and Test the PAM Module

Choose one of the following sections to set up and configure the PAM component:

  • PAM Kerberos
  • PAM LDAP
  • PAM RADIUS
  • SecurID

PAM Kerberos

Kerberos Communication Ports – TCP 88

To configure PAM authentication using Kerberos:

  1. Execute the following command (but first verify that the krb5-workstation package is installed in your environment):
    yum install krb5-workstation pam_krb5  
  2. Edit the following lines in the Kerberos configuration file /etc/krb5.conf. Replace variables, which are delimited by <angle brackets>, with your values and omitting the angle brackets. Capitalization is required where shown.

    # Configuration snippets may be placed in this directory as well
    includedir /etc/krb5.conf.d/

    [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

    [libdefaults]
    dns_lookup_realm = false
    ticket_lifetime = 24h
    dns_lookup_kdc = true
    renew_lifetime = 7d
    forwardable = true
    rdns = false
    default_realm = <DOMAIN.COM>
    default_ccache_name = KEYRING:persistent:%{uid}

    [realms]
    <DOMAIN.COM> = {
    kdc = <SERVER.DOMAIN.COM>
    admin_server = <SERVER.DOMAIN.COM>
    }

    [domain_realm]
    <domain.com> = <DOMAIN.COM>
    <.domain.com> = <DOMAIN.COM>
  3. Test the Kerberos configuration with the command: 
    kinit <user>@<DOMAIN.COM>
    No output after entering the password indicates success.
  4. Edit the NetWitness Server PAM configuration file  /etc/pam.d/securityanalytics to add the following line. If the file does not exist, create it and add the following line:
    auth sufficient pam_krb5.so no_user_check

This completes the configuration for PAM Kerberos. Now, proceed to the next section, Configure and Test the NSS Service.

PAM LDAP

LDAP Communication Ports - TCP 389 or TCP 636 

TCP 389 can be used for both unencrypted and in most cases encrypted traffic and is usually sufficient. Most modern LDAP implementations support the start_tls command once connected to port 389, which upgrades the connection from an unencrypted to an encrypted state. In this instance, LDAP URIs still begin with ldap:// even when using start_tls.

TCP 636 is used only in instances where the LDAP server does not support the start_tls command. In this case, LDAP URIs begin with ldaps:// and the start_tls command is not used.

To configure PAM authentication using LDAP:

  1. Execute the following command (but first verify that the openldap-clients package is installed in your environment):
    yum install nss-pam-ldapd openldap-clients
  2. Edit the LDAP configuration file /etc/nslcd.conf as shown in the following example:

Note: Replace variables, which are delimited by <angle brackets>, with your values and omit the angle brackets. Capitalization is required where shown.

Sample /etc/nslcd.conf file entries:
uri ldap://<server.domain.com>
base <dc=domain,dc=com>
binddn <cn=bineuser,dc=domain,dc=com>
bindpw <secret>

  1. After modifying the /etc/nslcd.conf file, run the following command:
    systemctl restart nslcd
  2. (Optional) To enable secure transport for LDAP communication with peer certificate verification (more secure), refer to Linux man page for nslcd for the correct code modification for the /etc/nslcd.conf file.

Note: Windows domain controllers do not by default enable secure LDAP transport. They require the installation of a server certificate for Server Authentication. Obtaining and installing this certificate onto the DC is outside the scope of this document. Some guidance on this is available at https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx.

  1. (Optional) To enable secure transport for LDAP communication without peer certificate, refer to Linux man page for nslcd for the correct code modification for the /etc/nslcd.conf file.
  2. To troubleshoot the LDAP configuration, first stop the nslcd service by entering the following command:
    systemctl stop nlscd
  3. To output troubleshooting and status information from the service to the console, run the nslcd service in debug mode from the command line:
    nslcd -d
  4. Edit the NetWitness Server PAM configuration file  /etc/pam.d/securityanalytics to add the following line. If the file does not exist, create it and add the following line:
    auth sufficient pam_ldap.so

This completes the configuration for PAM LDAP. Now, proceed to the next section, Configure and Test the NSS Service.

PAM RADIUS

Radius Communication Ports - UDP 1812 or UDP 1813

To configure PAM authentication using Radius you must add the NetWitness Server to your Radius Server’s Client list and configure a shared secret. Contact the Radius Server Administrator for this procedure.

To configure PAM authentication for RADIUS using LDAP:

  1. Execute the following command (but first verify that the pam_radius package is installed in your environment):
    yum install pam_radius
  2. Edit the RADIUS configuration file, /etc/raddb/server as follows:
    # server[:port] shared_secret  timeout (s)
    server          secret         3
  3. Edit the NetWitness Server PAM configuration file  /etc/pam.d/securityanalytics to add the following line. If the file does not exist, create it and add the following line:
    auth sufficient pam_radius_auth.so

Caution: For PAM RADIUS to work, the /etc/raddb/server files must have write permission. The command needed for this is: chown netwitness:netwitness /etc/raddb/server.

The PAM Modules and associated services output information to /var/log/messages and /var/log/secure. These outputs can be used to assist in troubleshooting configuration problems.

The following procedure is an example of the steps to configure PAM authentication for RADIUS using SecurID:

Note: The examples in these tasks use RSA Authentication Manager as the RADIUS server.

  1. Execute the following command (but first verify that the pam_radius package is installed in your environment):

    yum install pam_radius

  2. Edit the RADIUS configuration file, /etc/raddb/server and update it with the authentication manager instance hostname, shared secret and timeout value:

    # server[:port] shared_secret timeout (s)

    111.222.33.44 secret 1

    #other-server other-secret 3

    192.168.12.200:6369 securid 10

    Note: You must comment out 127.0.0.1 & other-server lines and add the IP address of the authentication manager primary instance with RADIUS port number (for example, 192.168.12.200:1812), RADIUS shared secret and a timeout value of 10.

  3. Edit the NetWitness Server PAM configuration file /etc/pam.d/securityanalytics to add the following line. If the file does not exist, create it and add the following line:

    auth sufficient pam_radius_auth.so

    Note: You can add debug to the end of the above line in the /etc/pam.d/securityanalytics file to enables PAM debugging (for example, auth sufficient pam_radius_auth.so debug)

The PAM Modules and associated services output information to /var/log/messages and /var/log/secure.These outputs can be used to assist in troubleshooting configuration problems.

Add a RADIUS Client and Associated Agent

Note: The examples in these tasks use RSA Authentication Manager as the RADIUS server.
You must use administrative account credentials to log on RSA Authentication Manager Security Console.

To add a RADIUS Client and Associated Agent:

  1. Log on to RSA Authentication Manager.
    The Security Console is displayed.
  2. In the Security Console, Click RADIUS > RADIUS Client > Add New.
    The Add RADIUS Client page is displayed.
    Image of RSA Security Console for Add RADIUS Client settings
  3. In RADIUS Client Settings, provide the following information:
    1. In the Client Name field, enter the name of the client, for example, NetWitness Suite.
    2. In the IPv4 Address field, enter the IPv4 address of the RADIUS client, for example, 192.168.12.108.
    3. In the Make/Model drop-down list, select the type of RADIUS client, for example, Fortinet.
    4. In the Shared Secret field, enter the authentication shared secret.
  4. Click Save & Create Associated RSA Agent.
    Image of Add New Authentication Agent page.
  5. Click Save.

If Authentication Manager Instance is unable to find the authentication agent on the network, A warning page is displayed. Click Yes, Save Agent.

For more information, see Add a RADIUS Client topic in RSA Authentication Manager 8.2 Administrator’s Guide.

This completes the configuration for PAM RADIUS. Now, proceed to the next section, Configure and Test the NSS Service.

PAM Agent for SecurID

PAM Communication Port - UDP 5500

Prerequisites
The RSA SecurID PAM module is supported only under the following conditions:

  1. Trusted connections must be enabled and functioning between NetWitness Suite and Core services.

Process Overview 

The high-level steps to configure the SecurID PAM module are:

  1. Configure Authentication Manager:
    a. Add Authentication Agent.
    b. Download configuration file.
  2. Configure NetWitness Server:
    a. Copy configuration file from Authentication Manager and customize it.
    b. Install the PAM SecurID Module.
  3. Test connectivity and authentication.

Then follow the remaining procedures in the sections that follow:

  • Configure NSS.
  • Enable PAM in NetWitness Server.
  • Configure group mappings in NetWitness Server.

To configure Authentication Manager:

  1. Log on to RSA Authentication Manager.
    The Security Console is displayed.
    Image of the Authentication Manager Security Console
  2. In the Security Console, add a new authentication agent.
    Click Access > Authentication Agents > Add New.
    The Add New Authentication Agent page is displayed.
    Image of the Add New Authentication Agent page.
  3. In the Hostname field, type the hostname of the NetWitness Server.
  4. Click Resolve IP.
    The IP address of the NetWitness Server is automatically displayed in the IP Address field.
  5. Keep the default settings and click Save.
  6. Generate a configuration file.
    Go to Access > Authentication Agents > Generate Configuration File.
    The Generate Configuration File page is displayed.
    Image of the Generate Configuration File page.
  7. Keep the defaults and click Generate Config File.
    This creates AM_Config.zip, which contains two files.
  8. Click Download Now.

To install and configure the PAM SecurID module:

  1. On the NetWitness Server, make a directory:
    mkdir /var/ace
  2. On the NetWitness Server, copy sdconf.rec from the .zip file to /var/ace.
  3. Create a text file sdopts.rec in the /var/ace directory.
  4. Insert the following line:
    CLIENT_IP=<IP address of NetWitness Server>
  5. Install the SecurID Authorization Agent for PAM, which is available in the yum repository:
    yum install sid-pam-installer
  6. Run the install script:
    /opt/rsa/pam-agent-installer/install_pam.sh
  7. Follow the prompts to accept or change the defaults. 
  8. Edit the NetWitness Server PAM configuration file, /etc/pam.d/securityanalytics to add the following line. If the file does not exist, create it and add the following line:
    auth sufficient pam_securid.so

This completes the installation of the SecurID PAM module.  Next, test the connectivity and authentication. Then, follow the procedures in Configure and Test the NSS Service.

Note: If the PAM SecurID setup is not complete, it may crash the Jetty server and the NetWitness Suite UI will not be displayed. You must wait until the PAM authentication configuration is complete and then restart the Jetty server.

To test connectivity and authentication:

  1. Run /opt/pam/bin/64bit/acetest, enter username and passcode
  2. (Optional) If acetest fails, turn on debugging:
    vi/etc/sd_pam.conf
    RSATRACELEVEL=15
  3. Run /opt/pam/bin/64bit/acestatus. Output below

RSA ACE/Server Limits
---------------------
Configuration Version : 15 Client Retries : 5 
Client Timeout : 5 DES Enabled : Yes 

RSA ACE/Static Information
--------------------------
Service : securid Protocol : udp Port Number : 5500 

RSA ACE/Dynamic Information
---------------------------
Server Release : 8.1.0.0 Communication : 5

RSA ACE/Server List
-------------------
Server Name :           auth81.netwitness.local
Server Address :        192.168.100.10
Server Active Address : 192.168.100.10
Master : Yes Slave : No Primary : Yes 
Usage : Available for Authentications

  1. (Optional) To troubleshoot the Authentication Manager server,
    go to Reporting > Real-time Activity Monitors > Authentication Activity Monitor. 
    Then click Start Monitor.
  2. If you changed the setting, reset RSATRACELEVEL to 0:
    vi/etc/sd_pam.conf
    RSATRACELEVEL=0

Caution: After installation, verify that VAR_ACE in the /etc/sd_pam.conf file points to the correct location of the sdconf.rec file. This is the path to the configuration files. The command needed for this is: chown -R netwitness:netwitness /var/ace.

This completes the configuration for PAM Agent for SecurID. Now, proceed to the next section, Configure and Test the NSS Service.

Configure and Test the NSS Service

Choose an NSS Service

There are three NSS service options: Samba, LDAP, and UNIX. There are advantages and disadvantages to all three.

                           
NSS Samba ProsNSS Samba Cons
Purpose built for Active DirectoryCannot be used with non-AD back-ends
Minimal to no configuration must be performed in Active DirectoryPotentially more difficult to configure and troubleshoot
No special user accounts neededRequires the NW Server machine be joined to the Active Directory Domain
 Uses many ports to communicate with Active Directory; more difficult to implement across firewalls and proxies

 

                         
NSS LDAP ProsNSS LDAP Cons
Basic configuration is simplerMay require additional configuration and roles inside of Active Directory
Can communicate with any LDAP implementationRequires configuration of an LDAP bind account
Uses a single TCP port for communication - easier to work with firewalls and proxiesMore difficult to enable secure transport unless configured to not validate server certificates
Does not require joining NW host to AD domain 

NSS UNIX

No configuration is necessary to enable the NSS UNIX module; it is enabled in the host operating system by default. To authorize a user for a specific group, simply add that user to the operating system and add them to a group:

  1. Create an OS group to use add your external user to with this command:
    groupadd <groupname>
  2. Add the external user to the OS with this command:
    adduser -G <groupname> -M -N <externalusername>

Note: Note that this does NOT permit or allow access to the NW Server console.

This completes the configuration for NSS UNIX. Next, go to Test NSS Functionality.

NSS Samba

AD Winbind Communication Ports

The following ports are the minimum ports internal testing indicates should be open to permit NSS Samba functionality. These are provided only as a reference.

TCP 88 - Kerberos
TCP 139 - Netbios
TCP 389 - LDAP
UDP 53 - DNS
UDP 88 - Kerberos
UDP 389 - LDAP

Additional ports may be needed, depending on site-specific requirements of implementation. See the following article for information on all ports Active Directory communication may require: http://technet.microsoft.com/en-us/library/dd772723(ws.10).aspxhttp://technet.microsoft.com/en-us/library/dd772723%28ws.10%29.aspx

To configure NSS Samba:

  1. Edit the Samba configuration file, /etc/samba/smb.conf, as follows. Replace variables, which are delimited by <angle brackets>, with your values and omitting the angle brackets. Capitalization is required where shown.
    [global]
    workgroup = domain
    netbios name = <NW_APPLIANCE_HOSTNAME>
    password server = <ADSERVER.DOMAIN.COM>
    realm = <DOMAIN.COM>

    local master = no
    security = ads
    syslog only = yes
    log file = /var/log/samba/log.%m
    max log size = 5120
    idmap config * : range = 16777216-33554431
    template shell = /bin/bash
    winbind use default domain = true
    winbind offline logon = false
    winbind enum groups = yes
  2. To enable and start the Windows binding service, winbind, enter the following commands:
    systemctl enable winbind
    systemctl start winbind
  3. Edit the NSS configuration file, /etc/nsswitch.conf. Update only the below 2 entries and leave the rest all default:
    passwd:     files winbind
    group:      files winbind
  4. To join the Domain, enter the following command:
    net ads join -U <DomainAdminUser>
  5. To store the Domain Controller SID, enter the following command:
    net rpc getsid -S <SERVER.DOMAIN.COM>
  6. Test NSS functionality as described in the Test NSS Functionality section.  
  7. When you have confirmed that NSS is working properly from the command line, to reboot the host for the NSS changes to take effect, enter the following command.
    reboot

To troubleshoot NSS Samba:

To confirm whether NSS Winbind is able to communicate successfully with Active Directory:

  1. Enter the following commands:
    wbinfo -u to return a list of AD users
    wbinfo -g to return a list of AD groups
  2. If neither command succeeds, run winbind in console debug mode by entering the following commands:
    systemctl stop winbind
    winbindd -S -F -d <optional debugleve 0-10>
  3. From a separate ssh session, repeat step 1 and watch the winbindd output for any indication of the problem.
    Increase winbindd debugging verbosity as needed.
  4. Make any necessary adjustments to /etc/samba/smb.conf.
  5. In the winbindd debug window from step 2, stop winbindd by typing CTRL-C
    Repeat steps 1 and 2 and continue troubleshooting until the wbinfo commands succeed.
  6. Once the wbinfo commands succeed, use the getent commands from the Testing NSS Functionality section of this guide to test NSS.
    getent passwd <pamUser>
    getent group <groupOfPamUser>
  7. When getent succeeds, stop the command line winbindd by typing CTRL-C and enter the following command to start the service daemon:
    systemctl start winbind

If wbinfo -g succeeds from the command line but search for external group mapping does not display any Active Directory groups:

  1. Add the following line to to /etc/samba/smb.conf:
    allow trusted domains = no
  2. Type systemctl restart winbind .

This completes the configuration for NSS Samba. Next, go to Test NSS Functionality.

NSS LDAP

Note: These instructions require all Active Directory PAM user and NSS group objects to have their uidNumber and gidNumber attributes set to UNIX-style UID and GID numbers in order to be used by NSS LDAP. Older Active Directory schemas may not have these attributes by default. Newer AD schemas may have these attributes but they may not be defined in each object. Correctly configuring these attributes is beyond the scope of this document. Contact your Active Directory administrator to have these attributes defined for your PAM users and NSS groups.

An LDAP bind user must be created in Active Directory in order for NSS to be used. This user should be configured to not have its password expire. Because these credentials must be specified to the NSS LDAP service in plaintext, the permissions of /etc/nslcd.conf should be left at their default of 600 so the file cannot be read by system users other than root.

LDAP Communication Ports - TCP 389 or TCP 636

TCP 389 can be used for both unencrypted and in most cases encrypted traffic and is usually sufficient. Most modern LDAP implementations support the start_tls command once connected to port 389, which upgrades the connection from an unencrypted to an encrypted state. In this instance, LDAP URIs still begin with ldap:// even when using start_tls.

TCP 636 is only used in instances where the LDAP server does not support the start_tls command.  In this instance, LDAP URIs begin with ldaps:// and the start_tls command is not used.

To configure the NSS module for LDAP with Active Directory:

  1. Obtain the nss-pam-ldapd package from the SMCUPDATE repository or from the NetWitness Server Updates Repository if the server is synchronized with SMCUPDATE. This requires a configured Live Account in NetWitness Suite.
  2. To install the package, enter the following command:
    yum install nss-pam-ldapd
  3. Edit /etc/nslcd.conf to include the lines below, ensuring that all existing lines in the file are first commented out using a hash mark # at the beginning of the line:
    uid nslcd
    gid ldap
    uri ldap://<server.domain.com>
    base <dc=domain,dc=com>
    binddn <cn=binduser,dc=domain,dc=com
    bindpw <secret>

    Note: You will need to add additional mappings between NSS lookups and LDAP lookups for your specific environment. Please refer to Linux man page for nslcd for specific details.
  4. (Optional) To enable secure transport for LDAP communication with peer certificate verification (more secure), refer to Linux man page for nslcd for the correct code modification for the /etc/nslcd.conf file.

Note: Windows Domain Controllers do not by default enable secure LDAP transport. They require the installation of a server certificate for Server Authentication. Obtaining and installing this certificate onto the DC is outside the scope of this document. Some guidance on this is available from this URL: https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

  1. (Optional) To enable secure transport for LDAP communication without peer certificate, refer to Linux man page for nslcd for the correct code modification for the /etc/nslcd.conf file.
  2. Edit the NSS configuration file /etc/nsswitch.conf. Update only the below two entries and leave the rest at their default values:
    passwd:files ldap
    group:files ldap
  3. To enable and start the NSLCD service, enter these commands:
    systemctl enable nslcd
    systemctl start nslcd
  4. Test NSS functionality using guidance in the Test NSS Functionality section. If NSS tests fail, troubleshoot NSS LDAP as described in Troubleshoot NSS LDAP.
  5. When you have confirmed that NSS is working properly from the command line, reboot the host for the NSS changes to take effect.
    reboot

To troubleshoot NSS LDAP:

  1. To troubleshoot NSS LDAP, first stop the nslcd service by entering the following command:
    systemctl stop nslcd
  2. To output troubleshooting and status information from the service to the console, run the nslcd service in debug mode from the command line.
    nslcd -d
  3. (Optional) To increase debug verbosity, add an additional d multiple times to the end of nslcd -d, for example, enter the following command:
    nslcd -ddd
  4. From a separate ssh session, use the getent commands from the Testing NSS Functionality section of this guide to test NSS. Watch the debug output from nslcd for any indications of where the failure is occurring.  Increase nslcd debugging verbosity as needed.
    getent passwd <pamUser>
    getent group <groupOfPamUser>
  5. Make any necessary adjustments to /etc/nslcd.conf based on the output of step 2 or 3.
  6. In the nslcd debug window from step 2 or 3, stop nslcd with CTRL-C.  Repeat step 2 or 3 and continue troubleshooting until the getent command succeeds.
  7. When getent succeeds, stop the command line nslcd and start the service daemon:
    systemctl start nslcd

Common problems may include:

  • LDAP secure transport SSL certificate not installed on LDAP/AD server.
  • CA certificate verification failed – comment out the tls_cacert line in /etc/nslcd.conf and instead try tls_reqcert never.  If it succeeds, you know that certificate verification that is failing.
    • Root CA certificate is not in PEM format.
    • Using issuing CA certificate rather than root CA certificate.
    • LDAP server’s SSL certificate name does not match its hostname.
  • Incorrect base DN.
  • LDAP bind user or password is not specified correctly.
  • Incorrectly specifying ldaps:// instead of ldap:// in uri line of /etc/nslcd.confldaps:// should only be used when using LDAPS but not using the start_tls command.
  • Active Directory users and groups do not have uidNumber or gidNumber attributes set.
  • Network firewall is blocking communications.
  • LDAP server hostname specified cannot be resolved.
    • Incorrect DNS settings in /etc/resolv.conf.
    • Bad hostname specified in uri line of /etc/nslcd.conf.

This completes the configuration for NSS LDAP. Next, go to Test NSS Functionality.

Test NSS Functionality

To test whether NSS is working with any of the previous NSS services, use the following commands:

getent passwd <pamUser>
getent group <groupOfPamUser>

Output should be similar to:

[root@~]# getent passwd myuser
myuser:*:10000:10000::/home/myuser:/bin/sh

[root@~]# getent group mygroup
mygroup:*:10000:myuser3

  • If neither command produces output, NSS is not working properly for external authorization. Refer to the troubleshooting guidance for your NSS module provided in this document.
  • If getent commands succeed and authentication success is confirmed in /var/log/secure but NetWitness Suite still fails to allow External users to login:
    • Was the correct group name specified for the NSS group in NW External Group Mapping?  See Enable PAM and Create Group Mappings below.
    • It is possible that the NSS configuration has changed and NetWitness Suite has not picked up the change.  A reboot of the NetWitness Suite host will cause NetWitness Suite to pick up NSS configuration changes.  A restart of jetty is not sufficient.

Proceed to the next section, Enable PAM in NetWitness Server.

Enable PAM in NetWitness Server

  1. In NetWitness Suite, go to ADMIN > Security.
    The Admin > Security view is displayed with the Users tab open.
  2. Click the Settings tab.
  3. Under PAM Authentication, select Enable PAM Authentication and click Apply.
    This is an example of the PAM Authentication section.

Test PAM Authentication

To test external authentication for PAM:

  1. Go to ADMIN > Security.
    The Security view is displayed with the Users tab open.
  2. Click the Settings tab.
  3. Under PAM Authentication, select Enable PAM Authentication.
    Image of PAM Authentication and Active Directory Configurations portions of the Settings Tab
  4. Under PAM Authentication options, click Test.
    The PAM Authentication Test dialog is displayed.
    Image of the PAM Authentication Test dialog, requesting a Username and Password
  5. Type a user name and password that you want to test for authentication using the current PAM configuration.
  6. Click Test.
    The external authentication method is tested to ensure connectivity.
  7. If the test does not succeed, review and edit the configuration.

PAM is enabled, and Active Directory configurations will also remain enabled. PAM configurations are automatically populated in the External Group Mapping tab so that you can map security roles to each group. To configure security roles used for PAM access, see Step 5. (Optional) Map User Roles to External Groups.

You are here
Table of Contents > Set Up System Security > Step 4. (Optional) Configure External Authentication > Configure PAM Login Capability

Attachments

    Outcomes