| vince,
i just got off a call, (and elevated it with an IPMT), where the
customer is running dunix v4.0b/c2 security, and decnet/osi v4.0a.
if we try to dlogin from another system, we get "remote node says
node unreachable" if we try a dlogin 0, we get dlogin timed out.
the daemon.log files shows the dnascd process craping out with
ex_tempfail and ex_dataerr. from history, we changed the user name
in the sesscion control application cterm from daemon to root.. low\
and behold, we can now dlogin into the system. same temporary fix as
before. the permanent fix about two years ago was a new libsecurity.so
file. looks like we might need another one..
john wieland
|
| John,
As I recall, the problem originally (a long time ago) was that
dnascd was actually core dumping because of a bug in the
security library. The library bug is supposed to be fixed now,
and unless you are actually getting core dumps I think this
is just a configuration issue. Deneen put an update in the
case, but basically you have to re-activate accounts after
turning on C2. That includes accounts used by dnascd.
Vince
|
| vince is right...
per the release notes... (like some of us ever read them, and we
should)
2.1 Using DECnet with Enhanced Security
If enhanced security is enabled on a system running
DECnet, users may no longer be able to log into that
system via dlogin . This is because enhanced security
expires all accounts when it is enabled, including the
daemon account, which is the default account used by
DECnet for remote logins. To re-enable dlogin, either
activate the daemon account by resetting the password
or change the default account on the "session control
application cterm" entity to an active account.
thanks vince..
jw
|