Sk,
Another possibility... it could be the perceived name of the remote user has changed, rather than the proxy itself. This can depend on a DNS definition.
What you need to work out is the perceived name for the incoming node.
From a privileged session on the target node, make sure LOGFAIL audits are enabled and enable your terminal for SECURITY audits. Now SET HOST from the failing system and enter username/password TEST/TEST (assuming they don't exist!). In the resulting audit alarm, look at the "Remote node fullname:". You may find it listed as something like
"LOCAL:.NODE" for a name resolved from the local DNS, "DOMAIN:.NODE" if resolved from an external domain. Or, it could be an IP style address "NODE.DOMAIN.NET" or even as a raw numeric address "IP$12.34.56.7"
DECnet proxies are pretty dumb. They just take whatever string "Remote node fullname:" translates to and use that to look up the proxy data base - direct string comparison. You need to confirm that the *string* in the proxy record matches whatever the node translates to. The important thing to remember is the DNS name could change, but the *string* in the proxy data base won't change.
In some volatile environments it may be necessary to define several possible proxy records for a particular node. You can argue about how the implementation *might* have been done, but it's not going change, so learn to live with it!
>Is there any way to find out the changes made to proxy database.
Assuming you have AUTHORIZATION audits enabled, there will be events in your security journal "Network proxy record mofification", "Network proxy record deletion" and "Network proxy record addition", which should record exactly what was changed, when and by whom.
If you can't work out the ANALYZE/AUDIT syntax to extract just the UAF audits, use the big hammer:
$ ANALYZE/AUDIT/FULL/SINCE=date-time/OUT=AUD.TXT SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$ SEARCH AUD.TXT proxy/WINDOW=20
A crucible of informative mistakes
