Help with Powergrid netd password validation
Bert de Nooij
bert.dn@arma.nl
Wed, 17 Feb 1999 09:18:51 +0100
Larry,
It's a long time since I worked with PH client and Powergrid, but there a
few issues I can remember (because it cost me so much time to find them)
One of them was that Powergrid does not handle the Unix password
dynamically. When changing the (Unix) user password, powergrid does not
recognize the password change and (only) the old password is valid .
Solution is to restart the netd process
Another thing is that powergrid is rather critical with the file ownership
and protection. All powergrid files should have owner root and all
directories should be open for owner, group and others (**x**x**x)
Hope this helps
Regards,
Bert de Nooij
Arma BV
-----Oorspronkelijk bericht-----
Van: Larry Shurr [SMTP:lshurr@yahoo.com]
Verzonden: dinsdag 16 februari 1999 22:58
Aan: powerh-l@lists.swau.edu
Onderwerp: Help with Powergrid netd password validation
I'm serving as Unix system administrator for a Sun
Solaris system on a project for a client using
Powerhouse & Sybase. I've been dropped into this
situation without prior experience with Powerhouse
and Powergrid, and I am struggling to acquire the
knowledge I need to get things working. We have a
client system, a Windows for Workgroups (yeah,
it's an *old* app) and Visual Basic, with an app
which connects to Cognos via the Powergrid Network
Daemon (netd) running on the Sun. On the Windows
side you enter a user id and password, and, if it
works, you are in an application with many screens
and options, but if it doesn't (and it doesn't on
our development system), you are informed that the
login/password is invalid.
On the Sun/Solaris side, if you inspect the
cognos.log (attached), you see a certain amount of
interaction with the client, and then the messages:
CREATETASK: Start 'PHSRVN12' as user 'ded_us88'
CREATETASK: Password invalid
STATUS: *NETD Task Table is Empty*
(ded_us88 is a Solaris username, it and the password
are specified in a dialogue box on the Windows sys...
and, yes, it is the correct password). The assistance
I have received from our client has been pathetic...
The so-called Subject Matter Expert said I just needed
to be running nis+, so I set that up and it is working
normally -- no problems there, but it doesn't help.
The SME does not know what, if anything, is missing.
I have also run netd using truss to try to get some
visibility into this problem, and this is what I
found which appears to be relevant:
337: C R E A T E T A S K : S t a r t ' P H S R V N 1 2 ' a s
337: u s e r ' d e d _ u s 8 8 '\n
337: door_info(7, 0xDFFFF608) = 0
337: door_call(7, 0xDFFFF6A0, 0x00000400, 0x0000008C, 0x00000000) = 0
337: write(3, 0x0005905C, 29) = 29
337: C R E A T E T A S K : P a s s w o r d i n v a l i d\n
337: waitid(P_ALL, 0, 0xDFFFFA90, WEXITED|WTRAPPED|WNOHANG) Err#10
ECHILD
337: write(3, 0x0005905C, 35) = 35
337: S T A T U S : * N E T D T a s k T a b l e i s E m
p t
337: y *\n
As you can see, the attempt to run PHSRVN12 appears
to uses door_call(), a not-particularly-well-
documented RPC interface. The door_call() apparently
"works" because it returns a zero, suggesting that
the "remote" host receives the message and the server
calls door_return() to reply with the "password
invalid" status.
As you can see, I have little visibility into what's
going on here, so I'm looking for a clue or two.
I've noticed, for example, that PHSRVN12 is a pro-
gram supplied with Powergrid and the strings command
shows that it contains a number of instances of the
word "password", but nothing that really tells me
what it's doing. This may mean that the password
which is invalid is not necessarily the Unix login
password (which has already been demonstrated to be
valid on the Sun system). I've assumed that the
"remote" host (the target) for the door_call() is
also the host which is originating the call, but I
have nothing that actually tells me so.
I found a workaround which gets things working on
a provisional basis. I set the "-s" (disable
security) option on netd and I start netd as user
ded_us88. In this scenario, you still have to
fill in the login dialogue on the Windows machine,
but netd ignores it and everything seems to run
just fine.
As you can see, I'm wandering around in the
wilderness here, with a fragmentary understanding
of what's going on and I could do with some expert
direction. Please help.
Regards,
Larry
--------attached-----------------attached---------
ntSupplierAccept: Waiting for CONNECT on socket #8
ntSupplierAccept: Accepted connection on socket #11
cxdrnet_open: Using STREAM protocol
cxdrnet_reopen: Open DECODE stream over port (IS#11)
cxdrnet_read: Waiting for PDU Header
ntStreamReceive: Waiting on socket #11
ntStreamReceive: Read 4 bytes on socket #11
sdcxdrnet_read: Waiting for 106 byte EOT PDU
ntStreamReceive: Waiting on socket #11
ntStreamReceive: Read 106 bytes on socket #11
cxdrnet_read: Decrypt 106 bytes (expected checksum = 112)
cxdrmem_getlong: Read 0x3
cxdrmem_getlong: Read 0x40447
cxdrmem_getlong: Read 0x10000
cxdrmem_getlong: Read 0x106
cxdrmem_getlong: Read 0x8b7
cxdrmem_getlong: Read 0xa2f014d
cxdrmem_getshort: Read 0x0
nkInvoke: Request from [IN.10.47.1.77#0@2231] (reply required)
nkInvoke: Match found with API #1 "netx"
nkInvoke: Using API "netx" to call FUNCTION "createInitTask"
nkInvoke: Allocate Parm #1 (4 FAR DYNAMIC bytes)
cxdrmem_getshort: Read 0x0
cxdrmem_getlong: Read 0x8
cxdrmem_getchars: Read 8 chars
cxdrmem_getchars:
000603d0: 50 48 53 52 56 4e 31 32 PHSRVN12
nkInvoke: Allocate Parm #2 (4 FAR DYNAMIC bytes)
cxdrmem_getshort: Read 0x1
cxdrmem_getlong: Read 0x8
cxdrmem_getchars: Read 8 chars
cxdrmem_getchars:
000603e8: 50 48 49 4e 49 54 31 32 PHINIT12
nkInvoke: Allocate Parm #3 (4 FAR DYNAMIC bytes)
cxdrmem_getshort: Read 0x2
cxdrmem_getlong: Read 0xc
cxdrmem_getchars: Read 12 chars
cxdrmem_getchars:
00060400: 63 6f 67 5f 73 74 61 72 74 2e 73 68 cog_start.sh
nkInvoke: Allocate Parm #4 (4 FAR DYNAMIC bytes)
cxdrmem_getshort: Read 0x3
cxdrmem_getlong: Read 0x8
cxdrmem_getchars: Read 8 chars
cxdrmem_getchars:
00060418: 64 65 64 5f 75 73 38 38 ded_us88
nkInvoke: Allocate Parm #5 (4 FAR DYNAMIC bytes)
cxdrmem_getshort: Read 0x4
cxdrmem_getlong: Read 0x6
cxdrmem_getchars: Read 6 chars
cxdrmem_getchars:
00060b08: xx xx xx xx xx xx xxxxxxx
nkInvoke: Allocate Parm #6 (4 FAR STATIC bytes)
nkInvoke: Allocate Parm #7 (4 FAR STATIC bytes)
CREATETASK: Start 'PHSRVN12' as user 'ded_us88'
CREATETASK: Password invalid
STATUS: *NETD Task Table is Empty*
cxdrnet_reopen: Open ENCODE stream over port (IS#11)
cxdrmem_putlong: Write 0x40000
cxdr_NP_REPLY_HEADER: Encode 0 signals
cxdrmem_putlong: Write 0x0
cxdrmem_putshort: Write 0x5
cxdrmem_putlong: Write 0x0
cxdrmem_putshort: Write 0x6
cxdrmem_putlong: Write 0x32
cxdrnet_write: Send EOT buffer (28 bytes)
ntStreamSend: Sending 28 bytes on socket #11
cxdrnet_close: Close stream over port (IS#11).
ntSockClose: Close port (IS#11)
nkInvoke: Release Parm #1
nkInvoke: Release Parm #2
nkInvoke: Release Parm #3
nkInvoke: Release Parm #4
nkInvoke: Release Parm #5
ntSupplierAccept: Waiting for CONNECT on socket #8
--------attached-----------------attached---------
==
Larry A. Shurr (lshurr@yahoo.com)
A Keane, Inc. consultant. Stay tuned for @keane.com address.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.