On 01/13/2014 09:14 AM, dschaldenovell wrote:
> What is the issue they were having as they attempted this, exactly?
> What
> was the issue last time? Was the user LUM-enalbed already? How were
> they
> attempting to add it to the group?
> From what I understand they were trying to add the user to a LUM enabled
> Group through iManager. They used C1 to add the user to become a member
> of group that was the admin group. Then they used iManager to LUM enable
> the user. From what I have seen there were (are) some prior LUM
> attributes left over on this user. Currently when looking at the user we
> see that they still have a Primary group listed. Which if they were
> removed cleanly they should not be having.

It's probably better to add the user to the group in the first place via
iManager. I thought, but have not tested in along time, that it would
handle the LUM-ification process at that time if you did so, where
ConsoleOne has no clue about that so it will not. Just a thought...

> Which attributes? Were any LUM attributes populated properly (vs.
> none)?
> Again from what I have understood there was (were) some attributes
> populated correctly. Basically just enough to report in iManager that
> the user was successfully LUM enabled, but not enough to get any
> response when doing an id <username>

Interesting. I do not suppose you have exports of the object via LDAP
before/after happened, do you? In order to really be seen by PAM you need
things like the UID, uidNumber, gidNumber, loginShell, and homeDirectory
and I think that it is. To have most of these the user will be extended
with one or two aux classes (I think two). If iManager is just looking
for the aux class then that may be why some attributes were missing, but
it's hard to speculate in a way that matters without real data.

> Which attributes were cleaned forcibly? Using ndsdump just to clean up
> a
> few users' attributes seems like overkill since, usually, attributes
> can
> be cleaned up using any of the standard tools.
> From the previous effort, the Engineer (BL) removed all attributes for
> the LUM enabling process, basically just took a cannon to the user and
> using DUMP was able to remove all the attributes and when the LUM
> procedure was started again the user(s) went through without any further
> issue. What standard tools could be used?

Any tools can be used to add/remove almost any attribute from any object,
assuming you have rights. iManager and ConsoleOne are the
Novell/NetIQ-specific ones, but I'd just use a good LDAP tool like Apache
Directory Studio since it shows the objects simply and lets you remove
attributes in a nice little GUI (right-click, Delete value).

> Care to share the various environment details, particularly the ones
> that
> the TID would have you check? For example, SLES/OES version/patches,
> iManager version (if it is being used), the plugin version? Is this
> always repeatable, or just sometimes? How are they made aware that
> there
> is a problem in the first place (error, missing functionality once
> LUM-enalbed, etc.)?
> Version of SLES SLES10 SP4
> Version of OES2SP3
> iManager version 2.7.4
> Plug-in was version 2.2.0
> Basically they know the user is not working when they are not seeing the
> id <username> reports nothing. Nor are they (user) able to ssh into a
> box

When this happens I suppose I would watch LDAP (via ndstrace) to see if
the server is querying for the object and, if it is, what is being sent
back from eDirectory, if anything. This used to happen in cases where the
user's login was done with something like 'ab' when the actual attribute
value in eDirectory was 'Ab' so only the case differed. I believe namcd
(the process that does this user management in OES) now allows you to tell
it that usernames are case-insensitive so that helps, but fixing the UID
attribute in eDirectory to always have the correct (lower) case is usually
the best way to take care of these things. Generally things like
usernames should always be lower case in the backend anyway, so updating
those throughout the environment may be a good thing to work on if not
known to be consistent already.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...