Tuesday Mar 25, 2008

Solaris 10 and Active Directory

Check out the new bigadmin article written by me and Wajih that describes how to integrate a Solaris 10 08/07 OS client with Microsoft's Active Directory using Kerberos and LDAP. In this article, the Solaris LDAP client uses "per-user authentication (a.k.a. self-credentials)" which means name service related LDAP lookups are performed by binding to AD as the user who is requesting the corresponding information. Prior to Solaris 10 08/07 these lookups were done using a proxy account. The article shows how to configure Solaris as a LDAP client of AD server that uses SFU as well as of AD server that has Identity services for Unix enabled. The article uses a script called adjoin which automates the process of joining Solaris client to a AD domain. This script was originally written for the Winchester project by Nico Williams. Note that this script is a proof-of-technology and not supported by Sun. Without this script you will have to manually configure your Solaris system as a Kerberos client of AD. There is an Opensolaris project which is currently integrating the domain-join functionality from the adjoin script into kclient(1M). See kclientv2.

Wednesday Apr 26, 2006

Winchester (Solaris and Active Directory Interoperability) now live

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 posted in the coming weeks. Our mailing list is sparks-discuss [at] opensolaris [dot] org Please join us and contribute to the discussions.

Monday Apr 17, 2006

PAM, Name Service and Active Directory Interoperability

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

Tuesday Apr 04, 2006

Sparks on OpenSolaris

Today our group released an internal project codenamed sparks on OpenSolaris. Sparks plans to deliver newer functionalities and enhancements to the name service switch and the name service cache daemon. If you would like to contribute, please do so by joining the sparks-discuss mailing list at www.opensolaris.org

Monday Jun 20, 2005

Solaris Native LDAP II client's server list

What is PreferredServerList and DefaultServerList ?
The Solaris Native LDAP II client allows the user to specify a default server list as well as the preferred server list. Both the lists are space-separated list of LDAP server names or IP addresses with the following distinction. The LDAP client sorts DefaultServerList based on the network such that servers on the same subnet as the client have higher priority than those on different subnets. OTOH, for PreferredServerList, the LDAP client uses the same order as specified in the configuration. The LDAP client construct the final server-list as follows.
      If PreferredServerList is specified {
            Add entries from PreferredServerList to server-list;
      If DefaultServerList is specified {
            Sort the DefaultServerList based on network;
            Add entries from the sorted list but not in PreferredServerList to the server-list;

How the list works ?
The list of servers and their status is maintained by the ldap cache manager (ldapcachemgr). The cached server status is updated whenever its refresh TTL expire. The refresh TTL is not constant and is adjusted using an adaptive algorithm. The client library requests a server from the cache manager using door functionality. If the server is not reachable, the client notifies the cache manager. The manager will not return this server on the next request and will also reduce the server's refresh TTL.

Tuesday Jun 14, 2005

Somethings about N2L

Somethings about N2L


NIS to LDAP Migration tool (N2L) provides a migration path from an existing NIS name service to LDAP name service. It is a NIS name service modified to use LDAP server as the repository. The Solaris System Administration Guide contains overview of the service, setup instructions as well as other administrative information. In the following sections I will describe some additional details.

Source code:

Frontend  and Backend 

The frontend consists of modified NIS daemons i.e. ypserv, ypxfrd, and rpc.yppasswdd. The backend consists of the parser, shim, mapping unit and the LDAP-access module, all implemented within the libnisdb.so library. The parser parses the mapping and configuration files, shim intercepts NIS client requests, mapping unit performs NIS/LDAP data conversion and LDAP-access module performs LDAP specific operations.

N2L maintains local cache of LDAP data in the form of ndbm maps with configurable Time To Live (TTL) values. NIS clients are served using the cached data and the cache is refreshed when the TTLs expire. There are two types of TTLs, viz. per-entry TTLs to refresh individual entries and per-map TTLs for entire map. The initial TTL values are chosen randomly from a configurable range to prevent different maps from expiring at the same time.

How the service works ?

The following examples describes the procedure followed by the N2L server in response to various client requests.

Example 1:
  ypcat hosts.byname

N2L server follows the following algorithm to handle client request for an entire map
	if ( map-TTL for hosts.byname cache expired && hosts.byname cache refresh not in progress) {
		set hosts.byname cache refresh flag
		initiate hosts.byname cache refresh thread in the background.
		return data from old hosts.byname cache
		/\* subsequent calls will return refreshed data \*/
	} else {
		return data from current hosts.byname cache

The refresh thread collects the new data in a temporary map. After a successfull download, the data is moved to the hosts.byname cache. The refresh time depends on variable factors such as the network traffic, load on the LDAP server, indexing of LDAP data, load on the N2L server and the number of entries that needs to be transferred. Hence, instead of waiting for the cache refresh thread to complete, N2L returns stale data to prevent blocking of the client request. All client requests for hosts.byname that coincide with the refresh will receive stale data. All client requests after the refresh completes, will get the refreshed data.

Example 2:  ypmatch myhost hosts.byname

N2L server follows the following algorithm to handle client request for a specific entry.
	if (entry "key=myhost" found in hosts.byname cache) {
		if (entry-TTL for entry "key=myhost" expired && hosts.byname cache refresh not in progress) {
			refresh the entry "key=myhost" from LDAP
			if (no such entry exists in LDAP) {
				delete the entry from hosts.byname cache
				return no entry found
			} else {
				return refreshed entry
		} else {
			return entry from the cache
	} else { /\* entry not found in cache \*/
		if (map-TTL for hosts.byname cache expired && hosts.byname cache refresh not in progress) {
			set hosts.byname cache refresh flag
			initiate hosts.byname cache refresh thread in the background
			return no entry found
			/\* subsequent calls will return refreshed data \*/
		} else {
			return no entry found

During the refresh if multiple LDAP entries matches the given NIS key, then only the first match will be used. Note that, unlike map refresh, single-entry refreshes happen in the foreground and hence the client request will either get the refreshed data or no data. In case of refresh errors, the configuration file specifies the number of retry attempts and if all retries fail whether to return stale cached data or YPERR_YPERR to the client.

Example 3:  yppasswd baban

N2L server follows the following algorithm to handle client request for password change
	get domain list from mapping file (nisLDAPyppasswddDomains)
	if (no domains specified) {
		domain = getdomainname();
	for each domain {
		authenticate user=baban using old password
		update LDAP database for "key=baban"
		update N2L cache for "key=baban" (handles passwd.adjunct)
		push the change to NIS slaves

The default mapping file contains commented entries for C2 security (i.e passwd.adjunct). If C2 security is required, the mapping file needs to be modified accordingly.

How to update NIS slave servers ?

1. Run yppush(1M) on the N2L server to push the N2L maps to the slave servers


2. Run ypxfr(1M) on the slave servers to pull the maps.


3. The tedious part is that the above commands have to be invoked for each map. A simple script as follows can be ran on the N2L server to yppush all maps to slave servers.
	#--------START SCRIPT--------
	if [ -d "/var/yp/$DMN" ]
		for n2lmap in /var/yp/$DMN/LDAP_\*_TTL.dir
			map=`/usr/bin/basename $n2lmap _TTL.dir | cut -c 6-`
			echo yppush -d $DMN $map
			/usr/lib/netsvc/yp/yppush -d $DMN $map
			echo $?
	#---------END SCRIPT---------

Technorati Tag:
Technorati Tag:

Wednesday Jun 08, 2005

Steps to setup SSL for Solaris LDAP client (certutil and openssl)

Directory server side

The following shows how to setup Sun Directory Server 5.2 and Solaris LDAP client for SSL. I have tried to give openssl, certutil, PEM, DER examples (and Directory server console at some places) to achieve the same result.

Latest Info

It has been quite sometime since I wrote this entry. To keep up with the latest changes, I'm adding this section wherein I will add links to recent articles on this topic. Thanks to everyone who have given me valuable feedback.
Bigadmin article on DSEE6.0 and LDAP name service with SSL
Ludovic's blog on Sun Directory server and Advanced Certificate Management
Bigadmin article on how to configure Solaris 8, 9, 10 as LDAP client


myhost.test.sun.com == fully qualified hostname of the Directory server.
/var/mps/serverroot == serverroot for the Directory server.
dc=sun,dc=com == Directory server already setup with this suffix
# openssl is delivered in /usr/sfw/bin on Solaris 10
# Please refer to appropriate manpages for description of various command-line options used below.


DER: a binary format
PEM: base-64 encoded DER format with header and footer
certutil: Default is DER. For PEM, use "-a"
openssl: Default is PEM. For DER, use "-inform DER" and/or "-outform DER"

Create Test CA

1. openssl
# The /usr/sfw/bin/CA.pl script will create a directory structure either under the current working directory or under /etc/sfw/openssl depending upon the version of openssl you are using. I suggest checking the value of CATOP variable in /usr/sfw/bin/CA.pl.
If you want to create CA under /CA/cacertdb :
mkdir -p /CA/cacertdb; cd /CA/cacertdb
Modify CATOP in /usr/sfw/bin/CA.pl to /CA/cacertdb
Modify dir under [ CA_default ] in /etc/sfw/openssl/openssl.cnf to /CA/cacertdb
perl /usr/sfw/bin/CA.pl -newca
# Default name for CA cert is "cacert.pem"

2. certutil
# Create CA certificate DB
mkdir -p /CA/cacertdb
certutil -N -d /CA/cacertdb -P "ca-"
# Create a self-signed CA certificate
certutil -S -x -n "ca-cert" -s "cn=CA Certificate certutil,ou=TEST,o=Sun Microsystems Inc.,l=Menlo Park,st=CA,c=US" -t CTPu -v 120 -d /CA/cacertdb -P "ca-" -5
# when prompted, select (5) SSL CA and 'y' for critical extensions
# Export the CA cert into an output file in PEM format
certutil -L -d /CA/cacertdb -P "ca-" -n "ca-cert" -a > cacert.pem

Create NSS DB for Directory server

1. Console
Use the Directory server console => Manage Certificates. The DB is created when trying to use any of the certificate functions for the first time. With the new DS6.0 directory server, the NSS DB will be created when creating the server instance so this step won't be necessary

2. certutil
certutil -N -d /var/mps/serverroot/alias -P "slapd-myhost-"
# Remember the password you have given

Generate Certificate Signing Request (CSR) for server cert

1. Console
Use the Directory server console => Manage Certificates to generate CSR and save it to a file

2. certutil
certutil -R -s "cn=myhost.test.sun.com,ou=TEST,o=Sun Microsystems Inc.,l=Menlo Park,st=CA,c=US" -o DER.csr -d /var/mps/serverroot/alias -P slapd-myhost-"

3. openssl
# Generate 2048-bit RSA private key
openssl genrsa -out privkey.pem 2048
# OR Generate 2048-bit DSA private key
openssl dsaparam -out DSAparam.pem 2048
openssl gendsa -out privkey.pem DSAparam.pem
# Generate the certificate request
openssl req -new -key privkey.pem -out PEM.csr
# Display the content and public key from the certificate request
openssl req -in PEM.csr -text -pubkey

Sign CSR using Test CA

1. certutil
# Sign DER CSR
certutil -C -c "ca-cert" -i DER.csr -o ./cert.der -v 12 -d /CA/cacertdb -P "ca-" -5
# Sign PEM CSR
certutil -C -c "ca-cert" -a -i PEM.csr -o ./cert.pem -v 12 -d /CA/cacertdb -P "ca-" -5

2. openssl
openssl ca -policy policy_anything -cert cacert.pem -in PEM.csr -out ./cert.pem

Import signed certs into NSS DB

1. Console
Use Manage Certificates tab to import pem certificates

2. certutil
# Import PEM server cert
certutil -A -a -n "server-cert" -i ./cert.pem -t Pu -d /var/mps/serverroot/alias -P "slapd-myhost-"
# Import DER server cert
certutil -A -n "server-cert" -i ./cert.der -t Pu -d /var/mps/serverroot/alias -P "slapd-myhost-"
# Import PEM CA cert
certutil -A -a -n "ca-cert" -i cacert.pem -t CT -d /var/mps/serverroot/alias -P "slapd-myhost-"
# List the contents
certutil -L -d /var/mps/serverroot/alias -P "slapd-myhost-"
# List the contents of a specific cert
certutil -L -d /var/mps/serverroot/alias -P "slapd-myhost-" -n "server-cert"

3. openssl
# Import openssl certificates/keys into NSS DB. Convert cert, key and CA cert into pkcs12 format
openssl pkcs12 -export -in cert.pem -inkey privkey.pem -certfile cacert.pem -name "MY CERTIFICATE" -out mycert.p12
# Import it into NSS DB
pk12util -i mycert.p12 -d /var/mps/serverroot/alias -P "slapd-myhost-" -v

Enable SSL

1. Console.
# From Configuration tab, select Encryption.
# Select "Enable SSL for this server"
# Select "Use this cipher family"
# Select Certificate
# Select "Do not allow client authentication" OR "Allow client authentication" but NOT "Require client authentication"
# Save and Restart the directory server from command line. You will be prompted for "Enter PIN for Internal (Software) Token"

# For automatic startup of SSL, add NSS DB password to the following file
cd /var/mps/serverroot/alias
vi slapd-myhost-pin.txt
Internal (Software) Token:your-NSSDB-password-here
chmod 400 slapd-myhost-pin.txt
directoryserver stop
directoryserver start

Run idsconfig

# Assume: Naming Base DN: "dc=test,dc=sun,dc=com"      Domain: "test.sun.com"
# When prompted for Authentication Methods, choose atleast one that starts with "tls:"
# Choose appropriate name for the profile (say tls-profile). The default name is "default".

Solaris Native LDAP client side

# Create NSS DB (Don't enter password. Just hit return)
certutil -N -d /var/ldap
chmod 444 /var/ldap/\*
# Download the Test CA certificate on the client machine into a temporary location. Ex: /var/tmp/cacert.pem
# Add CA certificate to the NSS DB
certutil -A -n "ca-cert" -i /var/tmp/cacert.pem -a -t CT -d /var/ldap
# Verify that "myhost" is fully qualified. Else modify /etc/hosts (and if necessary /etc/nssswitch.conf)
getent hosts myhost.test.sun.com
# Test with ldapsearch
ldapsearch -v -h myhost.test.sun.com -p 636 -Z -P /var/ldap/cert8.db -b "dc=sun,dc=com" -s base "objectclass=\*"
# Initialize Native LDAP client using profile "tls-profile".
/usr/sbin/ldapclient init -a profileName=tls-profile -a domainname=test.sun.com -a proxyDN=cn=proxyagent,ou=profile,dc=test,dc=sun,dc=com -a proxyPassword=proxy

Monday May 09, 2005

Hello World

Hello World, I have been with Sun as a software engineer for almost 5 years. Till recently, I was member of the Solaris Networking and Security group focusing primarily on Naming, Directory and Security services. Now I am member of the KISS (Keep It Simple Solaris) group and the name says it all. I'll keep posting more on the technologies I work (or worked) on so stay tuned.



« July 2016