jpasswdA common password change

client for Unix and NT

Marty Wise

Jefferson Lab

October, 2000

Authentication Environment

• Mix of Unix and NT desktop and Server systems– Unix login integrated via NIS– NT Login integrated via NT DCs

• Various other services use either NIS or NT

• A FEW others have independent authentication services

Global UIDs For NIS

When NIS was configured several years ago, we instituted a policy of registering and synchronizing account ids across all systems.

Other Services using NIS or NT Authentication

• Cisco RAS login (currently NT, NIS avail.)

• Apache Web Servers (NIS)

• MS IIS Web Servers (NT)

Services using Standalone Authentication

• Netscape Calendar Server

• Apache Web Servers – some applications use local .htpasswd files.

Why?

• Reduce helpdesk calls resulting from user confusion over “which password goes where?”

• Improve overall security through better password management.

• Enforce password rules

“Catch-22”

• Users could have NIS-only, NT-only, or accounts on both systems.

• NIS-only users could not do RAS since it was NT driven.

• A “Both” user who didn’t have easy access to an NT system could not change their passwords.

• Password aging on NT eventually locked them out.

Commercial Products

• Commercial products were reviewed and considered initially.

• One product seemed useful – SyNTUnix – now defunct.

• Commercial tools either too expensive/complex, or didn’t offer the right features.

Requirements• Provide a single password change client that

updates both NIS and NT authentication systems.• Provide mechanisms for enforcing site password

selection criteria.• Provides mechanism to enforce site password

history policies.• Provide a means to implement password aging on

Unix

Additional Objectives

• Operation of the site or user environment must not depend on this system.

• Ensure the system is secure, and that security components can be upgraded as technology evolves.

• Develop infrastructure components that can be re-used for other system management applications.

• Build the system so that it can evolve to provide additional user account management features.

Considerations

• Client components must work on Unix, Web

• Agent components must work on Unix and NT

• Central CUE configuration provides simple management of the application

Implementation

• Java is used for almost everything• Small native library

– JNI for console input (password hiding)– JNI for NIS authentication

• Some Perl– Agent scripts to interface to NT admin– Agent scripts for

• PHP For some admin tools

Design Overview• Master Controller

– Receives, authenticate, validate, queues incoming change requests and feeds back to requester.

– Dispatches authenticated “Change Orders” to agent systems.

– Provides full debug and accountability logging for all changes processed by the system.

• Change Request Clients– Issue signed requests for changes to system parameters

(e.g. -- user’s password)

• Agents– Accept Change Orders from a Master Controller and

modifies the host system accordingly.

MySQLDB

CRServer

Dispatcher

MasterController

NISAgent

NTAgent

NTAgent

Webserver

client

client

client

Webclient

Jpasswd System

Master Controller

• A MySQL database is used as a repository for all system data, including logs, etc.

• A server process provides an interface for clients to submit “Change Requests” for action

• A dispatcher is responsible for issuing “Change Orders” to agent systems distributed throughout our CUE environment

Database

• MySQL is used

• MySQL security disallows changes from other nodes.

• MySQL connection authentication is therefore on a single machine.

CR Server

• Multithreaded server allows simultaneous connections from numerous clients, serializes DB accesses and provides record locking function (via MySQL user locks)

• Authentication, Validation, Access Management, etc. all currently provided in the CR server.

• When a request is received, it is reviewed for compliance with site policies. Failures are returned to the requester with corrective information.

Change Requests

• Implemented as serialized java objects• Sensitive data is encrypted using PK

techniques (no shared secrets).• Requesting node is not authenticated.• Signing technique is currently simple

password, hooks for certificate based signing in place. Not appropriate for most client applications due to inadequate PKI.

Dispatcher

• The dispatcher currently polls a DB queue for changes that are pending and issues the appropriate orders to the agent systems.

Change Orders

• Flow from MasterController to Agents.

• Certificate-based session providing authentication.

• Currently 1 CR 1 CO, dispatcher issues the same order to all agents, who act on it depending on content.

Web Server

• An Apache web server is provided on the MC (running SSL and doing NIS auth.)

• Provides a “low budget” management interface until Change-Request-based tools are available.

• Runs a series of PHP scripts to view database, modify config parameters, etc.

Miscellaneous processes

• Various “cron” tasks run on the Master Controller– Nightly audit task – not implemented yet.– Password aging check – not yet implemented

Clients• Unix command line client operates very much like

traditional “passwd” command• Web Server Client

– Based on a Java Servlet – Apache SSL web server– Form-based interface

• The same underlying code is used for both clients• An “admin” mode is available for both that allows

CC staff members to modify other’s passwords

Old (original) Clients

• The original password change clients for both NT and Unix are disabled.

• This forces all changes through the new system

• Unix yppasswdd has been shut down

• NT User accounts are inhibited from changing their own passwords

Agents

• An agent provides an interface to modify the configuration of services running on a given system.

• Currently, 2 agents are needed – – Unix agent (to update NIS)– NT agent (to update NT DCs)

• System allows for redundant agents

Current Status

• System implemented and online for ~2 months – nearly 600 password changes processed.

• Minor finishing up to be done at this point.

• Beginning to transition to development of user account management tools

User Account Management Tools

• An effort is developing to provide additional account management functions –– User enable/disable– Add / Delete / Deactivate User– Unix / NT Group management– Fully automated account request / creation– Filesystem quota management

Conclusions

• Development was lengthened due to learning curve associated with security components.

• The tool has proven quite useful. Help desk calls are expected to decline.

• People hate the password rules – I suspect they hadn’t been following them previously.