Monday Oct 13, 2008

OpenDS in under 3 minutes

Nick Wooler the product line manager for the directory services team has posted a screencast on installing OpenDS in under 3 minutes !!! This screencast is a must watch.

watch the simplicity of the entire installation process. It's simply awesome. The entire install including pre-populating OpenDS with 2000 simulated/sample entries was done in under 3 minutes in 5 extremely simple steps. (it takes longer to boil an egg)

User Experience DOES matter.

... and if you liked the soundtrack used in the screencast.. it's "Light & Day / Reach for the Sun" by The Polyphonic Spree feel free to download it from iTunes. (thanks shazam). And for pine-apples... here's the YouTube full length video (which is also under 3 minutes) :

Wednesday Jan 16, 2008

Fedora Directory Server would KILL openLDAP

Redhat had announced recently that their "aquired" AOL Netscape Directory server would be released as an opensource product. There have been debates on whether RedHat would make this move especially after they spent 20.5 Million Dollars in this aquisition last september. Well, If you have been fololowing the developments at RedHat, you'd notice that the Fedora Directory Server Community have been abuzz with developers scrambling around to better the product and build plugins etc. They have also begun to publicly make available sourcecode for migrating from openLDAP to Fedora Directory Server.. Every startup in the silicon valley had a tendency to use OpenLDAP or OEM the Sun Directory Server. Would this move by RedHat prompt a startup:wide move to Fedora Directory Server ?. Well, I dont think so. The startups have invested a lot of effort, time and energy arpound either embedding OpenLDAP or OEM the Sun Directory Server. Making architecture change in a startup company is not a simple move as their product turnaround times are dicatated by their venture capitalists and the release announcements that they have already made. In addition the folks who have OEM'd the Sun Directory Server have this huge group of support engineers on standby to help enable deployment. If startups had to make a move from Sun Directory to Fedora Directory, they would have to SACRIFICE the backend support, their currently embedded features and a whole lot more. But those who have been using OpenLDAP might most probably consider a move to Fedora Directory Server. One organization I am thinking of is infoblox. They might use Fedora Directory as an embedded product for ldapONE, their LDAP Appliance. but will they make this move? or would they consider OEMing the Sun Directory? Guess time will tell.
UPDATE: I Just noticed the infoblox is not advertising their ldapONE as a product offering now, I assume that have simply pulled out of the idea of shrinkwrapping openldap into an appliance. Guess they have decided to stick to their DNS offerings as Cricket Liu is their trump card.

Tuesday Jan 15, 2008

NIS to LDAP migration Guide

I have been asked over and over again n procedures and processes to enable the migration of NIS / NIS+ infrastructures over to LDAP... especially with the Support-EOL drop dead date soon approaching..

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

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: 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.
Server Setup:
  • Install Solaris9 (8/03)-Release using 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 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=( 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:
    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="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]

      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 and 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.

In the beginning there were GROUPS... and along came ROLES

Guess the one question I would continually be posed with whenever I interact with folks involved in Identity Management, is the usage of groups vs roles and the best practices for choosing one or the other. Well, hopefully the folks who keep searching for answers on this stumble on this blog and not ask me this over and over...

SO explanation: Once upon a time GROUPS was a convenient way to aggregate users. GROUPS were used to simplify the process of managing access permissions and generic attributes with a subset of users. To make management simpler, GROUPS could be made a subset of another GROUP and thus inherit permissions etc from it's parent. The ability to make GROUPS a subset of another facilitated a hierarchical structure. GROUPS is a simple aggregate.

and then.. along came ROLES.

So: A ROLE is a special type of GROUP. the properties of ROLES and GROUPS are extremely similar. But when GROUPS are used to OBJECT permissions, ROLES are used for APPLICATION permissions. ROLES provide a scemantic grouping of policies/permissions with a common subject which pertains to the users role(noun) - capacity, function, position, duty in an organization. A ROLE can enable one to associate policies with an automated component (ie: application). A ROLE is thus a SPECIAL GROUp where all the policies/permissions have the same subject.

Roles and further be categorized as FLAT ROLES, DYNAMIC ROLES etc... Flat ROLES are exactly the same as GROUPS in usage and behaviour.

Someday soon, when i get a moment to spare a thought again I shall try to blog on ROLES and their flavors in more detail.. Cheers for now.


for everything on Identity, JCAPS, SOA, WebServices, Security, Single Signon, Federation, Provisioning, Virtualization, Optimization, Debugging, Workflows, Compliance, MySQL and more... WAY MORE....

[this is a group blog]


« July 2016