1 / 28

jpasswd A common password change client for Unix and NT

jpasswd A 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

jamuna
Download Presentation

jpasswd A common password change client for Unix and NT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. jpasswdA common password change client for Unix and NT Marty Wise Jefferson Lab October, 2000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related