do it. think it. blog it! ... a twisted world

Most of the time, the folks who ask me questions already have gone through sufficient documentation and trial runs, but yet there exists a reluctance in performing the upgrade without a approval signoff from an architect.

Please read the updates at the bottom of this post.

So: to make everybodys life easier, i thought of posting a blog on the as close as possible steps that would be required to perform this upgrade.

Unless one has a humongous NIS / NIS+ infrastructure, the steps in this post followed to the dot should suffice. hopefully after readin this, some organizations may save some consulting dollars... hey !!! mail me a gift certificate with your savings

So, fun aside. here goes...

This blog post is a high level draft of options that one could use to enable native ldap authentication... This may not be 100% accurate, but if and when yu try this out and find out something thats different from whats listed here, please do comment on it... The term user information is not restricted to a users entry containing just his username and password, but rather extended to also contain pertinent information for the LDAP store to serve as a naming services server in conjunction with extenstions to use the data as a authentication source for web applications.

Native LDAP:
For details on the Usage and Guidelines Please refer to http://www.ietf.org/rfc/rfc2307.txt

Any naming system should only have one source of authoritative information. Current naming Services Environments usually use DNS, which uses flatfiles as sources. Under LDAP, the source of authoritative data is the directory, and it is managed using directory management tools. FlatFile sources could be retained for emergency backup or backout only, and they generally should not be used.

This post/blog is a superset of the information contained in the chapter "Naming and Directory Services (DNS, NIS, and LDAP)" of the System Administration Guide (found on the Sun Product Documentation site: http://docs.sun.com). The former presents a relatively simple “cookbook” approach for first time users. This post contains technical detail for the more advanced user.

My plan is to make additions to this post or post more updates as new deployment techniques are discovered.

This Document describes ONLY the following structure.

• Solaris9 Server with SunONE Directory Server 5.2 As the master datasource for naming Services information.
• Solaris8 Clients with LDAP used as the naming services protocol rather than DNS/(local)FlatFiles.

• Install Solaris9 (8/03)-Release using http://docs.sun.com/db/prod/solaris.9u803#hic as a guideline document.
• Setup the LDAP server thats comes bundled with the OS. (v.5.2)
• Ensure that the wrappers for “directoryserver”, “idsconfig” exist on the server.
• Run idsconfig in order to configure the directory server with naming Services Schema and structure.
• Use the root (ie: dc=yourcompany,dc=com) as the base dn for the LDAP server while running idsconfig
• Manually create the naming services required indexes on the LDAP server after stopping the slapd process running on the Solaris9 host.
  1. Indexes need to be executed on all the naming services maps. Please follow the usage for “directoryserver” as prompted after running “idsconfig”
  2. If the server does not have the “directoryserver” wrapper, you could alternatively run the indexes by using / < directory-server-install-root > / slapd-ldapsrv/vlvindex -n userRoot -T yourcompany.com.getgrent etc...

     NOTE:What are a VLV-indexes and why do we need these?
     These indexes are used (and needed) to improve performance when browsing through large tables that contain many objects. i.e. when an enduser on a LDAP-client issues the command "getent hosts", all entries in of ou=Hosts,dc=yourcompany,dc=com become read from the LDAP-server. If a VLV-index for the Hosts-table does exist, the LDAP-client will receive the response very quickly. Please see "Section 10 Managing Indexes in the IDS 5.1 Administrator's Guide" to find further information

• Start the slapd process. (either using the SunONE console or using commandlione tools as documented in the SunONE Directory Server Administration guide)
• The nisDomain attribute must be present in the top entry of the subtree where the NIS maps are stored. Both the LDAP client search base and the name of the NIS domain (serviced by the server) are set to this top entry.
• Check the existence of the nisDomainObject by using the following command
  ldapsearch -b cn=schema objectclass=* | grep nisDomainObject
• The Result should be as follows:
  objectClasses=( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top STRUCTURAL MUST nisDomain X-ORIGIN 'user defined' )
• If you get absolutely no result while running this crosscheck setep You should add the nisDomainObject By doing the following.
  1. The LDIF you use to create the nisDomainObject object varies depending on whether you place the NIS maps at the top of the tree created during the installation, under a separate branch point of that tree, or under a new suffix. The next sections give example LDIF that can be imported to add the nisDomainObject object in each of these scenarios. Even though the attribute is called nisdomain, the client accessing the directory is not using NIS. The name is simply carried over from legacy NIS implementations.
     1. dn: dc=yourcompany, dc=com
     2. changetype: modify
     3. add: objectclass
     4. objectclass: nisDomainObject
     5. -add: nisdomain
     6. nisdomain: yourcompany.com
  2. Note : You do not have to match the value for nisdomain to the DNS domain name, but it is a common practice to do so.

     Client Setup:
     Initialize the Solaris8 Client on the box using:

     • ldapclient -i -D <”PROXYAGENTCN”> -w <PASSWORD> -b <BASEDN> <IPADDRESS of the HOST>
     • This would create a ldap_client_file and a ldap_credential_file on the machine that is now a ldapclient.
     • Verify that the ldap client file has entries that resemble the following:
       
       1. NS_LDAP_FILE_VERSION= 2.0
       2. NS_LDAP_SERVERS= 127.0.0.1"replace this with your IP"
       3. NS_LDAP_SEARCH_BASEDN= dc=yourcompany,dc=com
       4. NS_LDAP_AUTH= simple
       5. NS_LDAP_CACHETTL= 3600
       6. NS_LDAP_CREDENTIAL_LEVEL= anonymous<
       7. NS_LDAP_SERVICE_SEARCH_DESC= group:ou=somecustomgroups,dc=yourcompany,dc=com
       8. NS_LDAP_SERVICE_CRED_LEVEL= pam_ldap:simple
     • Edit the file /etc/nsswitch.conf with the following data source:
       #Use LDAP in conjunction with files
       # "hosts:" and "services:" in this file are used only if the
       # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.
       # the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
       
       1. passwd: ldap [NOTFOUND=return] files
       2. group: ldap files
       3. hosts: ldap [NOTFOUND=return] files
       This value should be changed to dns ldap if the intention is to use dns for name resolutions and hostnames
       
       1. networks: ldap [NOTFOUND=return] files
       2. protocols: ldap [NOTFOUND=return] files
       3. rpc: ldap [NOTFOUND=return] files
       4. ethers: ldap [NOTFOUND=return] files
       5. netmasks: ldap [NOTFOUND=return] files
       6. bootparams: ldap [NOTFOUND=return] files
       7. publickey: ldap [NOTFOUND=return] files
       8. netgroup: ldap
       9. automount: files ldap
       10. aliases: files ldap
       # for efficient getservbyname() avoid ldap
       1. services: files ldap
       2. sendmailvars: files
     • You need to use ldapaddent to create entries in the LDAP containers for all of the standard system databases stored in files under the /etc directory. You need to transfer the following Solaris databases:
       1. aliases (ou=Aliases)
       2. bootparams(ou=Bootparams)
       3. ethers(requires bootpararmas database to be installed first)(ou=Ethers)
       4. group(ou=Group)
       5. hosts(ou=Hosts)
       6. netgroup(ou=Netgroup)
       7. netmasks(requires networks database to be installed first)(ou=Networks)
       8. networks(ou=Networks)
       9. passwd(ou=People)
       10. shadow(requires passwd database to be installed first)(ou=People)
       11. protocols(ou=Protocols)
       12. publickey(ou=Hosts)
       13. rpc(ou=Rpc)
       14. services (ou=Services)
     • Enter the following commands from within the /usr/sbin/directoryserver directory:
       1. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/aliases aliases
       2. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/bootparams bootparams
       3. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/ethers ethers
     • Unix/NIS Groups:
       1. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/group group
       2. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/hosts hosts
       3. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/netgroup netgroup
       4. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/networks networks
       5. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/netmasks netmasks
       6. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/passwd passwd
       7. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/shadow shadow
       8. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/protocols protocols
       9. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/publickey publickey
       10. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/rpc rpc
       11. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/services services
     • These are specific to remote mounting of home directories:
       1. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/auto_home auto_home
       2. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/auto_master auto_master
       3. ldapaddent -D “cn=Directory Manager” -w [password] -f /etc/auto_direct auto_direct
     • Now that you have added your users into LDAP, you can test whether or not the machine that is an ldapclient can recognize them:

       # getent passwd [user id]

     • This should result in something that looks like this :

       test4::1005:1:this is a test user:/export/home/test4:/bin/csh

     • Reboot the Server
     When the client is initialized, an IP address of one or more LDAP servers and a search base is specified. This information can be specified as a command line argument to the ldapclient command, or in a profile generated by the ldap_gen_profile command. The preferred method is to generate a profile with the ldap_gen_profile command. The search base that is set in the profile is determined by how the tree is set up.

     The nisdomain value that the client looks for is the name listed in the /etc/defaultdomain file, or one supplied with the -d argument to the ldapclient command. The steps that the ldapclient command perform are:

     1. Search the LDAP server’s DSE to obtain the naming contexts supported in the specified directory server.
     2. Search the found naming contexts for an entry containing a nisDomainObject object.
     3. Check the found nisdomain attribute of the entry to verify if its value equals the value stored in the client’s /etc/defaultdomain file.
     4. Search the ou=profile container directly below the entry for an entry that matches the profile name rovided on the command line.
     5. Use the information retrieved from the profile entry to create the /var/ldap/ldap_client_file and /var/ldap/ldap_client_cred files on the client.
     A key point here is that the search for the profile entry will start directly below the entry containing the nisDomainObject with the matching nisdomain value. Another important point is that you only want to have one entry with the same nisdomain value in the directory server. The search will stop at the first match and fail if it cannot find the specified profile which is expected to be directly below the entry with nisDomainObject.

     Client searches on the naming service database default to ou=people, ou=group, etc. based on the SolarisSearchBaseDN variable set in the LDAP client profile. However, different search bases can be specified for different databases. You can specify these by overriding the defaults in the profile. To override a default, use the -B option of the ldap_gen_profile command. For example:
     ldap_gen_profile -P altpasswd -b o=nismaps,dc=yourcompany,dc=com -B “passwd: (ou=people,dc=yourcompany,dc=com)” -D cn=proxyagent,ou=profile,dc=yourcompany,dc=com -w [password] 127.0.0.1

     In this example, the passwd database is accessed from an alternative path. If user account information is shared with applications other than Solaris OE clients, you should separate the People container from the rest of the naming service databases.

     NOTE: The Solaris9 Server with the SunONE Directory Server 5.2 can be a client to itself. In order to have the Solaris9 Server (Naming Services Host) to be a client to itself, please rerun the instructions for Client Setup on the naming Services Host (Solaris9 Server with Directory Server5.2).

     Reboot the naming Sevices Host after configuring it to be a client to itself.

     NOTE: Solaris 9 includes a copy of the Sun Management Console 2.1 with support for LDAP Directory Server provisioning. SMC is rather complex, however, and attempting to provision LDAP users is an exercise in frustration. I have got to the point where I can begin to add LDAP users and groups, but there is no communication to the Directory Server and log entries are very cryptic.

     Useful References:
     

     1. Solaris 9 Administation Guide: Naming Server (NIS, NIS+, DNS and LDAP)
     2. NIS to LDAP Micgration Scripts
     3. SysAdmin to SysAdmin: Syncing NIS and LDAP
     4. NIS end-of-life and LDAP
     5. Migrating from NIS and NIS+ to RFC 2307-compliant LDAP services: Network Information Services (NIS and NIS+) Guide
     6. Transitioning From NIS+ to LDAP : Sun Docs
     7. PADL: NIS to LDAP MigrationTools
     8. The Official Red Hat Linux Reference Guide Configuring Your System to Authenticate Using OpenLDAP
     9. LDAP-mini-HOWTO By Mark Grennan
     10. Approaching LDAP Migration from LINUX.COM

         WHEW !!!. I'm poofed for now. Shall post another addendum to this sometime soon...

         UPDATE 1 : There has been no announcement made that nis would be EOL'd. I stand corrected. UPDATE 2 : My colleague Michael Haines pointed out a few inaccuracies in this post. I would like to add that for detailed usage and guidelines, you would need to refer to http://www.ietf.org/rfc/rfc2307.txt and http://www.padl.com/~lukeh/rfc2307bis.txt. There also seems to be some in accuracies in the ldapaddent section. I shall ammend that as soon as i find out the specifics of the inacuracies.