OpenSolaris

  subsites   code review   repo   packages   bugs   defect   polls   planet
You are not signed in. Sign 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

Recent News

Documentation page updated with permanent links to both sections.

Setting Up OpenDS 1.0.0 as a Naming Service for the OpenSolaris OS, Part 2 of 2: Advanced Configurations

The following is the second part of an excellent two part blog entry, from the OpenDS team, detailing the steps to setting up an OpenDS server on OpenSolaris.

http://developers.sun.com/identity/reference/techart/opends-namesvcs2.html

Setting Up OpenDS 1.0.0 as a Naming Service for the OpenSolaris OS, Part 1 of 2: Basic Steps

The following is an excellent blog entry from the OpenDS team detailing the steps to setting up an OpenDS server on OpenSolaris.

http://developers.sun.com/identity/reference/techart/opends-namesvcs.html

We're looking forward to part 2!

Duckwater Standalone Enhancements in snv_93

The Duckwater (phase 0) standalone tools improvements, as well as a number of improvements in connection management were delivered in snv_93.

Details on the Duckwater standalone changes can be found here: http://www.opensolaris.org/os/project/duckwater/duckwater_phase0/

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.

Older News

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

Blogs

baban - Solaris 10 and Active Directory

Mar 25, 4:53 PM

We've a new bigadmin article that describes how to integrate a Solaris 10 08/07 OS client with Microsoft's Active Directory using Kerberos and LDAP. I wrote this article along with Wajih Ahmed (also ...

Doug Leavitt - Sparks alpha release now available

Jun 30, 12:33 PM

Just letting everyone know, the first Sparks project OpenSolaris delivery is now available on the sparks project website: http://www.opensolaris.org/os/project/sparks The bfu's, sources and details ...

Baban Kenkre - Winchester (Solaris and Active Directory Interoperability) now live

Apr 26, 9:38 AM

The Winchester project (Schema mapping and ID mapping for AD Interoperability) is now live. We have an overview of the project in the Architecture page (work in progress). There will be more material ...

Baban Kenkre - PAM, Name Service and Active Directory Interoperability

Apr 17, 11:38 PM

We have announced various projects that address PAM (Pluggable Authentication Modules) enhancements, Name Service enhancements, Simplified Management tools and Active Directory Interoperability on ...

Doug Leavitt - Sparks/Reno/Duckwater/Winchester inter project overview

Apr 17, 2:05 PM

The Sparks, Reno, Duckwater and Winchester OpenSolaris projects are working to tackle multiple approachability, interoperability, security and performance issues that exist in Solaris naming services ...