Sparks: name service switch/nscd enhancements at OpenSolaris.org

You are not signed in. or register.

OpenSolaris Project: Sparks: name service switch/nscd enhancements

View the leaders for this project
Project Observers

Endorsing communities

OS/Net (ON)
Security

Sparks Status

BigAdmin Solaris LDAP/Active Directory Document Now Available

The document Using Kerberos to Authenticate a Solaris 10 OS LDAP Client With Microsoft Active Directory is now available on BigAdmin at:

http://www.sun.com/bigadmin/features/articles/kerberos_s10.jsp

This document describes step by step, how to setup Active Directory, Kerberos and per-user (self) authentication from Sparks, so that a Solaris machine can run natively in an Active Directory Environment using Active Directory style secure authentication (Kerberos). The document is written from the point of view of a Solaris 10 deployment, but it applies equally to Nevada as well. This is a great paper to read.

Prototype Versioning nscd – snv_83

The sparks Mercurial gate has been updated to include changes to support the initial versioning API as described in more detail here:

http://www.opensolaris.org/os/project/duckwater/Documentation/nssversion/

An updated nscd, with support for this interface was delivered in build 83 (snv_83).

Sparks phase 2 ramping up

The system has been stable for some time, and as of snv_80 phase 2 work is starting to ramp up. More information soon.

A new Mercurial gate has been setup and phase 2 work will progress in that gate until the phase 2 work is delivered into the Nevada tree.

Sparks phase 1 was delivered into snv_50 and s10u4

The first sparks delivery has been integrated into the 50th build of Solaris Nevada.

It was also back ported and delivered into Solaris 10 update 4.

Sparks in it's current form is part of the current ON (OS/Net) Consolidation found here

Introduction

The Sparks project plans to make upward compatible changes to the name service switch and to nscd(1M) in order to deliver new functionality including:

Better caching in nscd(1M) and management of connections within theupdated framework.
Name service lookups that are access controlled at the naming service on a per-user basis. The updated the switch framework will add support for this style of lookups using SASL/GSS/Kerberos in a manner that is compatible with the authentication model used in MS Active Directory.
A framework for the future addition of putXbyY interfaces.

This project also plans to fix many of the outstanding approachability bugs, RFEs and known problems in the existing switch code including the hard coded internal buffer length limitations, such as hosts and groups, the multithreading performance issues, etc.

Why Sparks? 1 2

Nsswitch Approachability Issues

The impetus for the sparks project stems from a review, about a year ago, of the hundreds of outstanding bugs and RFE requests from customers that have accumulated over the last 10-15 years, input we were receiving from internal and customer deployments of LDAP naming services, the announcement that we made to EOL NIS+ and an analysis of Active Directory features.

From this we assembled a list of high level approachability issues that include:

Security – The switch is not secure by default, and not very secure in general.
Caching – nscd caches a subset of {pw,gr,host,attr} only
Scalable buffering – Internal fixed sized buffers cause scalability issues
MT Scalability – The nsswitch is not MT hot and has fixed operational limits
Write Capability – There is no write capability, password changing is ad-hoc
Interoperability – We need to extend beyond basic “UNIX/Linux” interop
Auto-configuration – is needed including DNS SRV and NWAM support
Start addressing the RFEs – There are about ~150 active RFEs… +bugs

We translated this into the following high level naming service requirements. Naming services needs to:

Respond to system changes w/o requiring reboot, and be able to work properly with smf, nwam, etc.
Improve Security/Interoperability
- Use Kerberos {SASL/GSS}
- Enable secure User & Host credentialed authentication to DS
- Support Active Directory Schema {as applicable}
Work on Approachability
- Fix/obsolete the {plethora of} divergent tools story {ypinit, nisinit, ldapclient versus one tool, ypmake, nisaddent, ldapaddnet versus one tool, etc.}
- Move towards obsoleting older APIs {IE embrace smf, move away from vi'ing nsswitch.conf}
- Fix or address all the RFEs and the bugs.
- Document the switch, and expose the APIs to 3rd parties.

Nsswitch As It Exists Today

The design of the name service switch, sometimes known as nsswitch or just "the switch", is based on early 90's technology (It was the 18th ARC case {PSARC/1991/018} with nscd being added in 1994 {PSARC/1994/391}. It has had modifications to, but no significant retooling “of” since that time. The initial design was geared towards single cpu, workstations that people today would generally consider today as being low memory configurations. Those systems with 16MB, 32MB, or a whopping 64MB RAM. The nsswitch is not MT hot, or secure by todays standards. The nsswitch is not smf, boot, install, user, administrator or configuration friendly. There is very little internal or external documentation, the only public documentation being the various manual pages and administrator guide sections.

And finally, all the switch interfaces below the public getXbyY APIs, including all the backend interfaces have always been considered by Sun to be project private or at best consolidation private interfaces. This means that Sun has never guaranteed, although it has practiced, nsswitch backend compatbility between any release. And Sun has never guaranteed support for 3rd party or Open Source products written to these interfaces.

This OpenSolaris project plans to change all that.

The following is an overview diagram of the nsswitch, as it exists in Solaris 10 and earlier.

Nsswitch as it exists in Solaris 10 and earlier

Every application that links with libc, and/or uses a getXbyY API will have an instance of the switch activated. A small set of getXbyY APIs make requests of NSCD, which uses it's instance of the switch to fetch results, populate caches and then NSCD returns results.

The remaining getXbyY APIs are processed locally in each and every applications nsswitch policy engine. More on this later.

Nsswitch As Viewed by Sparks

The Key changes to the switch planned by the Sparks project are as follows:

All XbyYs performed by centralized nscd switch
- Nscd switch is MT hot
- More robust caching and Caching of all DBs
- Managed Connections
- PutXbyY framework using a new, generic, app<->nscd door interface
- Holistic config, no more reboots, smf integrated
Nscd manages per-user lookups (if enabled)
- Manages user/host principles uses forker & sub procs for actual per-user separation of work
- Supports nss_ad backend when delivered

The following is an overview diagram of "Sparks" nsswitch as we see the design at this point in time:

Nsswitch w/Sparks

Announcements

02 Aug 2006	Sparks Beta now available
02 Aug 2006	Sparks code review now in progress
30 Jun 2006	Sparks Alpha Release now available

OpenSolaris