Any ideas why some boxes/domains would get "access denied" on nmConnect?

Question

I have four boxes running NodeManager, with 2-3 domains on each box. I want to be able to use WLST to connect to the NodeManager on each box, to perform certain operations. On each box, I've created each domain using the same process (it's entirely possible I missed a step somewhere). The application deployed to each of these domains (the same application is deployed) appears to be working ok. The admin console also works perfectly fine. I can stop and start managed servers from the console.
I execute wlst on each box exactly the same way. At each prompt, I enter a fully-qualified "nmConnect()" call, specifying the user, pwd, machine, nmport, domain name, domain path, and "ssl". I've verified all of these field values (like the password) many times. On all but one of these boxes, the result of this call is:
Traceback (innermost last):
File "<console>", line 1, in ?
File "<iostream>", line 1379, in nmConnect
WLSTException: "Error occured while performing nmConnect : Cannot connect to Node Manager.Access to domain '<domain name>' for user 'weblogic' denied Use dumpStack() to view the full stacktrace"
I've carefully examined any meaningful differences between these domains, and I can't see anything that might cause this. Of the four domains, two of them are in production mode, and the other two are not. The only one that does not fail the connection is not in production mode (but note that the other that is not in production mode also fails).
What else could be the cause of this?

Answer 1

At first I thought this was working fine. It now works fine from WLST. Unfortunately, the admin console now fails to see the nodemanager. I even tried restarting the admin server. No luck.
I then copied back the old nm_password.properties file (I made a backup first) and now WLST fails, but the admin console can see the nodemanager, so it's back to where it was.
What's curious is that the contents of the properties file after wlst hashed it was different from the original hashed value, and the wlst-hashed value was very odd. The original hashed value ended with "0\=" at the end of the line. After I replaced the "hashed" property with the cleartext properties "username" and "password" and then ran wlst, the new contents of the "hashed" property was in TWO lines, where the first line ended with "0\=" as before, but the next line contained the last five characters of the password value that I entered. I tried this on three different boxes, and the behavior was the same, with respect to the odd hashing.