| Title: | DCE Product Information |
| Notice: | Kit Info - See 2.*-4.* |
| Moderator: | TUXEDO::MAZZAFERRO |
| Created: | Fri Jun 26 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2269 |
| Total number of notes: | 10003 |
We are experiencing login failures involving the TASK object on our system and this seems to be coming from the RPC daemon. I am seeing this on OpenVMS VAX(6.2) and Alpha(7.0) and have upgraded to DCE V1.4. The login failures cause the system account to be locked out and this in turn adversly affects NMail, so we would like to get the problem resolved. I have found that I can provoke this running and then terminating our debug server that establishes itself as an RPC end point (you'll have to excuse my terminology, I'm only just getting in to this!). $ run debugshr %DEBUG-I-SPEAK: TCP/IP: YES, DECnet: YES, UDP: YES %DEBUG-I-WATCH: Network Binding: ncacn_ip_tcp:16.32.16.145[3798] %DEBUG-I-WATCH: Network Binding: ncacn_dnet_nsp:63.436[RPC2C4001590001] %DEBUG-I-WATCH: Network Binding: ncadg_ip_udp:16.32.16.145[1076] %DEBUG-I-AWAIT: Ready for client connection... CTRL/Y $ exit $ Some time later (from 3 to 30 minutes I have observed) we start to get login failures on the task object, these seem to be originating from the RPC daemon. I turned on auditing of network connections and you will notice that the "object name" in the connection event is the same as in the network bindings as printed by the debug server - RPC2C4001590001. It seems we get 20 of these login attempts spaced at roughly one minute intervals. This is enough for VMS to go into breakin evasion mode and lock out the account from this source. %%%%%%%%%%% OPCOM 7-MAY-1997 16:19:48.52 %%%%%%%%%%% (from node MAWK at 7-MAY-1997 16:19:48.12) Message from user AUDIT$SERVER on MAWK Security alarm (SECURITY) on MAWK, system id: 64948 Auditable event: DECnet logical link created Event time: 7-MAY-1997 16:19:48.07 PID: 2C400194 Process name: NET_8283 Username: DECNET Process owner: [1,3] Remote nodename: MAWK Remote node id: 64948 (63.436) Remote username: SYSTEM DECnet logical link ID: 8283 DECnet object name: RPC2C4001590001 DECnet object number: 0 Remote logical link ID: 8282 Status: %SYSTEM-S-NORMAL, normal successful completion %%%%%%%%%%% OPCOM 7-MAY-1997 16:19:48.75 %%%%%%%%%%% (from node MAWK at 7-MAY-1997 16:19:48.34) Message from user AUDIT$SERVER on MAWK Security alarm (SECURITY) and security audit (SECURITY) on MAWK, system id: 64948 Auditable event: Network breakin detection Event time: 7-MAY-1997 16:19:48.31 PID: 2C400194 Process name: NET_8283 Username: ILLEGAL Remote nodename: MAWK Remote node id: 64948 (63.436) Remote username: SYSTEM Status: %LOGIN-F-NOSUCHUSER, no such user
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2247.1 | More info | STAR::SWEENEY | Wed May 14 1997 10:35 | 9 | |
Did this ever work and if so, in what configuration? The process NET_8283 is generating the login failures not DCE$RPCD, so how did you reach the conclusion that the RPC daemon is generating the login failures? Are you sure your integrated login environment is set up correctly? Check out the OpenVMS DCE product guide, chapter seven for a description of how the DCE principal, DCE UAF and OpenVMS files need to be set up. If you think it is set up correctly, please provide listings of the OpenVMS account, the DCE principal and the DCE$UAF account/principal information. Dave | |||||
| 2247.2 | more details | SSPADE::HIDER | Paul Hider, DTN 381-2251 | Wed May 14 1997 14:03 | 63 |
Thanks Dave,
The client/server software that is using RPC is working fine. The problem
is that we have had this "mysterious NMail" problem for more than six months
and have finally tracked it down to a side effect of using RPC. Since the
software appears to be working fine you don't really notice the problem until
you turn on the operator log and start seeing the login failures.
The NET_8283 process is not the source, but rather the target of the
network connection that fails. Unfortunately I have not been able to
persuade VMS to identify the process that made the network connection,
but I have a clue in the line
DECnet object name: RPC2C4001590001
as this matches the data that our server printed out as one of its
RPC bindings
%DEBUG-I-WATCH: Network Binding: ncacn_dnet_nsp:63.436[RPC2C4001590001]
This would suggest the RPC daemon, or other DCE component, as the source.
I didn't do the initial DCE installation, nor did I write the client/server
code, but I am trying to come up to speed on it. We are using unauthenticated
RPC at the moment, so the integrated login components are not configured:
$ @sys$manager:dce$setup show
**************************** INFO *****************************
*** DCE is configured to support 70 DCE Processes
This system has the following DCE configuration:
Hostname: mawk
Remote Procedure Call Services SubsetEnabled
Security Services Disabled
CDS Name Service Disabled
PC Name Service Interface Disabled
Distributed Time Service Disabled
Integrated login Disabled
This system supports the following network transport protocols:
TCP/IP: [ncacn_ip_tcp]
UDP/IP: [ncadg_ip_udp]
DECnet: [ncacn_dnet_nsp]
TCP/IP services on this system are provided by: UCX
TCP/IP Services for OpenVMS
Based on this configuration, the following DCE daemons should be active:
Daemon Process Name Process ID
Remote Procedure Call Services DCE$RPCD 2C4001D6
*** DCE System Management Procedure Complete ***
Thanks for your help, Paul.
| |||||
| 2247.3 | SSPADE::HIDER | Paul Hider, DTN 381-2251 | Wed May 21 1997 15:20 | 6 | |
Are there any suggestions for resolving this?
Or is there any other information I can give you that would help?
Thanks, Paul
| |||||