Anonymous_User Absent Member.
Absent Member.
852 views

eDir to eDir - Unable to set NMAS password


Hello,

So, all of a sudden, one users password is not syncronized from one eDir
to the other. The password is syncronized to AD though. It is only to
the other eDir the problem exists. I get this error:

Code(-8021) Unable to set NMAS password: -1658 NMAS_E_MISSING_KEY.

Google'ing this problem gives nothing exept the explenation of the error
by Novell:

-1658 FFFFF986 NMAS E MISSING KEY
Source: NMAS
Explanation: The key attribute for the Login Configuration attribute or
the Login Secret attribute is missing or
corrupt.
Action: Contact a “Novell Support Provider” on page 8.

I then took a look at what the "Login Configuration attribute" and
"Login Secret attribute" do. They are for the challenge-response
questions. So i tried deleting these attributes on the user, and sure
enough, he has to type in new questions when he logs into the UA. The
error still persist if he attempts to change his password afterwards.

I've tried driver restarts, eDir restarts, ndsrepair and a couple of
other things, with no luck.

Any ideas?

Jacob.


--
jacmarpet
------------------------------------------------------------------------
jacmarpet's Profile: https://forums.netiq.com/member.php?userid=415
View this thread: https://forums.netiq.com/showthread.php?t=47837

Labels (1)
0 Likes
11 Replies
Anonymous_User Absent Member.
Absent Member.

Re: eDir to eDir - Unable to set NMAS password

Keys are used all over in eDir to encryption of data. It seems possible
to me that this error, while originally for other things in NMAS that use
keys, also now covers (without having its documentation updated) password
keys. With that said, the keys in use exist in a few different forms,
none of which ndsrepair will "fix" since their absence isn't something
ndsrepair cares about, and their corruption wouldn't cause this error.

A few details may help, including a trace of the side generating the
error, which is presumably the destination/receiving tree/server:

eDir version on the server receiving changes from IDM
Verification that the server holds a full read/write or Master replica of
the partition holding the user, and if not, a lot of details on why not
and what is there.
Can an administrator set this user's password directly? Before trying
this perhaps grab an eDir DIB/backup so that if you want to do more
checking later you can put it in a test environment and do so there, or
send it to Novell/NetIQ for analysis.
User history: Has this user ever had a password change before via IDM?
Recently? Frequently and regularly? These are to find out why/when this
started as much as possible.
Does the Universal Password (UP) policy set for this user match the ones
set for other users who work? Shouldn't matter, but it's good to know.
Use iManager's Password: View Policy Assignments task to verify which
policy is really applying to the user.

Good luck.
0 Likes
Knowledge Partner
Knowledge Partner

Re: eDir to eDir - Unable to set NMAS password

On 5/27/2013 12:14 PM, jacmarpet wrote:
>
> Hello,
>
> So, all of a sudden, one users password is not syncronized from one eDir
> to the other. The password is syncronized to AD though. It is only to
> the other eDir the problem exists. I get this error:
>
> Code(-8021) Unable to set NMAS password: -1658 NMAS_E_MISSING_KEY.


My experience in this, is that some tool, was used to write to eDir that
does not properly understand the sasLoginConfiguration* attributes, and
for some reason touches them.

Alas, my favorite LDAP tool, LDAP Browse/Edit (LBE) does this. If i
modify an attribute unrelated to passwords with LBE, then the user will
have issues with passwords and 1658 errors.

One sure way to diagnose this, is to get Jim Willeke's UP Tool

http://ldapwiki.willeke.com/Wiki.jsp?page=DumpEdirectoryPasswordInformationTool

Then, call it in a BAT/sh file, like:

java -jar DumpPasswordInformation.jar -h hostIP -Z SSL -p 636 -D
cn=admin.ou=user,o=com -w password -A -v -E -S cn -V %1


That will search for your user, (-V and then -S cn to search by CN
(maybe uid makes more sense for you, whatever).

The output will give it away. A normal user will output:

dn: cn=geoffc,ou=people,dc=willeke,dc=com
Password: secretvalue
Does Current password meet password policy assigned to user? true
===> Password Status <===
==> Universal Password <==
Is UPwd Enabled: true
Is the UPwd history full: false
Does UPwd match NDSPwd: true
Does UPwd match SimplePwd: false
Is UPwd older than NDSPwd: false
==> Simple Password <==
Is Simple Password Set: false
Is Simple Password Clear Text: false
Does Simple Password match NDSPwd: false
==> Account Status <==
Is Entry Account Disabled: FALSE
Is Account Intruder Locked: FALSE
Login Time: 20090618002926Z

A user with the 1658 problem will output a shorter version, more like this:

dn: cn=geoffc,ou=people,dc=willeke,dc=com
Password: secretvalue
Does Current password meet password policy assigned to user? true
===> Password Status <===
==> Account Status <==
Is Entry Account Disabled: FALSE
Is Account Intruder Locked: FALSE
Login Time: 20090618002926Z

Dead giveaway of the issue.


> Google'ing this problem gives nothing exept the explenation of the error
> by Novell:
>
> -1658 FFFFF986 NMAS E MISSING KEY
> Source: NMAS
> Explanation: The key attribute for the Login Configuration attribute or
> the Login Secret attribute is missing or
> corrupt.
> Action: Contact a �Novell Support Provider� on page 8.
>
> I then took a look at what the "Login Configuration attribute" and
> "Login Secret attribute" do. They are for the challenge-response
> questions. So i tried deleting these attributes on the user, and sure
> enough, he has to type in new questions when he logs into the UA. The
> error still persist if he attempts to change his password afterwards.
>
> I've tried driver restarts, eDir restarts, ndsrepair and a couple of
> other things, with no luck.
>
> Any ideas?
>
> Jacob.
>
>


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir to eDir - Unable to set NMAS password


Thanks for the thorough reponse. I'll attempt to answer as many of your
questions as possible:

1. eDir version of the tree where the users sets his password(in UA for
example): eDir 64bit v8.8 SP7.
2. eDir version of the tree where the password is attempted to be synced
to: eDir i586 v8.8 SP6.
3. Both servers have full read/write.
4. If i, as admin, change the users password the error also happens.
5. The user has been in the system for many year, just like many other
users. The password has been changed many times without problems.
6. The problem started this friday, when the user attempted to change
his password through the Novell Client(Novell Client for Windows 4.91
SP2). He has done this many times before.
7. The universal password policy is the same in both trees, and that
specific user is on the same policy as everyone else.
8. I have had a couple of other people change their passwords, both
through the Novell Client(Novell Client 2 SP2 for Windows 7) and through
the UA, and also myself changing my own password through both of those
and as admin, with no problems. It is only that specific user that
suddently has this problem.
9. Novell nmas version on eDir where i try to change the password: nmas
3.3.4.0-20120419
10.Novell nmas version on eDir where i try to change the password: nmas
3.3.0.3-20100914
11. I just tried changing the password of the user in the OTHER tree
from COnsoleOne. I get this error: -319 FFFFFEC1 SYSTEM ERROR - this
looks like it could be a problem with the Novell Client, but again, he
does actually not get that error when he changes his password. It just
goes through, and then i get the earlier presented error in the eDir
drivers(both of them). But I get the -319 FFFFFEC1 SYSTEM ERROR when i
try to change his password as admin, in the OTHER tree.
12. If i look in the DStrace i find this error:

ERROR: -1418 GetXKeyFromValues: CCS_UnwrapKey
23:06:57 BEEBEB70 NMAS: ERROR: -1418 GetXKeyFromValues: CCS_UnwrapKey
23:06:57 BEEBEB70 NMAS: NMAS Audit with Audit PA not installed
23:06:57 BEEBEB70 NMAS: NMAS Audit with XDAS not installed
23:06:57 BEEBEB70 NMAS: ERROR: -1658 Failed set distribution password
for tg.xx.xx

13. I have then tried your tool geofcc and it outputs:

Password: Entry has no Universal Password value (-16049)
Password policy assigned to user: cn=POL-PWD-ITQ,cn=Password
Policies,cn=Security
Does Current password meet password policy assigned to user? NMAS
Return Code (-1665)
===> Password Status <===
==> Universal Password <==
Is UPwd Enabled: true
Is the UPwd history full: false
Does UPwd match NDSPwd: false
Does UPwd match SimplePwd: false
Is UPwd older than NDSPwd: true
==> Simple Password <==
Is Simple Password Set: false
Is Simple Password Clear Text: false
Does Simple Password match NDSPwd: false
==> Account Status <==
Is Entry Account Disabled: FALSE
Is Account Intruder Locked: FALSE
Password Expiration Time: 20130825210657Z
Grace Logins Remaining: 6
Login Time: 20130527212541Z

My head hurts!


--
jacmarpet
------------------------------------------------------------------------
jacmarpet's Profile: https://forums.netiq.com/member.php?userid=415
View this thread: https://forums.netiq.com/showthread.php?t=47837

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir to eDir - Unable to set NMAS password

On 05/27/2013 03:44 PM, jacmarpet wrote:
> ERROR: -1418 GetXKeyFromValues: CCS_UnwrapKey
> 23:06:57 BEEBEB70 NMAS: ERROR: -1418 GetXKeyFromValues: CCS_UnwrapKey


Well there you go... something amiss with NICI. Have you added a server to
your tree lately? Done anything with the sdidiag tool? One of the keys
(the tree key, specifically) used to encrypt Universal Password stuff
(among other things, including the SAS attributes you found earlier) is
managed by NICI/SDI. If you lose a key, or if your user had their
password set previously with a key that is available on serverX (where the
change previously happened) but not serverY (where it's currently trying
to happen) then bad things can happen. There was a bug several years ago
related to this for when tree keys were missing and functionality changed
to just ignore that condition since, basically, it meant that the old
password value (in that case stuck in the password's history) could never
be decrypted so it was lost forever... might as well let things move on
rather than failing entirely. Still, that was fixed years ago, well
before 8.8 SP6 or SP7.

Well there are options for you... rmupwd it s tool from Novell that will
let you strip out password history (I presume you use it) or even the
Universal Password value for that user from this tree, and then you can
resynchronize the password from the other tree, or have the user change
their password again, or change it as an admin if you know what the
password is they are trying to use currently. If this works then you know
tree keys were an issue. Use sdidiag to get output on tree keys from all
servers in the tree (one tree at a time, don't mix/match trees) and then
use tkinfo (shameless plug) to get a bit of output from the process.txt
file generated:

http://www.novell.com/coolsolutions/tools/16574.html

TID# 3455150 is the one you want to generate the process.txt file, btw.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir to eDir - Unable to set NMAS password


Okay. So I ran the sdidiag on both trees, and the keys are fine
according to the output below:

Tree 1:

Password :
SDIDIAG> CHECK
*** [Key Consistency Check - BEGIN] ***
[Checking SDI Domain]
SDI Check Domain Configuration...
SDI Domain Key Server .itq-meta04.service.ITQ.META01TREE.
- Configuration is good.
SDI Domain Key Server .itq-meta03.service.ITQ.META01TREE.
- Configuration is good.
SDI Domain Key Server .itq-meta02.service.ITQ.META01TREE.
- Configuration is good.
SDI Domain Key Server .itq-meta01.SERVICES.ITQ.META01TREE.
- Configuration is good.
*** SDI Check Domain Configuration is [GOOD]
SDI Check Domain Keys...
SDI Domain Key Server .itq-meta01.SERVICES.ITQ.META01TREE.
- Keys are good.
SDI Domain Key Server .itq-meta04.service.ITQ.META01TREE.
- Keys are good.
SDI Domain Key Server .itq-meta03.service.ITQ.META01TREE.
- Keys are good.
SDI Domain Key Server .itq-meta02.service.ITQ.META01TREE.
- Keys are good.
*** SDI Check Domain Keys are [GOOD]

[Checking SDI Domain: GOOD]

*** No Problems Found ***

*** [Key Consistency Check - END] ***

------------------------------------------------------------------------------------------

Tree 2:

Password :
SDIDIAG> CHECK
*** [Key Consistency Check - BEGIN] ***
[Checking SDI Domain]
SDI Check Domain Configuration...
SDI Domain Key Server
..kbh-sles05.SERVERE.SERVICES.KBH.ITQ.ITQTREE.
- Configuration is good.
SDI Domain Key Server
..kbh-dsfw01.OESSystemObjects.ITQ.ITQTREE.
- Configuration is good.
SDI Domain Key Server
..kbh-oes03.SERVERE.SERVICES.KBH.ITQ.ITQTREE.
- Configuration is good.
*** SDI Check Domain Configuration is [GOOD]
SDI Check Domain Keys...
SDI Domain Key Server
..kbh-oes03.SERVERE.SERVICES.KBH.ITQ.ITQTREE.
- Keys are good.
SDI Domain Key Server
..kbh-sles05.SERVERE.SERVICES.KBH.ITQ.ITQTREE.
- Keys are good.
SDI Domain Key Server
..kbh-dsfw01.OESSystemObjects.ITQ.ITQTREE.
- Keys are good.
*** SDI Check Domain Keys are [GOOD]

[Checking SDI Domain: GOOD]

*** No Problems Found ***

*** [Key Consistency Check - END] ***


--------------------------------------------------------------------------------------

I cant use CODE tags for some reason. Continue in next post...


--
jacmarpet
------------------------------------------------------------------------
jacmarpet's Profile: https://forums.netiq.com/member.php?userid=415
View this thread: https://forums.netiq.com/showthread.php?t=47837

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir to eDir - Unable to set NMAS password


I then ran the rmupwd utility in the tree where I was not able to change
his password as admin. It seems like it's his object in this tree that
is troublesome. It had no effect. I still can't change his password in
that tree and when I attempt to from the other tree, I get the good old
error in the eDir driver as always. I then tried the rmupwd in the other
tree. No luck. Then in both trees, no luck. Argh!!


--
jacmarpet
------------------------------------------------------------------------
jacmarpet's Profile: https://forums.netiq.com/member.php?userid=415
View this thread: https://forums.netiq.com/showthread.php?t=47837

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir to eDir - Unable to set NMAS password

Yes.... and this is not a process.txt file, and you did not run the
command to generate one. Doing a single-server check isn't that useful.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir to eDir - Unable to set NMAS password


Sorry, I didn't think the process.txt was so important since I could see
the output from the sdidiag. I've followed these two guides to create
the process.txt:

http://www.novell.com/support/kb/doc.php?id=3455150I
http://www.novell.com/support/kb/doc.php?id=3092072

I've created a process.txt on a server in each tree, and run the
tkinfo.pl tool. The output from the first tree:


Code:
--------------------

-----Keys On Servers Report-----
C7 3C B8 7C EE 77 8D 61 04 3B 10 74 FE 0A BD FE
.itq-meta03.service.ITQ.META01TREE. - Valid
.itq-meta01.SERVICES.ITQ.META01TREE. - Valid
.itq-meta02.service.ITQ.META01TREE. - Valid
.itq-meta04.service.ITQ.META01TREE. - Valid
4 out of 4 possible servers with this key valid.



-----Key Synchronization Report-----
Key ID: C7 3C B8 7C EE 77 8D 61 04 3B 10 74 FE 0A BD FE - 168 bits
No action needed: Valid.


-----Valid Key Report-----
Valid Keys:
C7 3C B8 7C EE 77 8D 61 04 3B 10 74 FE 0A BD FE - 168 bits

Revoked/Unsynchronized Keys:
None


-----Bad Servers Report-----
Your servers are well-behaved.


4 servers found total (non-bad NICI).
0 servers with broken or missing NICI. Note that having one of these will
prevent any keys from showing up as truly synchronized and valid.
1 keys total in environment.

--------------------


The other tree(the one where I can't change his password):


Code:
--------------------

-----Keys On Servers Report-----
40 FE E3 4F 2E 81 31 7B 53 E6 B1 88 67 C0 4A DD
.kbh-oes05.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.groupwise.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.kbh-sles05.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.kbh-oes04.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.kbh-oes03.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.kbh-dsfw01.OESSystemObjects.ITQ.ITQTREE. - Valid
6 out of 6 possible servers with this key valid.

40 C9 AC A4 15 24 70 85 2E 05 9A 5B 9E D3 48 FC
.kbh-oes05.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.groupwise.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.kbh-sles05.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.kbh-oes04.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.kbh-oes03.SERVERE.SERVICES.KBH.ITQ.ITQTREE. - Valid
.kbh-dsfw01.OESSystemObjects.ITQ.ITQTREE. - Valid
6 out of 6 possible servers with this key valid.



-----Key Synchronization Report-----
Key ID: 40 FE E3 4F 2E 81 31 7B 53 E6 B1 88 67 C0 4A DD - 168 bits
No action needed: Valid.

Key ID: 40 C9 AC A4 15 24 70 85 2E 05 9A 5B 9E D3 48 FC - 56 bits
No action needed: Valid.


-----Valid Key Report-----
Valid Keys:
40 FE E3 4F 2E 81 31 7B 53 E6 B1 88 67 C0 4A DD - 168 bits
40 C9 AC A4 15 24 70 85 2E 05 9A 5B 9E D3 48 FC - 56 bits

Revoked/Unsynchronized Keys:
None


-----Bad Servers Report-----
Your servers are well-behaved.


6 servers found total (non-bad NICI).
0 servers with broken or missing NICI. Note that having one of these will
prevent any keys from showing up as truly synchronized and valid.
2 keys total in environment.

--------------------


It all seems alright to me? Hmm!

Jacob.


--
jacmarpet
------------------------------------------------------------------------
jacmarpet's Profile: https://forums.netiq.com/member.php?userid=415
View this thread: https://forums.netiq.com/showthread.php?t=47837

0 Likes
Knowledge Partner
Knowledge Partner

Re: eDir to eDir - Unable to set NMAS password

> 8. I have had a couple of other people change their passwords, both
> through the Novell Client(Novell Client 2 SP2 for Windows 7) and through
> the UA, and also myself changing my own password through both of those
> and as admin, with no problems. It is only that specific user that
> suddently has this problem.


Those with Client32/2 the question will be about NMAS on the client of
course.

But without it, UP and NDS will drift (I.e. No NMAS client, a client32
password change will change NDS but not UP password, which the UP tool
from Willeke will detect), but not cause the seen symptoms.

> 11. I just tried changing the password of the user in the OTHER tree
> from COnsoleOne. I get this error: -319 FFFFFEC1 SYSTEM ERROR - this
> looks like it could be a problem with the Novell Client, but again, he
> does actually not get that error when he changes his password. It just
> goes through, and then i get the earlier presented error in the eDir
> drivers(both of them). But I get the -319 FFFFFEC1 SYSTEM ERROR when i
> try to change his password as admin, in the OTHER tree.


There is a C1 bug that is maddening. The original (and far far too
long) copies of C1 ship with a local copy of nmas.dll whose functions,
override the client NMAS and are ancient and do not work properly.
There is a TID you can follow to clean up your C1 instances. Of course,
if any helpdesk techs copied it local and use that, they need the fixes
as well.

http://www.novell.com/support/kb/doc.php?id=3576410


> 12. If i look in the DStrace i find this error:
>
> ERROR: -1418 GetXKeyFromValues: CCS_UnwrapKey
> 23:06:57 BEEBEB70 NMAS: ERROR: -1418 GetXKeyFromValues: CCS_UnwrapKey
> 23:06:57 BEEBEB70 NMAS: NMAS Audit with Audit PA not installed
> 23:06:57 BEEBEB70 NMAS: NMAS Audit with XDAS not installed
> 23:06:57 BEEBEB70 NMAS: ERROR: -1658 Failed set distribution password
> for tg.xx.xx
>
> 13. I have then tried your tool geofcc and it outputs:
>
> Password: Entry has no Universal Password value (-16049)
> Password policy assigned to user: cn=POL-PWD-ITQ,cn=Password
> Policies,cn=Security
> Does Current password meet password policy assigned to user? NMAS
> Return Code (-1665)
> ===> Password Status <===
> ==> Universal Password <==
> Is UPwd Enabled: true
> Is the UPwd history full: false
> Does UPwd match NDSPwd: false
> Does UPwd match SimplePwd: false
> Is UPwd older than NDSPwd: true
> ==> Simple Password <==
> Is Simple Password Set: false
> Is Simple Password Clear Text: false
> Does Simple Password match NDSPwd: false
> ==> Account Status <==
> Is Entry Account Disabled: FALSE
> Is Account Intruder Locked: FALSE
> Password Expiration Time: 20130825210657Z
> Grace Logins Remaining: 6
> Login Time: 20130527212541Z
>
> My head hurts!


So the UP is broken. 16049 usually means no UP set. 1665 is a new one
for me, and it says:

-1665 0xFFFFF97F NMAS_E_LOGIN_ATTRIBUTE_NOT_FOUND The login secret for a
particular login method is not available; for example, password not set,
fingerprint or biometric data not available.

(From this page: http://www.novell.com/support/kb/doc.php?id=3987489 )

So it says the secrets are broken.

Also this line:
Is UPwd older than NDSPwd: true
suggests that Client32 sans NMAS was used to set a password. I.e. NDS
password is newer than UP.

I think clearing the 4 sasLogin* attributes should help here, but I
forget if you tried that with any success.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDir to eDir - Unable to set NMAS password


I just removed the 4 sasLogin attributes in one tree, and at the same
time removed the 2 of them in the other tree, since only the SAS:Login
Configuration and SAS:Login Configuration Key were the ones present(the
tree where the UA is not connected). It seems like the problem is now
fixed! I tried this earlier, but I think I only removed them in one
tree, then tried to change the password. Then remove them in the other
tree and tried to change the password. It makes sense that they should
be removed from both trees before attempting to change it. I will have
to wait till tomorrow to see if the password is correct in the rest of
the systems he uses, but I suspect all will be good! Thank you very
much!(!!!!!!)

Jacob.


--
jacmarpet
------------------------------------------------------------------------
jacmarpet's Profile: https://forums.netiq.com/member.php?userid=415
View this thread: https://forums.netiq.com/showthread.php?t=47837

0 Likes
Knowledge Partner
Knowledge Partner

Re: eDir to eDir - Unable to set NMAS password

On 5/28/2013 6:44 PM, jacmarpet wrote:
>
> I just removed the 4 sasLogin attributes in one tree, and at the same
> time removed the 2 of them in the other tree, since only the SAS:Login
> Configuration and SAS:Login Configuration Key were the ones present(the
> tree where the UA is not connected). It seems like the problem is now
> fixed! I tried this earlier, but I think I only removed them in one
> tree, then tried to change the password. Then remove them in the other
> tree and tried to change the password. It makes sense that they should
> be removed from both trees before attempting to change it. I will have
> to wait till tomorrow to see if the password is correct in the rest of
> the systems he uses, but I suspect all will be good! Thank you very
> much!(!!!!!!)


Generally, you need to clear the attributes in the tree with the
problem. I rarely see the need to clear both sets.

What is nice, is with that tool, you can script it, two lines, and %1 is
the CN you pass in.

So I can call my script.bat (or script.sh) as:
script geoffc

And it reports all the trees I have listed and configured, so I can see
on one page, the password stats of a user.


0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.