Solaris LDAP

LDAP is a client-server protocol for accessing a directory service. LDAP server can be used as a central point for user authentication over the network. LDAP is the industry standard for directory access and embraced by companies such as IBM, Netscape, Novell, Microsoft etc.

LDAP was first implemented at the University of Michigan in the early 1990's. LDAP is a TCP/IP application level protocol similar to HTTP, ftp and telnet.

There are many commercial LDAP servers available like Microsoft Active Directory, Novell eDirectory, iPlanet Directory Server, etc. In addition there is an open source implementation of LDAP (OpenLDAP) based on the work done at Michigan . It is used mainly on Linux and BSD operating systems, but can be used on Solaris too. LDAP is commonly defined in terms of four models. These are:

• Information Model -- specifies how data is stored within the directory.
• Naming Model -- defines how objects within the directory structure are organized and identified
• Access Model. The mechanics for accessing data
• Security Model. How data are protected.

The Lightweight Directory Access Protocol (LDAP) is an open-standard, platform independent, access protocol based on the X.500 informational model. It is designed to run over TCP/IP and uses simple string encoding. LDAP servers provide access to a hierarchical Directory Information Tree (DIT) that is made up of entries much like Unix filesystem tree. An entry has a relative distinguished name (RDN) that is unique among all its siblings and a distinguished name (DN) that is unique in the tree. LDAPv3 (RFC 2251) supports the following operations:

1. bind Allows authentication information to be exchanged between the client and server.
2. unbind Terminates a protocol session.
3. search Allows a client to request that a search be performed on its behalf by a server.
4. modify Allows a client to request modification of an entry on its behalf by a server.
5. add Allows a client to request the addition of an entry into the directory.
6. delete Allows a client to request the removal of an entry from the directory.
7. modify DN Allows a client to change the leftmost component of the name of an entry in the directory, or to move a subtree of entries to a new location in the directory.
8. compare Allows a client to compare an assertion provided with an entry in the directory.
9. abandon Allows a client to request that the server abandon an outstanding operation.
10. extended Allows clients to make requests and receive responses with predefined syntax and semantics.

LDAP in Solaris

The LDAP client library was first available in Solaris 7. The ldap(3LDAP) man page refers to 134 LDAP library functions that were added. In addition, the following user commands became available:

• ldapadd(1) -- LDAP entry addition tool
• ldapmodify(1) -- LDAP entry modification tool
• ldapdelete(1) -- LDAP delete entry tool
• ldapsearch(1) -- LDAP search tool
• ldapmodrdn(1) -- LDAP modify entry RDN tool
• ldapsearchprefs.conf(4) -- Configuration file for LDAP search preference routines
• ldapfilter.conf(4) -- Configuration file for LDAP filtering routines
• ldaptemplates.conf(4)-- Configuration file for LDAP display template routines

Starting from version 8 Solaris provides complete LDAP integration. LDAP back-end support to the Name Service switch was added. Network administrators can now specify LDAP as the desired name service to directory access by copying the nsswitch.ldap template file to /etc/nsswitch.conf. Native LDAP support is only available for IPv4 for Solaris versions less then 10. 

There are several relevant man pages:

• ldap(1)Using LDAP as a naming repository.
• ldap_cachemgr(1M) Specifying LDAP daemon to cache server and client information for Network Information Service lookups.
• ldapclient(1M)Initializing LDAP client machines.
• ldap_gen_profile(1M) Creating an LDIF file that can be loaded into an LDAP server to be used as the client profile, which can be downloaded by ldapclient.
• ldaplist(1) Specifying LDAP utility to search and list naming information from an LDAP directory service.
• pam_ldap(5) Specifying Authentication and password management PAM modules for LDAP.

The nsswitch(4) man page have been updated with changes to support LDAP.

A directory service functions somewhat like a database, but it differs from traditional relational databases in several ways:

• It is optimized for reading; adding and updating entries may be expensive.
• It provides advanced searching features.
• Its fundamental data structures, collectively known as the schema, can be extended according to local needs.
• It adheres to published standards to ensure interoperability among vendor implementations, specifically, a series of RFCs.
• It takes advantage of distributed storage and data replication techniques, allowing it to scale efficiently.

Because of these advantages  LDAP is replacing NIS/NIS+ as the enterprise user account and authentication of choice. That's why NIS+ will no longer be supported in future versions of Solaris. The Solaris best supports LDAP with the iPlanet Directory Server but can also work with other LDAP directory servers.  iPlanet Directory Server must be set up and then configured to support Solaris LDAP clients. On a configured LDAP server, the /etc/rc2.d/S72directory script starts the iPlanet Directory Server during the boot process.

LDAP provides a directory service which can be used for storing and querying information about the users. The range of information that can be made available in this way is typical for directories: Unix user account data or other institutional directory data (office location, phone numbers, and the like).

In order to emphasize these differences with respect to standard relational databases, different terminology is used to name a directory service's data structures: records are referred to as entries, and each field within a record is known as an attribute. .Like the DNS namespace, LDAP names start with the least significant component and proceed to the most significant; in other words, those just below root. The DN is constructed by concatenating the sequence of RDNs up to the root of the tree.

Note: Although the term LDAP is very fuzzy, it actually refers only to the protocol by which data are accessed (implemented in a daemon). The actual database capabilities are provided by a separate back-end program or package.

LDAP directories provide a way to name, manage, and access collections of directory entries. A directory entry is composed of attributes that have a type and one or more values. The syntax for each attribute defines the allowed values, or the allowed data type of the attribute values, such as American Standard Code for Information Interchange (ASCII) characters or a numerical data. LDAP also defines how those values are interpreted during a directory operation; for example, determining if a search or compare is case sensitive.

Directory entries are organized into a tree structure, which can be based on boundaries defined by geography (country), organization (company), or domain components (dc).

Entries are named according to their position in this tree structure by a distinguished name (DN). Each component of the DN is called a relative distinguished name (RDN). An RDN is composed of one or more attributes from the entry. The hierarchy of the directory tree structure is similar to that of the UNIX file system. An RDN corresponds to the relative path name of a file, and the DN to the absolute path name. As in the UNIX file system, sibling directory entries must have unique RDNs. However, unlike Unix filesystem in the directory tree, each entry can contain both content and attributes.

dc=softpanorama, dc=org
ou = Hosts ou = People
DN = "cn = Nikolai Bezroukov, ou = People, dc = softpanorama, dc = org"

Solaris LDAP Client

You execute the ldapclient command on the client system once to initiate the client as a native LDAP client. The required command-line arguments include the proxy name, password, and the LDAP server�s IP address. The following example describes a typical client initialization:

# ldapclient init -a proxyPassword=proxy \

-a proxyDN=cn=proxyagent,ou=profile,dc=softpanorama,dc=org\

-a domainname=softpanorama.org 192.168.1.1

There are two ACSII configuration files for the client in /var/ldap/

• ldap_client_cred contains the proxy agent information that the client uses for LDAP authentication that you can read using The ldapclient list command or any text file view command availble in Unix, for example cat ldap_client_cred
   
• ldap_client_file

You use the ldaplist command to list the naming information from the LDAP servers.

• Without any arguments, the ldaplist command returns all of the containers in the current search base DN.

To unconfigure an LDAP client, use the ldapclient uninit in used. This command removes the client files from the /var/ldap directory and restores the previous /etc/nsswitch.conf file.The ldap_cachemgr process is also stopped. The configuration changes are dynamic and no reboot is needed after ldapclient uninit command.

NEWS CONTENTS

• 20100613 : LDAP basics ( LDAP basics, Jun 13, 2010 )
• 20070715 : Brads Publications ( Brads Publications, July 15, 2007 )
• 20060824 : LDAP Authentication In Linux HowtoForge - Linux Howtos and Tutorials by tdi ( LDAP Authentication In Linux HowtoForge - Linux Howtos and Tutorials, Aug 24, 2006 )
• 20060727 : Demystifying LDAP ( Demystifying LDAP, Jul 27, 2006 )
• 20060727 : LDAPSolaris Docs TWiki ( LDAPSolaris Docs TWiki, )

Old News ;-)

[Jun 13, 2010] LDAP basics

LDAP (Lightweight Directory Access Protocol) has a reputation for being complicated, but I hope to dispel that myth and explain exactly how LDAP works in this simple introduction of some of the basic concepts..

What is LDAP?

LDAP is a lightweight protocol for accessing directory servers. Okay, so what is a directory server? It's a hierarchical object orientated database. If that makes you want to run away screaming, don't worry, it'll get worse before it gets better.

Only joking. This guide should make learning LDAP easy. Let's go through that description bit by bit, starting at the end. It's a database, which means we can store data in it. If you've used relational databases, like mysql, then it won't look like anything you're used to, but like a relational database, it allows you to store your data in a user defined structural way.

The second part of our description was object orientated. In LDAP our database is a collection of objects. Like in OO programming, objects are instances of a particular class. A class defines the set of attributes that an object may contain. Classes can inherit from other classes to add additional attributes. LDAP has some differences from the usual OO semantics, which will be explained in the next section.

The final part of our description was hierarchical. Every object in LDAP can contain one or more sub-objects. The result is a tree with the trunk being the root of the directory and the branches and leaves being the objects in the directory. In this way we can build up our database into an easy to navigate, structured database.

Lightweight? Lightweight? What crack are you on?

Sometimes you wonder how anyone could describe this complicated mess as lightweight. The lightweight is in reference to the previous leading standard for directory services, called X.500. The problem with X.500 was that it required the use of the OSI network stack and couldn't use TCP/IP. It was also rather more complicated. LDAP only uses 9 of the operations that X.500 supported, and can use the simpler TCP/IP networking stack.

Objects and Classes

As I mentioned, data stored in LDAP is stored in objects. These objects contain a number of attributes, which are basically a set of key/value pairs. Because data in LDAP is structured, objects can only contain valid keys, and which keys are valid is dependant on what class the object is. Classes in LDAP can define mandatory attributes and optional attributes and their type.

To confuse matters (and this is where LDAP deviates from most OO systems) objects can have more than one class and there are several types of class.

The first type is the structural class. An object must have one and only one structural class. Structural classes tend to map to physical objects like a person or a network. Once an object has been created the structural class can not be changed without destroying the object and creating it again.

Auxiliary classes define additional attributes to complement structural classes. Objects may have many auxiliary classes and can be added and removed after the object has been created.

Finally there are abstract classes, which can not be used directly by objects, but can be used by other classes through inheritance.

Classes are assigned to objects using the objectClass attribute. LDAP defines some basic classes, types and comparison methods by default, but you are free to define your own.

Examples

It's well and good me telling you all this, but it probably won't make sense until I show you some examples. A common use for LDAP is an address book, so you could use the person class, which is structural. It defines sn and cn as mandatory attributes and userPassword, telephoneNumber, seeAlso and description as optional fields. A couple of those attributes probably need explaining. sn is surname and cn is common name, which we can use to store the person's full name. The dashed line in the image marks the mandatory and optional attributes.

But what if we wanted to store addresses in the object too? Well if we had used the organizationalPerson, which inherits from the person class, but adds title, street, postalAddress and postalCode. The class adds several more attributes too. Because it inherits from person we still have sn and cn. There is an even more comprehensive class called inetOrgPerson.

Another common use for LDAP is authentication of user accounts. For this, we can use the posixAccount class. This is an auxiliary class and adds cn, uid, uidNumber, gidNumber and homeDirectory mandatory attributes and userPassword, loginShell, gecos and description as optional attributes. Because posixAccount is auxiliary, we can add it to our person object for people we want to be able to authenticate.

Distinguished Names

One very important aspect I have omitted to mention is the dn or distinguished name. This is a unique name used to refer to a particular object in the tree. It's made up from the dn of the parent object and a unique key/value pair from the sub-objects. For example if you stored your address book under ou=People,dc=example,dc=com, a common location, my details would have a dn of cn=David Pashley,ou=People,dc=example,dc=com and Bill Gates would have a dn of cn=Bill Gates,ou=People,dc=example,dc=com. As you can see each level in the hierarchy is separated by commas. It is possible to have multi-attribute distinguished names by putting a + between the attributes. Distinguished names are not actually attributes of objects.

Database Layout

I should explain that ou is an organizational unit and dc is domain component. In our database we are storing all our objects below dc=example,dc=com and is called the base dn because it is the base of our database. While you don't need to use a unique base dn for your database, it is common practice to do so and is more important if you intend to make your database publicly available. Originally databases used to be based on your location (o=Catnip,l=Brighton,st=Sussex,c=uk), but it is much more common now to use a DNS domain that you own as the basedn (dc=catnip,dc=org,dc=uk).

Earlier we used ou in a dn. This is merely a class for grouping our data into sections for administrative ease. There are no rules that force you to organise your database in any particular way, but there are several common ways of laying out databases. The actual layout of the directory tends to not be that important to applications using the directory as they can do recursive queries for the objects they are interested in. We could have our address book in ou=People,dc=example,dc=com and a list of computers in ou=Computers,dc=example,dc=com. If we had a very simple database we could easily mix both into one location and have people and computers as sub-objects of dc=example,dc=com. Alternatively, if we had a very large authentication database, we could go the other way and split the people into several organizational units mirroring their departments, so we could have the sales department in ou=Sales,dc=example,dc=com and marketing in ou=marketing,dc=example,dc=com. Using this scheme you could delegate control for the sales tree to the Sales Manager and the marketing tree to the Marketing Manager, which may not be possible with other schemes.

Further Reading

• LDAP System Administration by Gerald Carter
• Understanding and Deploying LDAP Directory Services (2nd Edition) by Timothy A. Howes, Mark C. Smith, Gordon S. Good, and Tim Howes
• OpenLDAP documentation
• Linux LDAP HOWTO
• Understanding LDAP - Design and Implementation

[July 15, 2007] Brads Publications

Mastering OpenLDAP Book review

A book review of Mastering OpenLDAP, written on 29th March, 2008.

• Book Review

LDAP Theory and Management

Covers LDAP theory and how to manage the data. Given at:

• SAGE-AU 2003 in Hobart on 4th August, 2003.
  • LaTeX
  • PDF
• SAGE-AU 2006 in Canberra on 24th July, 2006.
  • LaTeX
  • PDF

LDAP Servers and Applications

Covers LDAP servers and applications. Given at:

• SAGE-AU 2003 in Hobart on 4th August, 2003.
  • LaTeX
  • PDF
• SAGE-AU 2004 in Brisbane on 17th August, 2004.
  • LaTeX
  • PDF
• SAGE-AU 2006 in Canberra on 24th July, 2006.
  • LaTeX
  • PDF

LDAP Tutorial

This presentation gives an overview of what LDAP is, and covers a few uses for it. Given at:

• SAGE-AU and AUUG Tasmania in Tasma nia on October 2nd, 2000
  • HTML
  • ZIP
• SAGE-AU 2001 in A delaide on July 9th, 2001
  • HTML
  • ZIP
• SAGE-AU 2002 in Melbourne on August 5th, 2002
  • LaTeX
  • PDF

System Authentication using LDAP

A short presentation with basic information about LDAP and how to set up system authentication using pam_ldap and nss_ldap. Given at:

• SAGE-AU 2000
  • HTML (Paper)
  • MagicPoint (Slides)
  • HTML (Slides)
• QAUUG Summer Technical Conf 2001: HTML

Introduction to LDAP

This article was published in Linux.com Sysadmin section on 25th October 2000, and is a basic introduction to LDAP.

[Aug 24, 2006] LDAP Authentication In Linux HowtoForge - Linux Howtos and Tutorials Submitted by tdi

This howto will show you howto store your users in LDAP and authenticate some of the services against it. I will not show howto install particular packages, as it is distribution/system dependant. I will focus on "pure" configuration of all componenets needed to have LDAP authentication/storage of users. The howto assumes somehow, that you are migrating from a regular passwd/shadow authentication, but it is also suitable for people who do it from scratch.

Requirements

• OpenLDAP
• pam_ldap
• nss_ldap
• PADL migrationtools

Introducion

The thing we want to achieve is to have our users stored in LDAP, authenticated against LDAP ( direct or pam ) and have some tool to manage this in a human understandable way.

This way we can use all software, which has ldap support or fallback to PAM ldap module, which will act as a PAM->LDAP gateway.

More information on LDAP idea can be found on Wikipedia: LDAP wikipedia

[Jul 27, 2006] Demystifying LDAP

Is LDAP a database or a protocol? Is it understandable and deployable without reading a thousand pages of explanation and documentation? Brian Jones untangles some of the myths and legends about LDAP to explain what it is, why it's useful, and how to put it to productive use.

LDAPSolaris Docs TWiki

Solaris LDAP Authentication

This document covers how a Solaris system can be configured for LDAP authentication. It is an early draft and has only been tested with Solaris 10 zones although there is no reason why it should not work with earlier versions of Solaris.

Configure an SSL Tunnel

Because our LDAP service requires SSL connections before allowing authentication, it is necessary to connect to the LDAP server using SSL. The easiest way of doing this, is to configure a network tunnel ... the local machine will think it is talking to an LDAP server on the local machine.

First [ for O/S 9 and 10] , create the configuration necessary for the stunnel tool in /opt/etc. Or copy from ISOadm/nw-sun/LDAPclient/site-scripts/st-ldap.conf:-

    client = yes
    [ldap]
        accept=localhost:389
        connect=ldap.port.ac.uk:636

Note the "accept=localhost:389" ... the use of 'localhost' here prevents the tunnel from being visible (and usable) from the network, which would be a possible security hole.

Next is to configure an XML manifest for the SMF service if applying to Solaris 10. Either create the XML file with these conditions or use ISOadm/nw-sun/LDAPclient/site-scripts/st-ldap.xml :-

  <?xml version="1.0"?>

  <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

  <service_bundle type='manifest' name='Lstunnel-ldap'>

  <service
          name='site/Lstunnel-ldap'
          type='service'
          version='1'>

          <create_default_instance enabled='true' />

          <dependent
            name='exim_multi-user-server'
            grouping='require_all'
            restart_on='none'>
            <service_fmri value='svc:/milestone/multi-user-server' />
          </dependent>


          <exec_method
                  type='method'
                  name='start'
                  exec='/ISOadm/nw-sun/sbin/stunnel /opt/etc/st-ldap.conf'
                  timeout_seconds='0' />

          <exec_method
                  type='method'
                  name='stop'
                  exec=':kill -15'
                  timeout_seconds='3' />
  
  </service>
  </service_bundle>

This can be imported with svccfg import st-ldap.xml. Once imported start with svcadm enable Lstunnel-ldap.

For Solaris 9 copy ISOadm/nw-sun/site-scripts/LDAPclient/ldap.client to /etc/init.d, and run /etc/init.d/ldap.client start

Configure PAM

For Solaris 9 and 10 replace /etc/pam.conf with, the appropiate files from /ISOadm/nw-sun/site-scripts/LDAPclinet. select pam9.conf for Solaris 9, pam10.conf for Solaris 10]

The following is the corerct pam.conf for Solaris 10, for Solaris 9 all lines contained cred are omitted.

#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login   auth requisite        pam_authtok_get.so.1
login   auth required         pam_dhkeys.so.1
login   auth required         pam_unix_cred.so.1
login   auth required         pam_dial_auth.so.1
login   auth binding          pam_unix_auth.so.1 server_policy
login   auth required         pam_ldap.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin  auth sufficient       pam_rhosts_auth.so.1
rlogin  auth requisite        pam_authtok_get.so.1
rlogin  auth required         pam_dhkeys.so.1
rlogin  auth required         pam_unix_cred.so.1
rlogin  auth binding          pam_unix_auth.so.1 server_policy
rlogin  auth required         pam_ldap.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh     auth sufficient       pam_rhosts_auth.so.1
rsh     auth required         pam_unix_cred.so.1
rsh     auth binding          pam_unix_auth.so.1 server_policy
rsh     auth required         pam_ldap.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp     auth requisite        pam_authtok_get.so.1
ppp     auth required         pam_dhkeys.so.1
ppp     auth required         pam_dial_auth.so.1
ppp     auth binding          pam_unix_auth.so.1 server_policy
ppp     auth required         pam_ldap.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other   auth requisite        pam_authtok_get.so.1
other   auth required         pam_dhkeys.so.1
other   auth required         pam_unix_cred.so.1
other   auth binding          pam_unix_auth.so.1 server_policy
other   auth required         pam_ldap.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd  auth binding          pam_passwd_auth.so.1 server_policy
passwd  auth required         pam_ldap.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron    account required      pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other   account requisite     pam_roles.so.1
other   account binding       pam_unix_account.so.1 server_policy
other   account required      pam_ldap.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other   session required      pam_unix_session.so.1
#
# Default definition for  Password management
# Used when service name is not explicitly mentioned for password management
#
other   password required     pam_dhkeys.so.1
other   password requisite    pam_authtok_get.so.1
other   password requisite    pam_authtok_check.so.1
other   password required     pam_authtok_store.so.1 server_policy
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#

Instead of just looking in /etc/passwd, this checks there and checks in the LDAP server. The /etc/passwd file takes priority.

Configuring LDAP

Configure the LDAP client daemon manually with the following command, there is a script file in /site-scripts called ldap-mancli which will do the same thing, as long as stunnel is running:-

/usr/sbin/ldapclient manual
                -a defaultServerList=localhost
                -a defaultSearchBase=ou=lan,o=port
                -a defaultSearchScope=sub
                -a authenticationMethod=none
                -a credentialLevel=anonymous
                -a serviceAuthenticationMethod=passwd:simple
                -a serviceAuthenticationMethod=shadow:simple
                -a serviceAuthenticationMethod=pam_ldap:simple
                -a attributeMap=passwd:gecos=fullname
                -a attributeMap=passwd:homeDirectory=unixHome
                -a attributeMap=passwd:uid=cn
                -a serviceSearchDescriptor=shadow:ou=lan,o=port?sub
                -a serviceSearchDescriptor=passwd:ou=lan,o=port?sub

To restrict the ability to login to members of a group, add "?groupMembership=cn=gp-ac-pepitas,ou=sysperms,ou=ns,ou=lan,o=port" to the end of the "serviceSearchDescriptor".

Cleaning Up

The ldapclient command makes some changes we don't like, so edit /etc/nsswitch.conf and remove the 'ldap' word from all the name services except for 'passwd' and 'group' (including any "[NOTFOUND=return]" bits). Double check DNS has files and dns.

Also disable the autofs with svcadm disable autofs as this seems to spring into life.

Remaining Stuff

1. Map homeDirectory to unixHome for systems where a local home directory is preferred.

2. Look into setting up autofs for /Network/Servers/{IP}/... so we automount the users home directory.

Debugging

Finding out what is going wrong is kind of tricky as there is very little logging for LDAP. The simplest method of debugging is to change the LDAP server list to "ldap.port.ac.uk" and dump the traffic :-

    ldapclient -v mod -a defaultServerList=ldap.port.ac.uk
    snoop -o ldap.dump -s 0 host hickory-blue

The output file is best inspected on a workstation using Ethereal.

Don't forget to change the server list back again ... because this is plain text LDAP (which is necessary for dumping traffic), the NDS won't allow any authentication.

Working ldapclient list Configuration

# /usr/sbin/ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= localhost
NS_LDAP_SEARCH_BASEDN= ou=lan,o=port
NS_LDAP_AUTH= none
NS_LDAP_SEARCH_SCOPE= sub
NS_LDAP_CACHETTL= 0
NS_LDAP_CREDENTIAL_LEVEL= anonymous
NS_LDAP_SERVICE_SEARCH_DESC= shadow:ou=lan,o=port?sub
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=lan,o=port?sub
NS_LDAP_ATTRIBUTEMAP= passwd:homeDirectory=unixHome
NS_LDAP_ATTRIBUTEMAP= passwd:gecos=description
NS_LDAP_ATTRIBUTEMAP= passwd:uid=cn
NS_LDAP_SERVICE_AUTH_METHOD= passwd:simple
NS_LDAP_SERVICE_AUTH_METHOD= pam_ldap:simple
NS_LDAP_SERVICE_AUTH_METHOD= shadow:simple

-- MikeMeredith - 23 May 2005

[Oct 27, 2005] Linux.com Advanced Linux LDAP authentication By: "American" Dave Kline

In an earlier look at LDAP, we set up a simple LDAP-based authentication system. We configured client machines to retrieve authentication information from a server running OpenLDAP. Now let's go further by enabling encryption and looking at how to make user modifications through LDAP.

If client machines are to authenticate through LDAP, administrators must make sure user changes are reflected within the LDAP server. Most user management utilities on a client system expect to find information in files like /etc/passwd and /etc/group. If such information is only available through LDAP, utilities may complain about unknown users. To make changes in these cases, an administrator must modify the corresponding LDAP entries. While utilities such as phpLDAPadmin can help with this task, you must know what you're doing if you're to use them effectively.

LDAP for Solaris 8

Solaris 8 comes with a 200,000 user license for iPlanet Directory Server, a NSS nameservice-switch library for LDAP, a PAM module for LDAP, and Not Enough Documentation to get it to work.

It was really nice of sun to include all of this. It was extremely frustrating to not find documentation on Sun's web site, nor in the Answerbooks, etc, etc, rant rant rant.

Nobody should have to go through the pain I went through trying to get this to work. Using usenet and google searches, I got at least the NSS part working, so I could largely replace /etc/passwd with ldap, and I'm working on getting the PAM part working. [update: I have pam and nss working just great, it's all working superbly!] The following whitepaper, which I found through lots of deja searches, and not on www.sun.com for some reason is very helpful.

[update: there is now some information on sun's site at http://wwwwswest.sun.com/software/solutions/blueprints/1000/ldap-sol8.pdf.]

Sun Whitepaper titled "LDAP Setup and Configuration" [PDF, 232K]

---

Michael Mittelstadt

Recommended Links

Softpanorama Recommended

Top articles

Sites

An LDAP Roadmap & FAQ -- Directory Services Information

IBM Redbooks Implementation and Practical Use of LDAP on the IBM eServer iSeries Server

First three chapters are a decent intro.

IBM Redbooks Understanding LDAP

Lightweight Directory Access Protocol (LDAP) is a fast-growing technology for accessing common directory information. LDAP has been embraced and implemented in most network-oriented middleware. As an open, vendor-neutral standard, LDAP provides an extendable architecture for centralized storage and management of information that needs to be available for today's distributed systems and services.

After a fast start, it can be assumed that LDAP has become the de facto access method for directory information, much the same as the Domain Name System (DNS) is used for IP address look-up on almost any system on an intranet and on the Internet. LDAP is currently supported in most network operating systems, groupware and even shrink-wrapped network applications.

This redbook was written for those readers who need to understand the basic principles and concepts of LDAP. Some background knowledge about heterogeneous, distributed systems is assumed and is highly beneficial when reading this book. Because this book is not meant to be an LDAP implementation guide, it does not contain product-related or vendor-specific information other than that used in examples

Implementing LDAP in the Solaris Operating Environment (October 2000) -by Tom Bialaski

This article provides an overview of LDAP implementation. LDAP is an industry standard interface that is more than just a protocol. This article provides an explanation of the LDAP models and their actual implementation. Since the installation and configuration of Solaris Native LDAP is quite complex this article provides a foundation for understanding the fundamental principles involved.

Solaris Directory Services: Past, Present and Future (October 1999) -by Tom Bialaski

The high availability features of currently supported Solaris Operating Environment directory services (NIS, NIS+, DNS) and contrasts them with LDAP's high availability features.

http://docs.sun.com/source/816-5616-10/ldap.htm An Introduction to LDAP, rather week

This chapter gives a brief introduction to the Lightweight Directory Access Protocol (LDAP) and the concepts behind LDAP.

LDAP is the Internet directory protocol. Developed at the University of Michigan at Ann Arbor in conjunction with the Internet Engineering Task Force, LDAP is a protocol for accessing and managing directory services.

The chapter is organized into the following sections:

• How Directory Services Work
• How LDAP Servers Organize Directories
• How LDAP Clients and Servers Work
• Support for the LDAPv3 Protocol

NOVELL LDAP page

Novell Using LDAP Tools on Linux, Solaris, or Tru64 UNIX Documentation

LDAP and Directory Books

Providing directory services with LDAP requires a careful look at the options

System Authentication using LDAP

O'Reilly Network Getting Started with LDAP

Netscape Directory Server

LDAP authentication using pam_ldap and nss_ldap

Selected Blueprints

Understanding Solaris 9 Operating Environment Directory Services (December 2002)
-by Tom Bialaski
This article examines the differences between the Solaris 8 Operating Environment (Solaris OE) Lightweight Directory Access Protocol (LDAP) Client and the Solaris 9 OE Secured LDAP Client, and explains how to support them on the same directory server. In addition, this article details troubleshooting tips for common implementation problems.

Automating LDAP Client Installations (July 2001)
-by Tom Bialaski
The article explains how to configure a native LDAP client at installation time, which is a new feature in Solaris 8 Operating Environment U3. The basics of sysidtools and creating a sysidcfg file for hands-off installation is covered along with how they relate to LDAP. Hard to find (non-documented) tips are provided to avoid common pitfalls.

Extending Authentication in the Solaris 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part II (October 2002)
-by Michael Haines and Joep Vesseur
This article is part two of a two-part series and details the PAM application programming interface (API) and the PAM service provider interface (SPI). Also included are procedures on how to effectively write PAM modules when using the Solaris 9 Operating Environment (Solaris 9 OE). By writing these PAM service modules, it is possible to extend the capability of the Solaris 9 OE authentication mechanisms in a number of different ways.

Part one, Extending Authentication in the Solaris 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part I, was published in the September 2002 issue of Sun BluePrints Online.

Securing LDAP Through TLS/SSL--A Cookbook (June 2002)
-by Stefan Weber
Deploying secure Lightweight Directory Access Protocol (LDAP) connections is becoming more demanding. This article details the steps on how to set up the Sun Open Net Environment (Sun ONE) Directory Server software so that it can be accessed securely from command line tools.

Running Multiple Solaris Operating Environment Naming Services on a Client (May 2001)
-by Tom Bialaski
The native LDAP client installation program assumes that you will not be running another naming service on your client. Some customers, who I have worked with, do not want to disable NIS when they configure native LDAP. This can be done, but there is no readily available document which describes how to do it. The article not only describes this procedure, but also highlights best practices for running NIS and LDAP together.

LDAP Utilities

• ldaplist -- list LDSP entries

• ldapcmp.exe

• ldapdelete.exe

• ldapmodify.exe

• ldapsearch.exe - search LDAP entries

Random Findings

• 10-minute LDAP tutorial
• MigrationTools -- Perl scripts for populating LDAP directories Jun 28th 1999, 15:07 stable: 3.19 - devel: none license: BSD type
• Performance Computing - Features - LDAP The Glue Is Almost Set
• Implementing LDAP--Namespace Considerations

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019