JPL Directory and Authentication System Admin Support
The JPL Directory (LDAP) and Authentication (Kerberos) service is available
to provide a reliable and secure source for authentication and authorization
on the JPL.NASA.GOV Shared Services network.
The JPL Directory service includes 3 clusters of LDAP and Kerberos servers that may be used for
LDAP authentication/authorization and Kerberos Single-Sign-On authentication. All servers are
located in institutionally supported server rooms; controlled, monitored, and maintained 24x7x365.
All systems are under JPLIT change management processes including coordination with the MMAPT and
flight freezes.
Each cluster consists of two load balancers and at least two LDAP and Kerberos servers. Clusters include:
- LDAP.JPL.NASA.GOV - Shared services
LDAP and Kerberos servers are also located at a commercial off-site disaster recovery center, Lockheed
Martin IT (Building 605), and Lockheed Martin IT Disaster recover site. Additional servers may be
deployed as needed.
The JPL Directory and Authentication service provides an authentication
service based on identities vetted by JPL Protective Services. This provides Data and Applications
owners the necessary information to:
- Meet export compliance regulations (ITAR, EAR)
- User are identifies as US Person or Foreign Nationals based on citizenship and employment status
- Meet Business restriction regulations
- Employee and affiliate characteristics
- Meet IT Security guidelines
- Password strength, history, expiration notification
- Bad authentication lockout
- Identity traceability and auditability
- Creation of IT Identities synchronized with JPL Windows Domain and NBS
- Timely disabling of identities upon separation from JPL
- Unique user name and UNIX ID number
- Enabling LDAP authentication from workstations
Operating System and Application Protective Measures
The system administrator will configure the user accounts to use only
JPL Directory Service authentication (https://dir.jpl.nasa.gov),
when this service provides the capability for central authentication.
If the operating system cannot achieve compliance using the JPL Directory
and Authentication Service (https://dir.jpl.nasa.gov) the
system administrator will:
- Configure the password for expiration in 13 weeks or 90 days. Where
the operating system does not provide this option, the SA will establish
a manual procedure to ensure that passwords expire in 90 days. For details,
refer to the operating system's or the device's user manual, specific to
the individual version, vendor and model.
- Configure the IT asset to conform to the construction standards and
prohibit passwords that are dictionary words, where this feature is
available. If unavailable, the SA will alert the users to this prohibition.
For details on the specific capabilities of the OS, refer to the operating
system's or the device's user manual, specific to the individual version,
vendor and model.
- Configure the account so that the password may not be reused
before 180 days have elapsed. Where the operating system does not
provide this password history option, the SA will establish a policy
stating that users must not reuse passwords more often than the
requirement allows. For details, refer to the operating system's or
the device's user manual, specific to the individual version, vendor
and model.
- Configure the IT asset to ensure that stored passwords are
encrypted, where this feature does not render the password unusable.
Where stored passwords cannot be encrypted, the SA will configure
the IT asset to restrict access to these files to privileged users.
For details on the specific capabilities of the operating system,
refer to the operating system's or the device's user manual,
specific to the individual version, vendor and model.
- Configure the IT asset to log password change events, and
include the user ID, date, and time, where supported by the
operating system. For details, refer to the operating system's or
the device's user manual, specific to the individual version, vendor
and model.
- Configure the operating system to drop the connection or suspend
the login after ten consecutive unsuccessful login attempts within
15 minutes. For details, refer to the operating system's or the
device's user manual, specific to the individual version, vendor and
model.
- Configure the operating system to drop the connection or suspend
the login after ten consecutive unsuccessful login attempts within
15 minutes. For details, refer to the operating system's or the
device's user manual, specific to the individual version, vendor and
model.
- Ensure that all accounts are secured by a password or two-factor
authentication.
- Configure the operating system to disable or delete user
accounts if the password has not been changed within the requisite
period, where this capability is provided by the operating system.
If the operating system does not provide this capability, the SA
will manually monitor the status of the accounts and disable or
delete as necessary to ensure this requirement is met.
If the application cannot achieve compliance using the JPL Directory and
Authentication Service (
https://dir.jpl.nasa.gov) the
developer will:
- Ensure the stored application passwords are encrypted. Where
possible, the system administrator will verify this stored application
password encryption when hosting the application.
- Configure the application to ensure that the application
will drop the connection or suspend the login after ten consecutive
unsuccessful login attempts within 15 minutes.
Network Access for Privileged Accounts
- Linux RedHat:
All access to privileged accounts including access via privilege
escalation must first require authentication via a unique user account
and Two Factor Authentication mechanism.
To secure a host locally with RSA Securid, the following procedure can
be used:
- Install the PAM_Securid libraries. (See
https://dir.jpl.nasa.gov/tfa/get_started_admin.php)
- Create the securid PAM stack:
/etc/pam.d/securid-auth:
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_securid.so
auth required pam_deny.so
- Edit the PAM files for the relevant services to use the securid-auth
stack for authentication:
/etc/pam.d/su:
...
auth sufficient pam_rootok.so
auth substack securid-auth
auth include postlogin
...
/etc/pam.d/sudo:
...
auth include securid-auth
...
Similar procedures can be followed to implement other TFA modules.
- Mac OS X 10.13:
Additional information regarding two-factor can be found at
https://dir.jpl.nasa.gov/tfa/ .
- Solaris 11:
All access to privileged accounts including access via privilege
escalation must first require authentication via a unique user account
and Two Factor Authentication mechanism.
To secure a host locally with RSA Securid please go to
https://tfa.jpl.nasa.gov/console-selfservice/ .
- Windows Server 2016:
Additional information regarding two-factor can be found at:
https://dir.jpl.nasa.gov/tfa/ .
- Windows 10:
Additional information regarding two-factor can be found at:
https://dir.jpl.nasa.gov/tfa/ .
- Linux Ubuntu:
All access to privileged accounts including access via privilege
escalation must first require authentication via a unique user account
and Two Factor Authentication mechanism.
To secure a host locally with RSA Securid, the following procedure can be used:
- Install the PAM_Securid libraries. (See
https://dir.jpl.nasa.gov/tfa/get_started_admin.php)
- Create the securid PAM stack:
/etc/pam.d/securid-auth:
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_securid.so
auth required pam_deny.so
- Edit the PAM files for the relevant services to use the securid-auth stack for authentication:
/etc/pam.d/su:
...
@include securid-auth
...
/etc/pam.d/sudo:
...
@include securid-auth
...
Similar procedures can be followed to implement other TFA modules.