2. jpasswd A common password change client for Unix and NT Marty Wise Jefferson Lab October, 2000

3. 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

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

5. Other Services using NIS or NT Authentication Cisco RAS login (currently NT, NIS avail.) Apache Web Servers (NIS) MS IIS Web Servers (NT)

6. Services using Standalone Authentication Netscape Calendar Server Apache Web Servers – some applications use local.htpasswd files.

7. Why? Reduce helpdesk calls resulting from user confusion over “which password goes where?” Improve overall security through better password management. Enforce password rules

8. “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.

9. 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.

10. 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

11. 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.

12. 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

13. 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

14. 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.

15. MySQL DB CR Server Dispatcher Master Controller NIS Agent NT Agent NT Agent Web server client Web client Jpasswd System

16. 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

17. Database MySQL is used MySQL security disallows changes from other nodes. MySQL connection authentication is therefore on a single machine.

18. 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.

19. 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.

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

21. 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.

22. 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.

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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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.