Novell is now a part of Micro Focus

LUM-enabling eDirectory Users

Novell Cool Solutions: Feature
By Aaron Burgemeister

Digg This - Slashdot This

Posted: 10 Jan 2007


A Forum reader recently asked:

"I have three questions when using eDirectory 8.8.

1. I import posixAccount, shadowAccount, Account Attributes and Object classes to nds via ConsoleOne, and it seems to be successful. Then I configure eDirectory as the LDAP server on the other Linux machine. Yes, I could run 'ldapsearch -x' to list all NDS users, but when I use 'id' or 'getent' to verify the nds users have been added to posixAccount, shadowAccount, and Account as its extension objects, running the above command returns nothing. I think that's because they're not valid Linux users. So, my first question is how to make NDS users as valid Linux user?

2. Does NDS support simple authentication by SSL? Is TLS the default setting in NDS?

3. I wonder whether "pam_passwd clear" being mofidied to "pam_passwd nds" in the configuration file would be a better choice."

And here's the response from Novell's Aaron Burgemeister ...


First, /etc/ldap.conf is not in any way related to eDirectory, so you shouldn't configure it. That is for OpenLDAP, which is definitely not the same.

"ldapsearch -x -D cn=admin,o=novell -W" is probably a good command for you to run. It sounds like you have already tried to make the eDirectory users LUM (Linux User Management)-enabled manually, but just to be sure let me go into that.

LUM-enabling a user involves extending their eDirectory objects with a couple Auxiliary Classes, including posixAccount and uamPosixUser. Doing so requires that you also add some mandatory attributes, including loginshell (/bin/bash), homeDirectory (/home/userNameHere), uidNumber (601), gidNumber (600), and probably other things. The key to all of this is that, usually, iManager is used. There is a role specifically for doing LUM-y things. Some other keys to LUM-enabled users include their membership in a LUM-enabled group (the gidNumber assigned to the user is also the gidNumber of that group) and that group being associated with the Linux Server (or workstation) to which you are trying to authenticate. The LUM plugins in iManager make this all quite painless.

Another key to all of this is that all Workstations must be associated with the "Unix Config" object, which is somewhere in the tree and is usually installed by the first Linux OES server (or the first LUM-happy server if not OES). Once you know how to do all this it's simple enough.

When a user is LUM-enabled it will look similar to the following (via LDAP):

# test000000, finance, novell, org
dn: cn=test000000,ou=finance,o=novell,dc=org
loginShell: /bin/bash
homeDirectory: /home/test000000
gidNumber: 600
uidNumber: 601
uid: test000000
sn: test000000lname
securityEquals: cn=admingroup,dc=user,dc=system
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top
objectClass: posixAccount
objectClass: uamPosixUser
groupMembership: cn=admingroup,dc=user,dc=system
cn: test000000
ACL: 2#subtree#cn=test000000,ou=finance,o=novell,dc=org#[All Attributes
ACL: 6#entry#cn=test000000,ou=finance,o=novell,dc=org#loginScript
ACL: 2#entry#[Public]#messageServer
ACL: 2#entry#[Root]#groupMembership
ACL: 6#entry#cn=test000000,ou=finance,o=novell,dc=org#printJobConfiguration
ACL: 2#entry#[Root]#networkAddress
ACL: 2#entry#[Public]#uidNumber
ACL: 2#entry#[Public]#gidNumber
ACL: 2#entry#[Public]#loginShell
ACL: 2#entry#[Public]#homeDirectory
ACL: 2#entry#[Public]#gecos
ACL: 2#entry#[Public]#groupMembership
ACL: 1#entry#[Public]#cn

This is a fairly plain-Jane LUM user. Notice the ACLs I forgot to mention above. All LUM users have assignments for [Public] to be able to see a few attributes so that Linux can query them without a proxy user. This could be avoided with the proper use of proxy users I suppose, but that seems to eliminate the need, doesn't it? Otherwise this object has a loginShell, homeDirectory, ACLs, uidNumber, gidNumber, etc. The corresponding group (admingroup as you can also is a member of that group via eDirectory) has a gidNumber of 600.

So now to the server/workstation. Simply having posix enabled is not enough. It may work, but you should use the LUM packages. "rpm -qi novell-lum" should return some informaton about the LUM package if it is installed. Also you should have a service called "namcd" running (/etc/init.d/namcd status). This comes with the LUM RPM and does some really neat things.

So in /etc/pam.d you should have a bunch of files including login, shadow, sshd, and su all with the following lines at the top (taken from pam_nam_sample in that same directory):

auth      sufficient
account   sufficient
password  sufficient
session   optional
These lines tell pam to use nam (LUM) for logins to the box, and for su, ssh, and other things as you add them (xdm is in there for GUI-ish thing, should you want that). Those take effect immediately once you have the lines in those files. It's nice not to need a reboot just to affect login possibilities. Also your /etc/nsswitch.conf file should have a couple of additions. Two lines in there starting with 'passwd' and 'group' should change from:
passwd: compat
group:  compat


passwd: compat nam
group:  compat nam

Sometimes those actually say 'files' instead of 'compat', and I can't honestly tell you the difference, but I always use 'compat nam' and life is good. If you have things configured nicely (the LUM RPM is installed), you will have an /etc/nsswitch.conf.nam file to help you with this stuff in the nsswitch.conf file.

So now let's review:

  • "namcd" is running.
  • "nsswitch.conf" is happy.
  • "/etc/pam.d/*" are all good.
  • A user is LUM-enabled.
  • A group is LUM-enabled.
  • A workstation/server object exists in the tree (if you haven't done this you can create this with 'namconfig add' once you have the LUM RPM on your box) linked to your Unix Config object, and life is good.

Assuming all is well, things should be working much better. PAM and nsswitch.conf know that a login can come from pam_nam, which gets information from namcd. namcd is configured with a user (who has adequate rights) in the tree and finds the users who are good for this workstation/server. eDirectory sends users over and even sends changes (passwords, etc.) back to the box as they happen. namcd caches those, so if a router/switch blows up, users can STILL log in to the LUM-enabled workstation/server (password information is all happily encrypted so no worries there ...)

For more information, try this Cool Solutions article:

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates