Conklin Technology Group, LLC IT Architecture. Identity Management. Unix Administration

27Apr/100

Adding Posix attributes to your LDAP users

dn: uid=msmith,ou=people,o=root
changetype:modify
add: objectclass
objectclass: posixaccount
-
add: uidnumber
uidnumber: 1000
-
add: gidnumber
gidnumber: 100
-
add: homedirectory
homedirectory: /home/msmith
-
add: loginshell
loginshell: /bin/bash

Now that you've got your OpenDS cloud-based server up and running, it's time to start configuring your Unix and Linux servers and workstations to use LDAP for authentication.

Before you get started, here's a few things to consider:

  • The POSIX attributes you'd normally find in the /etc/passwd and /etc/shadow files will now be stored in LDAP.  Things like login shell, numeric user ID, home directory, etc.
  • All of the attributes stored in LDAP for each user will be the same across all of your systems.  Meaning, the 'homedirectory' attribute (let's say its value is "/home/username") will need to exist on all the machines you're going to configure to use LDAP authentication.
  • If you don't have an existing source for what you're going to set the uid value to (something like an employee ID), you'll need to create some sort of mechanism for tracking which values have been used.  This could be a MySQL database, a spreadsheet, or a Post-It note, but you'll want to be sure that you don't assign one uid to multiple users.

(If you missed the last post, about populating your LDAP server with user data, check out the instructions here)

So, one of the first steps you'll need to do is to assign the necessary attribute values to the user records.  You can use the sample LDIF below to get started.  Notice the first change is to add a new objectclass called 'PosixAccount' -- this objectclass contains the attributes you'll need to do Unix authentication.

dn: uid=msmith,ou=people,o=root
changetype:modify
add: objectclass
objectclass: posixaccount

-

add: uidnumber
uidnumber: 1000

-

add: gidnumber
gidnumber: 100

-

add: homedirectory
homedirectory: /home/msmith

-

add: loginshell
loginshell: /bin/bash

Filed under: All, LDAP No Comments
6Apr/100

Getting started with your new LDAP server

So now that you've had a chance to get started with your new cloud-based LDAP server...  (you have fired it up, right?  If not, check out this post for more details on how you can have your own LDAP server running in 10 minutes or so!)

Some of the most common uses of LDAP are for centralized authentication, say, for a group of Linux servers in your office, or perhaps for a company-wide address book.  Today, we'll talk about just getting some basic user data into your directory server.  Next time, we'll tackle the attributes required for Linux authentication.

So, assuming you have followed the directions (found here), you should be able to bring up a browser and use the phpLDAPadmin tool to add a few new entries to your OpenDS instance.  The URL will be something like:  http://ec2-123-34-45-56.compute-1.amazonaws.com/pla   After logging in as the directory manager account (cn=directory manager, default password is dirmgr123), you should see one lone entry, called "o=root".  That's the top of your directory -- all the other groups and entries will be below here.  So, first, let's create two groups, or organizational units.  The first we'll call "ou=people', and the second "ou=groups".  Should be pretty self-explanatory as to what types of objects go into which group...

Using the phpLDAPadmin interface, click on the 'o=root' entry.  One of the options is 'Create a child entry' -- click there, and then choose 'Generic: organisational unit' from the available options.  Type 'people' into the text box, and click 'commit' when prompted if you want to create this entry.  That's it.  Now you've got a new organizational unit into which you can add accounts for people in your organization.

Next we'll create the 'ou=groups' container, but this time, we'll use a different method.  Click on the 'import' icon in the left-hand menu of the phpLDAPadmin screen, and paste the following lines into the text area:

dn: ou=groups,o=root
objectclass: organizationalUnit
objectclass: top
ou: groups

After clicking the 'Proceed' button, you should see a success message like 'Adding ou=groups,o=root Success'.  Also, you can now see in the left-hand menu a new container called 'ou=groups' under the root entry.  Pretty easy stuff.  The LDIF syntax lets you easily add many objects at once, without having to manually create each through the GUI of phpLDAPadmin.

Now that you have created these two containers, let's add one sample user into the people OU.  For our guinea pig, let's use the LDIF method.  Click the 'import' icon, and paste the following into the text area.  Replace values as you see fit:

dn: uid=jsmith,ou=people,o=root
givenname: Joe
sn: Smith
cn: Joe Smith
uid: jsmith
telephonenumber: 123-555-1234
objectclass: top
objectclass: person
objectclass: inetorgperson
dn: uid=jsmith,ou=people,o=root
givenname: Joe
sn: Smith
cn: Joe Smith
uid: jsmith
telephonenumber: 123-555-1234
userpassword: secret 
objectclass: top
objectclass: person
objectclass: inetorgperson

That's it.  Now you've added your first LDAP account -- you should be able to browse to it and view the object with phpLDAPadmin -- it's under 'ou=people'.

Continue to populate data into your LDAP server.  Next time we'll look at how you can start to use it for getting something done, like centralized authentication in Linux.

Filed under: All, LDAP No Comments
22Mar/100

OpenDS 2.2 cloud-based LDAP server available!

The newest, easiest way to get an LDAP server up and running is now here!  No more buying hardware, hoping it will provide enough capacity for your growing needs, no more configuring software and all the headaches caused by prerequisites for this package, or versions needed by that package.  In a matter of minutes, you can have your own hosted LDAP server up and running, ready to be populated with your own data.

Based on Amazon's Elastic Compute Cloud, the new OpenDS 2.2 image from Conklin Technology Group is running openSUSE 11.2, with Sun's open-source OpenDS 2.2.0 software.  In addition, you'll get the phpLDAPadmin tool pre-configured so you can easily manage your new server.

To sign up, you can use the following URL:  https://aws-portal.amazon.com/gp/aws/user/subscription/index.html?ie=UTF8&offeringCode=C831E696

For additional information to help you get started, check out the detailed documentation available here: http://conklintechnology.com/site/services/opends-2-2-ami/

Filed under: All, LDAP No Comments
16Mar/100

Hosted LDAP server from Conklin Technology

Conklin Technology Group is proud to announce a new cloud-based LDAP server, running in Amazon's Elastic Compute Cloud (EC2), available soon!

With this new product, you can easily have your own LDAP server up and running in a matter of minutes, all of the configuration has been completed already. Simply power on the machine, and you're off and running. The underlying products include OpenDS 2.2, as well as phpLDAPadmin for managing your new instance. All of the software is pre-installed, and allows you to get started quickly.

So stay tuned, in the next week or so, the service will be available through Amazon's web services site. If you haven't already signed up for Amazon's EC2 service, you might want to do it now, to familiarize yourself with their offerings.

Filed under: All, LDAP No Comments
5Mar/100

The future of Sun Directory Server

Well, now that Oracle's purchase of Sun has been finalized, it raises some interesting questions about the future of Sun's products, especially in overlap areas, like Java application servers, Sun Directory, OpenSSO, etc.

Thankfully, Oracle has posted several Webcasts with Sr. VP Hasan Rivzi, detailing many of the future roadmap decisions, which products will be strategic, how long Oracle will provide support for Sun's products, etc.

The identity management strategy webcast can be viewed here:

http://oracle.com.edgesuite.net/ivt/4000/8104/9236/12628/lobby_external_flash_clean_480x360/default.htm

18Nov/091

Microsoft’s Next Generation Active Directory

Infoworld.com is reporting that Microsoft has announced a new technology that they're calling "Next Generation Active Directory".  It's a "clip-on" -- whatever that means -- that allows directory data to be stored in a SQL database and allows developers to query that data for complex relationships that would normally be difficult, if not impossible, to pull from AD (more accurately, via LDAP queries). 

I'd have to read some more about the new software, and how they're proposing to update the underlying directory data through this "clip-on".  But part of the advantage of LDAP-based directories is that they're *not* relational databases...  It will be interesting to see how Microsoft plans to marry these two technologies and what the real benefit  is for end-users and developers.

4Nov/090

Combining dynamic and static groups

After my previous post, I've been trying to figure out some solutions to the scenario I presented (a dynamic email group with opt-in/opt-out capabilities). I got some good suggestions from Matt Flynn and will have a subsequent post with some commercial tools that provide end-user self-service for things like distribution list management in AD or LDAP.

My bigger concern, though, was trying to prove out my little quasi-code example in Sun Directory Server. While the software supports dynamic groups, defined with an LDAP search URL, it seems to be client-specific as to whether those dynamic URLs in the group definition are actually followed (meaning, the users matching the URL filter are returned to the client). I was unable to get a command-line ldapsearch query to successfully return all the members of a dynamic group (suggestions, anyone?). However, by using a combination of managed and filtered roles, instead of groups, it was quite easy to accomplish this.

First, you can define a managed (static) role and manually assign users in. This could be your "opt-in" group -- those users who would like to receive an email newsletter, for example, but would not normally be included automatically based on degree or major or what have you. With a self-service tool, users could add themselves into this managed role as a sort of 'subscribe' functionality.

Secondly, if needed, you could assign an attribute for the opt-out capability. Unfortunately, you can't use the 'nsRole' calculated attribute as part of the filter in the definition of another role. But there are certainly ways around this limitation (extend the schema to include an attribute called 'optout' with the value of the list name, or just use an existing attribute like 'memberof' with a value of your choice). You also can't use the 'isMemberOf' attribute (which is used to return all the static group memberships for a particular user), because, again, this is a calculated attribute.

For reference purposes, here is the filtered role definition I used for testing my example:
nsRoleFilter: (&(sn=Black)(!(memberof=optout_dllist)))

(All users with a last name of "Black", EXCEPT for those who have a memberof attribute set to "optout_dllist")

Once the filtered role is defined, you can then create a nested role with the managed (static) role you created for 'opt-ins', along with the filtered role with users matching a particular criteria (and optionally, excluding those who may have opted out) After the nested role has been defined, you can simply query a given user for the 'nsrole' attribute to see which roles they belong to, or search directly against the 'nsrole=nested_role_dn' to show all the members of the role. Note that you must explicitly ask for the nsrole attribute in an ldapsearch command -- just doing a normal search against a user's attributes will not show their role memberships.

And to save you some of the same headaches that I went through, since a role is defined as a subentry, it is not returned in a normal ldapsearch command. You must specifically ask for them using a search filter like :
"(&(objectclass=nsManagedRoleDefinition)(objectclass=ldapSubEntry))"

For additional information about Roles in SUN DSEE 6.3, the documentation is here.