Sec/User Mgmt: Configure PAM Login Capability

Document created by RSA Information Design and Development on Mar 23, 2017Last modified by RSA Information Design and Development on Apr 7, 2017
Version 2Show Document
  • View in full screen mode
  

This topic explains how to configure Security Analytics 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 Security Analytics without having an internal Security Analytics account, and to receive permissions or roles determined by mapping the external group to a Security Analytics 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 are Active Directory, RADIUS, 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. Security Analytics 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 operating system (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. Security Analytics 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. Security Analytics  compares the results of the request to the Security Analytics External Group Mapping and if a matching group is found, the user is granted access to log on to SA 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 Security Analytics. 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.

Note: For pre-10.4 services that use untrusted connections, all PAM users must also be configured in all Security Analytics Core services, and PAM needs to be configured on every EL6 Core host.  While this document does not address configuring PAM Authentication and Users for Core services, such as Decoder and Concentrator, the steps for configuring the PAM module are the same, except that the Security Analytics Core services use a different PAM configuration file, /etc/pam.d/netwitness.

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 Security Analytics Server.
  4. Create group mappings in Security Analytics Server.

Prerequisites

This feature is only available for EL6 based Security Analytics Version 10.4 or later.

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.

If you purchased a new host with Security Analytics 10.4 or later installed, the required rpm packages for Kerberos, LDAP, RADIUS, and Samba are installed by default.

Before beginning setup of PAM in Security Analytics, identify the group names that you will use in the External Group mapping. When mapping roles, the role in Security Analytics 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

Note: If Security Analytics Server and Security Analytics Malware Analysis share the same server, once you setup the PAM Kerberos, the Malware Analysis Samba (SMB) configuration will be disabled.

To configure PAM authentication using Kerberos:

  1. If you upgraded to Security Analytics 10.6, execute the following command, otherwise skip this step:
    yum --enablerepo=nwupdates 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.

    [libdefaults]
    default_realm = <DOMAIN.COM>
    dns_lookup_realm = true
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

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

    [domain_realm]
    <domain.com> = <DOMAIN.COM>
    <.domain.com> = <DOMAIN.COM>

    [appdefaults]
    pam = {
       debug = true    ticket_lifetime = 36000
        renew_lifetime = 36000
       forwardable = true
       krb4_convert = false
      }
  3. Test the Kerberos configuration with the command: 
    kinit <user>@<DOMAIN.COM>
    No output after entering the password indicates success.
  4. Edit the Security Analytics 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. If you upgraded to Security Analytics 10.6, execute the following command, otherwise skip this step:
    yum --enablerepo=nwupdates install openldap-clients
  2. Edit the LDAP configuration files, /etc/pam_ldap.conf and /etc/openldap/ldap.conf as shown in the following examples

Note: The two LDAP configuration files serve different purposes. The pam_ldap.conf file is used by the PAM Module only. The openldap/ldap.conf file is used by the openldap client tools, such as ldapsearch, which is used for troubleshooting the basic LDAP communications. Replace variables, which are delimited by <angle brackets>, with your values and omitting the angle brackets. Capitalization is required where shown.

Sample /etc/pam_ldap.conf file entries

base <dc=domain,dc=com>
uri ldap://<server.domain.com>
binddn <binduser@domain.com>
bindpw <secret>

nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User

Sample /etc/openldap/ldap.conf file entries

URI ldap://<server.domain.com>
BASE <DC=domain,DC=com>
TLS_CACERTDIR /etc/openldap/certs

  1. (Optional) To enable secure transport for LDAP communication with peer certificate verification (more secure), add the lines shown below to /etc/pam_ldap.conf and /etc/openldap/ldap.conf:
    Lines to add to /etc/pam_ldap.conf:
    ssl start_tls
    tls_cacertfile /etc/openldap/certs/myca.pem


    Lines to add to /etc/openldap/ldap.conf:
    ssl start_tls
    tls_cacert /etc/openldap/certs/myca.pem

    myca.pem
    is a file that contains a base64-encoded PEM-format x.509 certificate for the root CA (not the issuing CA) of the certificate chain that issued the domain controller’s secure LDAP certificate. Contact your Active Directory administrator to obtain this root CA certificate. The certificate file must be in PEM format.

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 add the lines shown below to /etc/pam_ldap.conf and /etc/openldap/ldap.conf:
    Lines to add to /etc/pam_ldap.conf
    ssl start_tls
    tls_reqcert never


    Lines to add to /etc/openldap/ldap.conf
    ssl start_tls
    tls_checkpeer no
  2. To test the LDAP configuration, enter the following command:
    ldapsearch -x -D <user>@<domain.com> -W
  3. To perform an advanced test or to troubleshoot your bind user, connect as your Bind User (example Mike Cool) and search for the user, see what the user's distinguished name (DN) is and use that value as the binddn in pam_ldap.conf, for example:
    1. ldapsearch -b "dc=domain,dc=com" -D mcool@domain.com -h server.domain.com -W "(cn=Cool*)" |grep Cool
      The grep will hide the password prompt (-W)
    2. Type the password and press ENTER.
  4. Edit the Security Analytics 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 Security Analytics Server to your RADIUS Server’s Client list and configure a shared secret. For instructions, see Add a RADIUS Client and Associated Agent.

To configure PAM authentication for RADIUS using LDAP:

  1. If you upgraded to Security Analytics 10.6, execute the following command, otherwise skip this step:
    yum --enablerepo=nwupdates install pam_radius_auth
  2. Edit the RADIUS configuration file, /etc/raddb/server as follows:
    # server[:port] shared_secret  timeout (s)
    server          secret         3
  3. Edit the Security Analytics 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

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 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. If you upgraded to Security Analytics 10.6, execute the following command to check if the PAM RADIUS package is installed:

    rpm -qa | grep pam_radius_auth

    Example: [root@ ~]# rpm -qa | grep pam_radius_auth

             pam_radius_auth-1.3.17-1.x86_64

    [root@ ~]#

    If the pam_radius_auth package is not available then use the following command to install the required PAM RADIUS package:

    yum --enablerepo=nwupdates install pam_radius_auth

  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 Security Analytics 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.

  3. In RADIUS Client Settings, provide the following information:
    1. In the Client Name field, enter the name of the client, for example, SECURITY ANALYTICS.

    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.

  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. All Security Analytics core services in the deployment must be running at a minimum version 10.4.0. Security Analytics 10.3.x or earlier is not supported.
  2. Trusted connections must be enabled and functioning between Security Analytics and Security Analytics 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 Security Analytics 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 Security Analytics.
  • Configure group mappings in Security Analytics server.

To configure Authentication Manager:

  1. Log on to RSA Authentication Manager.
    The Security Console is displayed.
  2. In the Security Console, add a new authentication agent.
    Click Access > Authentication Agents > Add New.
    The Add New Authentication Agent page is displayed.
  3. In the Hostname field, type the hostname of the Security Analytics server.
  4. Click Resolve IP.
    The IP address of the Security Analytics server is automatically displayed in the IP Address field.
  5. Keep the default settings and click Save.
  6. Generate a configuration file.
    Click Access > Authentication Agents > Generate Configuration File.
    The Generate Configuration File page is displayed.

  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:

Note: In version 10.4 or later, OVAs and installation ISOs pre-install the SecurID package. If this applies to your environment, skip this procedure.

  1. On the Security Analytics server, make a directory:
    mkdir /var/ace
  2. On the Security Analytics 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 Security Analytics 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 Security Analytics server PAM configuration file, /etc/pam.d/securityanalytics by adding this line:
    auth required pam_securid.so
    If the file does not exist, create it and add this 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: 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 whole path must have -rw------- root root permission.

Note: If the PAM SecurID setup is not complete, it may crash the Jetty server and Security Analytics UI will not be displayed. You must wait till 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/63bit/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,
    Click 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

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 SA 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 SA 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 SA Server console.

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

NSS Samba

Note: If Security Analytics Server and Security Analytics Malware Analysis share the same service, once you setup NSS Samba, the Malware Analysis Samba (SMB) configuration will be disabled.

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 = <SA_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:
    chkconfig winbind on
    service winbind start
  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:
    service winbind stop
    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:
    service winbind start

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

  1. Type service winbind restart.

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 Security Analytics Server Updates Repository if the server is synchronized with SMCUPDATE. This requires a configured Live Account in Security Analytics.
  2. To install the package, do one of the following:
    1. To install directly from SMCUPDATE, enter the following command:
      yum --enablerepo=sa install nss-pam-ldapd
    2. To install from the Security Analytics Updates Repository, enter the following command:
      yum --enablerepo=nwupdates 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:
    #see note in NSS LDAP Communication Ports section for guidance on using ldap:// or ldaps://
    uri ldap://<ldapServerHost>/ 
    base dc=<yourDomain>,dc=<com>
    binddn <ldapBindUser@yourdomain.com>
    bindpw <bindPassword>
    bind_timelimit 30
    timelimit 30
    idle_timelimit 3600
    pagesize 1000
    referrals off
    filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
    map    passwd uid              sAMAccountName
    map    passwd homeDirectory    unixHomeDirectory
    map    passwd gecos            displayName
    filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
    map    shadow uid              sAMAccountName
    map    shadow shadowLastChange pwdLastSet
    filter group  (objectClass=group)
    map    group  uniqueMember     member
    uid nslcd
    gid ldap
  4. (Optional) To enable secure transport for LDAP communication with peer certificate verification (more secure), add these lines to /etc/nslcd.conf:
    ssl start_tls
    tls_cacert /etc/openldap/certs/myca.pem


    myca.pem is a file that contains a base64-encoded PEM-format x.509 certificate for the root CA (not the issuing CA) of the certificate chain that issued the domain controller’s secure LDAP certificate. Contact your Active Directory administrator to obtain this root CA certificate.  The certificate file must be in PEM format.

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 add these lines to /etc/nslcd.conf:
    ssl start_tls
    tls_reqcert never
  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:
    chkconfig nslcd on
    service nslcd start
  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:
    service nslcd stop
  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:
    service nslcd start

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 Security Analytics still fails to allow External users to login:
    • Was the correct group name specified for the NSS group in SA External Group Mapping?  See Enable PAM and Create Group Mappings below.
    • It is possible that the NSS configuration has changed and Security Analytics has not picked up the change.  A reboot of the Security Analytics host will cause Security Analytics to pick up NSS configuration changes.  A restart of jettysrv is not sufficient.

Proceed to the next section, Enable PAM in Security Analytics server.

Enable PAM in Security Analytics Server

  1. Log on to Security Analytics and in the Security Analytics menu, select Administration > Security.
    The Administration Security view is displayed with the Users tab open.
  2. Click the Settings tab.
  3. Under External Authentication, select PAM and click Apply.

PAM is enabled, and Active Directory is automatically disabled. The Active Directory configuration settings are stored and hidden. Perform a test authentication with the PAM configuration, For instructions, see Test External Authentication.

Proceed to the final section, Create Group Mappings in Security Analytics server.

Create Group Mappings in Security Analytics Server

  1. In the Security view, click the External Group Mapping tab.
  2. Click to Add a Role Mapping.
    The Add Role Mapping page is displayed.
  3. Map the external group names to the appropriate Security Analytics roles as described in Step 5. (Optional) Map User Roles to External Groups.
    The external group name and the Security Analytics role name must match.
    For example, Analysts and Analysts but not Analysts and Analyst. 
You are here
Table of Contents > Set Up System Security > Step 4. (Optional Configure External Authentication > Configure PAM Login Capability

Attachments

    Outcomes