Quote Originally Posted by dgersic View Post
I know the official definition ("Unique identifier for portlet.") from the documentation (https://www.netiq.com/documentation/...a/b2ighzf.html).

I know, by experimentation, that it is created by RBPM on first login by the user, and written to the user object.

I can see that it is some string of characters, likely intended to be globally unique based off of something.

What I need to know, and have yet to find, is what is it used for. Why does this attribute exist, what uses it, and what might break if I remove it from the user.

If it matters, the UserApp in use is 4.02 Patch E. (Yes, I know there's newer, and yes, upgrade would be nice. $CLIENT is not going to upgrade, is not interested in upgrading.)
Hm, lots of views, but no answers. Maybe I should have titled this "UserApp breaks NMAS".

So I'm working at a client with UserApp 4.02 Patch E, and they're having sporadic problems where users can't authenticate to SSPR to change their password. This is front ended by NAM, so it's a bit hard to see what's going on, but digging in to it, I found that if I try to retrieve an affected user's password with dumpuniversalpassword.jar, I get an NMAS error -1665.

Searching for that error led me to TID 3364214 (https://www.novell.com/support/kb/doc.php?id=3364214), though not the cause of the problem. When the NDS Password (Private Key / Public Key) is newer than the Universal Password, the user gets an NMAS error when trying to log in. I do like how it notes that "this should never happen". If I try to examine their Universal Password status, I see NMAS error -1665. I can see in iMonitor when then last password change was (pwdLastChanged) and what the timestamp on the Public Key is, confirming that this is what NMAS is complaining about.

In this client's configuration, NDS Password should not even exist. The Universal Password policy does not have the "Set NDS password" option turned on, and they are only using Universal Passwords.

I cannot explain why, but the UserApp is using NDS Passwords. On first login to UserApp (open the "work dashboard"), three attributes are written to the User object: srvprvUUID (documented as being a unique user ID for the portal), Private Key, and Public Key. Private Key + Public Key are NDS Password.

So what happens for a new user is that the account is created. The initial password (Universal Password only) is set. The user at this point can go to login.company.com and log in (NAM). They can go to the "set password" (SSPR) link, and set up their challenge questions and set their password. All that works fine. They can log out, and log back in.

As long as they dont go to the "work dashboard" (UserApp) link, theyre fine. If they do, srvprvUUID, Public Key, and Private Key are written to their object. At this point, they can no longer log in at login.company.com. It looks, to the end user, like a password problem. They know what their password is, but it wont let them in. After a while, they call the helpdesk, and get their password reset. This works, not because they didnt know what their password was, but because now their Universal Password is newer than their NDS Password. From then on, theyll be fine. Nothing ever updates their NDS Password, so their Universal Password is always newer than their NDS Password, and everything is happy.

The simplest fix for this, which Im testing now, is to enable NDS Passwords in the Universal Password policy. I should not have to do this, IMHO, though it does seem to work because then NMAS sets the NDS Password, keeping the UP newer than the Private / Public key pair.

To clean up affected accounts, I created a temporary IDM driver that whacks the Private Key, Public Key, and srvprvUUID attributes on a user. I dont know what the side effects of removing srvprvUUID are going to be, though. I suspect that is probably a link attribute used in the Oracle database to identify the user within the UserApp. So I really kinda want to know, what is srvprvUUID, how is it generated, is it ever updated? And what happens if I remove it? Or, maybe I should leave it there, and just whack the Private/Public Key pair.