Solaris 10 as LDAP client (to OpenLDAP 2.4.x)

During the last couple of weeks I’ve been working on getting a central directory setup for my client, running on OpenLDAP 2.4. Not having worked with LDAP a lot before it proved quite a challenge, especially getting Solaris 10 to work with the LDAP server without any glitches.
In this document I’ll try and describe how this setup was made, because I have been unable to find a single consistent document describing all the intricate details.
At this time I have all my problems fixed (AFAIK), but during the setup phase I experienced various problems:

  • Solaris 10 not seeing any users from LDAP
  • Solaris seeing users, but not letting them log in
  • Log-in working from console, but not ssh
  • Passwordless login (pubkey) not working in SUN-SSH
  • Users being able to hack extra permissions for themselves
  • etc…. etc….etc…

The entire article has been moved to a more permanent location, as a page on this site. You can find it under the ‘Pages’ header on the right. Setting up ldap

Be Sociable, Share!

6 thoughts on “Solaris 10 as LDAP client (to OpenLDAP 2.4.x)”

  1. If you copied any of the slapd config, beware that I just changed part of the ACL’s. Proxyagent had write access to the People and Groups tree. This caused a ‘userdel’ command on a unix system to actually remove the user from LDAP (at least on AIX). This should no longer happen now.

  2. Foobar

    Excellent work!!, fantastic someone has taken the effort to deploy & document the process, Ive been pulling my hair out trying to get this to work

    Can you shed any light on

    objectClass: person
    objectClass: organizationalPerson
    objectClass: posixAccount
    objectClass: shadowAccount

    where are these objectClass’s referenced, in which schema?

    I’m also trying to figure out logically how it all hangs together

    Once I’m done i will post my results

    many thanks again

    Frank

  3. I think (from my head) that posixAccount and shadowAccount are from nis.schema. The person schema’s are from core.schema afaik.

    These are required for practically all *UX boxen

  4. Foobar

    The userPassword attribute for the testuser, can this be stored in crypt format? within the ldif file above?

    userPassword:: MUNGED

  5. It is stored (in this case) in SSHA format (Salted SHA1). You can also use various other hashing methods (MD5/Crypt/etc)

    Best is just to set it to something invalid (like this) and then use Apache Directory Studio (or some other ldap browser/editor) and set the password for the account using that.

Comments are closed.