A Forum reader recently asked:
"We are starting the rollout of Universal Password, and I have a couple of questions. We're using NetWare 6.5 SP5 servers, XP SP2 clients, and IDM 3.01 - all clients have NMAS enabled. I have applied the password policy to several containers, and it is working fine. I'll apply it to the Login Policy.Security instead, once we're over the rolling-out-slowly phase.
I have heard/read conflicting messages about being able to use ConsoleOne to manage UP passwords vs. using iManager's IDM password plug-in. When we tried using ConsoleOne to change something also set in the password policy, the next time the user logged in, it followed the password policy and reverted the ConsoleOne entry. Do we have to use iManager for now on for password resets?
We also use Groupwise and use ConsoleOne to create users. So, do we have to use two utilities - ConsoleOne to create accounts and then iManager to do password resets - or can one do both? Or, could we maybe create users, including GroupWise accounts, in iManager too, and not use ConsoleOne any more to manage users?"
And here are the responses from Aaron Burgemeister and Marcel Cox ...
ConsoleOne works fine for a couple of things, assuming that the NMAS client is installed on the box from which ConsoleOne is running. Those things include:
- Changing passwords (must set according to policy no matter who you are) for users
- Setting expiration dates closer to the present (more-restrictive)
- Setting grace logins (available) to a smaller number (changing the maximum number is not allowed, I don't think)
ConsoleOne CAN change the expiration date to be farther into the future, or increase the maximum number of grace logins, or change the expiration interval (days between password expirations). HOWEVER, those numbers will be reset to their more-secure values (according to what NMAS calculates they should be) as soon as the user logs in again via NMAS. This means that when a manager asks you to make it so their password doesn't expire for another month, you can do so - but when they log in again the restrictions will be back.
NMAS will let you make things more restrictive than the policy is, but not less restrictive. Expiring a password for a terminated employee is allowed, but extending a password's availability (without them changing it) is not. eDirectory defaults toward security. If somebody needs passwords to expire less frequently, they should have a policy assigned to them for that purpose. (Why use policies at all, which keep things like groups of users organized, if you're going to just trump them all the time?)
ConsoleOne should not be used for any kind of UP policy management (passwords, yes; policies, no).
iManager behaves the same way (set passwords, expire passwords sooner, etc.) as ConsoleOne. It also has the plugins that allow it to manipulate, create, delete, and assign the password policies.
So in your environment, assign your UP policies to the Login Policy Object (LPO) and use ConsoleOne for creating users, setting passwords, etc. GroupWise iManager plug-ins do not exist.
eDirectory 8.7.x comes with NMAS plug-ins for ConsoleOne, and that means that the ConsoleOne as it is on a NetWare 6.5 server will have those plug-ins. However, there are some .DLL version conflicts between ConsoleOne and the latest Novell clients that cause the NMAS functionality of ConsoleOne to fail. To avoid this issue, you must delete some files in the ConsoleOne directory structure as explained in the following TID:
Note that even with the NMAS plug-ins, you still can't manage Universal Password from ConsoleOne. However following the recommendations from the TID prevents you from getting errors when doing certain operations such as setting the simple password. With a Novell client with NMAS support installed, all NDS password change from ConsoleOne will automatically perform a Universal Password change if there is a policy requiring Universal Password.
For the best possible Universal Password experience, make sure you have the Security Services 2.04 package installed. You will find it here:
I don't know if you have been using any of the SS20x updates, but the SS20x updates make the NDS and Universal Password behavior more consistent with each other.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.