Wiki code for Sparks: name service switch/nscd enhancements

Hide Line numbers
1: == Sparks Status
2: 
3: == Recent News
4: 
5: === Documentation page updated with permanent links to both sections.
6: 
7: === Setting Up OpenDS 1.0.0 as a Naming Service for the OpenSolaris OS, Part 2 of 2: Advanced Configurations
8: 
9: The following is the second part of an excellent two part blog entry,
10: from the OpenDS team, detailing
11: the steps to setting up an OpenDS server on OpenSolaris.
12: 
13: [[http://developers.sun.com/identity/reference/techart/opends-namesvcs2.html>>http://developers.sun.com/identity/reference/techart/opends-namesvcs2.html]]
14: 
15: === Setting Up OpenDS 1.0.0 as a Naming Service for the OpenSolaris OS, Part 1 of 2: Basic Steps
16: 
17: The following is an excellent blog entry from the OpenDS team detailing
18: the steps to setting up an OpenDS server on OpenSolaris.
19: 
20: [[http://developers.sun.com/identity/reference/techart/opends-namesvcs.html>>http://developers.sun.com/identity/reference/techart/opends-namesvcs.html]]
21: 
22: We’re looking forward to part 2!
23: 
24: === Duckwater Standalone Enhancements in snv_93
25: 
26: The Duckwater (phase 0) standalone tools improvements, as well as a
27: number of improvements in connection management were delivered in snv_93.
28: 
29: Details on the Duckwater standalone changes can be found here:
30: [[http://www.opensolaris.org/os/project/duckwater/duckwater_phase0/>>Project duckwater.duckwater_phase0]]
31: 
32: === BigAdmin Solaris LDAP/Active Directory Document Now Available
33: 
34: The document
35:  [[Using Kerberos to Authenticate a Solaris 10 OS LDAP Client With Microsoft Active Directory>>http://www.sun.com/bigadmin/features/articles/kerberos_s10.jsp]]
36: is now available on BigAdmin at:
37: 
38: [[http://www.sun.com/bigadmin/features/articles/kerberos_s10.jsp>>http://www.sun.com/bigadmin/features/articles/kerberos_s10.jsp]]
39: 
40: This document describes step by step, how to setup Active Directory, Kerberos
41: and per-user (self) authentication from Sparks, so that a Solaris machine can
42: run natively in an Active Directory Environment using Active Directory style
43: secure authentication (Kerberos).
44: The document is written from the point of view of a Solaris 10 deployment,
45: but it applies equally to Nevada as well.
46: This is a great paper to read.
47: 
48: == Older News
49: 
50: === Sparks phase 1 was delivered into snv_50 and s10u4
51: 
52: The first sparks delivery has been integrated into the 50th build
53: of Solaris Nevada.
54: 
55: It was also back ported and delivered into Solaris 10 update 4.
56: 
57: Sparks in it’s current form is part of the current ON (OS/Net) Consolidation [[found here>>http://dlc.sun.com/osol/on/downloads/current]]
58: 
59: == Introduction
60: 
61: The Sparks project plans to make upward compatible changes to the name
62: service switch and to nscd(1M) in order to deliver new functionality including:
63: 
64: 
65: * Better caching in nscd(1M) and management of connections within the
66: updated framework.
67: * 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.
68: * A framework for the future addition of putXbyY interfaces.
69: 
70: This project also plans to fix many of the outstanding approachability bugs,
71: RFEs and known problems in the existing switch code including the hard coded
72: internal buffer length limitations, such as hosts and groups, the multithreading performance issues, etc.
73: 
74: Why Sparks? [[1>>http://www.nevadaweb.com/cnt/r-t/sparks/index.html]] [[2>>http://cprr.org/Museum/Unknowns/Sparks_NE_Roundhouse.html]]
75: 
76: == Nsswitch Approachability Issues
77: 
78: The impetus for the sparks project stems from a review, about a year ago,
79: of the hundreds of outstanding bugs and RFE requests from customers that
80: have accumulated over the last 10-15 years, input we were receiving from
81: internal and customer deployments of LDAP naming services, the announcement
82: that we made to EOL NIS+ and an analysis of Active Directory features.
83: 
84: From this we assembled a list of high level approachability issues that include:
85: 
86: * Security - The switch is not secure by default, and not very secure in general.
87: * Caching - nscd caches a subset of {pw,gr,host,attr} only
88: * Scalable buffering - Internal fixed sized buffers cause scalability issues
89: * MT Scalability - The nsswitch is not MT hot and has fixed operational limits
90: * Write Capability - There is no write capability, password changing is ad-hoc
91: * Interoperability -  We need to extend beyond basic “UNIX/Linux” interop
92: * Auto-configuration - is needed including DNS SRV and NWAM support
93: * Start addressing the RFEs - There are about ~150 active RFEs... +bugs
94: 
95: We translated this into the following high level naming service requirements.
96: Naming services needs to:
97: 
98: * Respond to system changes w/o requiring reboot, and be able to work properly with smf, nwam, etc.
99: * Improve Security/Interoperability
100:  * Use Kerberos {SASL/GSS}
101:  * Enable secure User & Host credentialed authentication to DS
102:  * Support Active Directory Schema {as applicable}
103: * Work on Approachability
104:  * Fix/obsolete the {plethora of} divergent tools story {ypinit, nisinit, ldapclient versus one tool, ypmake, nisaddent, ldapaddnet versus one tool, etc.}
105:  * Move towards obsoleting older APIs {IE embrace smf, move away from vi’ing nsswitch.conf}
106:  * Fix or address all the RFEs and the bugs.
107:  * Document the switch, and expose the APIs to 3rd parties.
108: 
109: == Nsswitch As It Exists Today
110: 
111: The design of the name service switch, sometimes known as nsswitch or just "the switch", is based on early 90’s technology 
112: (It was the 18th ARC case {PSARC/1991/018} with nscd being added
113: in 1994 {PSARC/1994/391}.
114: It has had modifications to, but no significant retooling “of” since
115: that time. The initial design was geared towards single cpu, workstations
116: that people today would generally consider today as being low memory
117: configurations.  Those systems with 16MB, 32MB, or a whopping 64MB RAM.
118: The nsswitch is not MT hot, or secure by todays standards.
119: The nsswitch is not smf, boot, install, user, administrator or configuration
120: friendly.  There is very little internal or external documentation, the only public documentation being the various manual pages and administrator guide sections.
121: 
122: 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.
123: 
124: This OpenSolaris project plans to change all that.
125: 
126: The following is an overview diagram of the nsswitch, as it exists in Solaris 10 and earlier.
127: 
128: [[image:Project sparks.WebHome@nsswitchs10.png||alt="Nsswitch as it exists in Solaris 10 and earlier"]]
129: 
130: Every application that links with libc, and/or uses a getXbyY API
131: will have an instance of the switch activated.  A small set of getXbyY
132: APIs make requests of NSCD, which uses it’s instance of the switch
133: to fetch results, populate caches and then NSCD returns results.
134: 
135: The remaining getXbyY APIs are processed locally in each and every applications nsswitch policy engine.  More on this later.
136: 
137: == Nsswitch As Viewed by Sparks
138: 
139: The Key changes to the switch planned by the Sparks project are as follows:
140: * All XbyYs performed by centralized nscd switch
141:  * Nscd switch is MT hot
142:  * More robust caching and Caching of all DBs
143:  * Managed Connections
144:  * PutXbyY framework  using a new, generic, app<->nscd door interface
145:  * Holistic config, no more reboots, smf integrated
146: * Nscd manages per-user lookups (if enabled)
147:  * Manages user/host principles uses forker & sub procs for actual per-user separation of work
148:  * Supports nss_ad backend when delivered
149: 
150: The following is an overview diagram of "Sparks" nsswitch as we see the design at this point in time:
151: 
152: [[image:Project sparks.WebHome@nsswitchsparks.png||alt="Nsswitch w/Sparks"]]
OpenSolaris

Top Menu

Wiki code for Sparks: name service switch/nscd enhancements

Search

Collectives

Community Group

Project

User Group

Subsites

Project sparks Pages
