Conference tuxedo::dce-products

	
	The machine in qu has the following details:



# uname -a
OSF1 <name> V3.2 62 alpha


# setld -i | grep DCE | grep insta
DCEADK133       installed       DCE Application Dev Kit V1.3b
DCEADKMAN133    installed       DCE Application Developers Manual Pages V1.3b
DCECDS133       installed       DCE CDS Server V1.3b
DCERTS133       installed       DCE Runtime Services V1.3b
DCESEC133       installed       DCE Security Server V1.3b

>		Verify that no other rpcd/llbd is running: (0x16c9a003)
>		Can not bind socket (dce/rpc)

 I've seen this same error when configuring on system's using certain CAD
 packages. There is a conflict between the rpcd port number and another
 listener. You need to check to see if the SLIP configuration uses the
 same port (TCP socket) as rpcd. If it does then you need to change the SLIP
 port number.


>	When trying to start them, the error code 387063936 is seen.

>	What does this code mean ? - Infact, what do all the series
>	of 387.... errors mean - I only know of DCE errors that begin
>	with 282....

  Invalid password ( dce / sec )

  I would check the key table (ktlist) to make sure that the passwords are
  in the table properly and the permissions on the file.

  Does this happen for applications or the DCE components? 

	

		

Re -.1


Thanks for ya reply... here's some answers & more qu's




>> same port (TCP socket) as rpcd. If it does then you need to change the SLIP

	
	From /etc/services, rpc entry is:

		
		courier         530/tcp         rpc

	
	so, I can just pick another number in the 500's,  which isn't in 
	use already - correct ?


	
>> I would check the key table (ktlist) to make sure that the passwords are
>>  in the table properly 


	How is that done?



>>	and the permissions on the file.


	Where is the default keytable file on D/Unix ?




>> Does this happen for applications or the DCE components? 

	Application servers





	
Thx,

	Craig.

	HELP !!!

	All keytable files are owned by root, with "rw" to root
	only.

	Are there any known clashes between DCE & any other 
	products?

	What entries & socket number does DCE use ????

	DCE does start - by deregistering the SLIP stuff we are
	past that problem for the meantime, but still can't 
	authenticate  !!!!

	Are there any trace env vars I can set before starting 
	my application svr that can tell me why I get invalid
	password ?

	We are getting desperate - the customer has reached the
	"drop dead date, TODAY!" 

	** PLEASE GIVE ANY SUGGESTIONS YOU CAN ***

	Here's a trace of the server staring:

SI API: Informational message from SI API
        0, ZAP_IMS_NAMEDQ=ZCS_RESSVR_500_1
        ../../../base/api/src/zap.c, 234
SI API: Informational message from DCE
        387063936, Invalid password (dce / sec)
        ../../../base/api/src/zapauthn.c, 457
/usr/bin/zcs_ressvr: Authentication of principal failed
zap_dcePasswordIncorrect


	(It uses DECmessageQ & MSG+ (formerly "IMS") &
	was working in the customers env. previously. now
	it just wont start and we have no idea why.


	THanks  !

	Craig.	
	

	

>	All keytable files are owned by root, with "rw" to root
>	only.

        Applications should use their own key tables.

        Temporarily, you can drop the permissions to allow the
        application to access the key table. This will at least
        let you know if the password is in the file.

        rgy_edit ktlist -f <KEY TABLE FILE NAME>

        The above command will list the keys in a specific
        key table.

        If you can redirect the application server to use another key
        table then you can create a key table specifically for it.
        Just remember that the file permissions need to be such that
        the server's principal which is NOT root can access the file.
        (This is from the operating system perspective.)

	Also, you need to check to make sure that the current password
	for the principal is actually in the table. Normally servers
	will maintain their passwords via a separate thread which
	will change the password to some unknown value just before it
	expires. Could this be the problem?

>	Are there any known clashes between DCE & any other 
>	products?

	The one that I know of is GeoMod from SDRC which uses the
	same port number as rpcd.

>	What entries & socket number does DCE use ????

>	DCE does start - by deregistering the SLIP stuff we are
>	past that problem for the meantime, but still can't 
>	authenticate  !!!!

	see above. This sounds like an administration problem.

>	Are there any trace env vars I can set before starting 
>	my application svr that can tell me why I get invalid
>	password ?

	Did they add the servicability calls to their code? If not,
	then they could simply put in the debug statements in
	login part of the server's code to see what errors messages
	that they get.

	For example, did they get an error when they tried to open the 
        key table? Did they ingore it anyway and continued with the code?
 

	Also, try resetting the server's principal and then put the new
	password into the key table. 

	rgy_edit ktadd -p <principal> -pw <password> -f <KEY TABLE FILE NAME>	

    Let me make sure I understand the problem:
    
    1) You've identified a conflict between DCE's secd and SLIP in that
    they both want to use port 530, and you've changed the SLIP
    configuration to use some other port.  Now secd starts.  However, now
    you have a different problem:
    
    2) Any application server that uses a keytable fails with an invalid
    password error, but you can invoke dce_login succesfully.
    
    If that's right, then it sounds as if your keytable file(s) are either
    inaccessible, corrupt, or contain expired passwords.  You say they're
    all rw to root - do the application servers run as root (they need to
    be able to at least read these files)?  If so, try using ktlist  to see
    what's in one of them:
    
    % dce_login cell_admin <cell_admin-passwd>
    % rgy_edit
    rgy_edit=> ktlist -f <keytable-file>
    
    If the server's principal name isn't listed, that's your problem.  If
    it is, then possibly either the key has expired, or it's been changed
    in the registry but the keytable hasn't been updated to match.
    
    Look at the server principal account in the registry to verify that it
    hasn't expired:
    
    rgy_edit=> do acc
    Domain changed to: account
    rgy_edit=> vi <server-account> -f
    <server-account> [<server-group> <server-org>]:*:<gid>:<uid>::/::
      created by: /.../<cell>/cell_admin  <creation-date>
      changed by: /.../<cell>/<someone> <modification-date>
      password is: valid, was last changed: <pwd-change-date>
      Account expiration date: none
      Account MAY be a server principal
      Account MAY be a client principal
      Account is: valid
      Account CAN NOT get post-dated certificates
      Account CAN get forwardable certificates
      Certificates to this service account MAY be issued via TGT authentication
      Account CAN get renewable certificates
      Account CAN NOT get proxiable certificates
      Account CAN NOT have duplicate session keys
      Good since date: <date>
      Max certificate lifetime: default-policy
      Max renewable lifetime: default-policy
    
    Verify that both the password and the account are listed as valid, and
    that the password hasn't been changed since the last time the keytable
    file was modified.
    
    If the password has been changed and the keytable file hasn't, that's
    your problem, and you need to find out how it happened (maybe the
    server is changing its own password in the registry, but not updating
    the keytable, or maybe someon manually changed the server's password
    and forgot to update the keytable).  You can fix things as follows:
    
    rgy_edit=> do acc
    Domain changed to: account
    rgy_edit=> c -p <server-account> -pw <new-password> -mp <cell_admin-passwd>
    rgy_edit=> ktadd -p <server-account> -pw <new-password> -f <keytable-file>
    rgy_edit=> ktadd -p <server-account> -r -a -f <keytable-file>
    
    The first command sets the server's password in the registry to
    <new-password>.  The second sets the password in the keytable file to
    the same.  The third command changes both registry and keytable copies
    to a new random password.
    
    John

>    Let me make sure I understand the problem:
>    
>    1) You've identified a conflict between DCE's secd and SLIP in that
>    they both want to use port 530, and you've changed the SLIP
>    configuration to use some other port.  Now secd starts.  However, now
>    you have a different problem:
    

	For the moment SLIP is out of the equasion 'cause it's deconfigured.
	The additon of SLIP is about the time things went bad. A few subsets
	called:


IAEBASE300      installed       Internet AlphaServer Administration Base System
subset
IAFWAPCH300     installed       Public Software Apache WWW server V1.0.5 subset
IAFWBASE300     installed       Internet AlphaServer Public Software Base System

	where also installed. Not sure if they cause any clashing.



>    2) Any application server that uses a keytable fails with an invalid
>    password error, but you can invoke dce_login succesfully.
    

		This is correct !


>    If that's right, then it sounds as if your keytable file(s) are either
>    inaccessible, corrupt, or contain expired passwords.  You say they're
>    all rw to root - do the application servers run as root (they need to
>    be able to at least read these files)?  If so, try using ktlist  to see
>    what's in one of them:
> 
>    % dce_login cell_admin <cell_admin-passwd>
>    % rgy_edit
>    rgy_edit=> ktlist -f <keytable-file>
    
>    If the server's principal name isn't listed, that's your problem.  If
>    it is, then possibly either the key has expired, or it's been changed
>    in the registry but the keytable hasn't been updated to match.

		The servers all run as root. The files appear to be OK
		ktlist -f <file> gave the expected output.
    
    
>    Look at the server principal account in the registry to verify that it
>    hasn't expired:
>    rgy_edit=> do acc
>    Domain changed to: account
>    rgy_edit=> vi <server-account> -f
>    <server-account> [<server-group> <server-org>]:*:<gid>:<uid>::/::
>      created by: /.../<cell>/cell_admin  <creation-date>
>      changed by: /.../<cell>/<someone> <modification-date>
>      password is: valid, was last changed: <pwd-change-date>
>      Account expiration date: none
>      Account MAY be a server principal
>      Account MAY be a client principal
>      Account is: valid
>      Account CAN NOT get post-dated certificates
>      Account CAN get forwardable certificates
>      Certificates to this service account MAY be issued via TGT authentication
>      Account CAN get renewable certificates
>      Account CAN NOT get proxiable certificates
>      Account CAN NOT have duplicate session keys
>      Good since date: <date>
>      Max certificate lifetime: default-policy
>      Max renewable lifetime: default-policy
>
>    Verify that both the password and the account are listed as valid, and
>    that the password hasn't been changed since the last time the keytable
>    file was modified.


		THe password & accounts for the 2 principals are valid.
	

		All dates/times matched exactly beteen kt files, the 
		account dommain, etc.

>
>    rgy_edit=> do acc
>    Domain changed to: account
>    rgy_edit=> c -p <server-account> -pw <new-password> -mp <cell_admin-passwd>
>    rgy_edit=> ktadd -p <server-account> -pw <new-password> -f <keytable-file>
>    rgy_edit=> ktadd -p <server-account> -r -a -f <keytable-file>
>    

		After adding the -g <group> & -o <org> to the "change"
		line above, this set of commands for the 2 pricipals fixed 
		the problems.. ir: the servers did start!

		Problem is we don't know why it's fixed now. THe install'n
		of the application servers does create the ktable entries,
		and set random passwords on them.

		I've asked the customer to do a re-install'n of the 
		application. The deinstall should delete the k/tables,
		the principals and accounts. The install will re-create
		them. We had done this several times already though.

		I'll keep ya posted...

		

	Thanks for ya help so far !


	Craig Thoman
	Systems Integration Engineering (Australia)
 
		 
		

          
	A product called DECmessageQ had been configured to use 
	port 500 by the customer. They were not aware that, as
	a general rule, values below 1024 are "reserved". After
	selecting a new value, the keytable passwords are now 
	bing accepted. I don't know if this is conincience or 
	not (I'm about to try it on a DEC target machine myself).
	Are you aware of DCE's use of port 500 ?

	Note that at the stage we've been at with this problem
	it has been only a 1 node cell. Hence I personally wouldn't
	expect any calls being made, but thats your territory.


	Thx

	Craig.

	So, we've established that RPC  uses 135.
	Pg 1-3 of a one of ya DCE doc's says:

		DDS uses port 12
		DECnet uses 69

	any others ?


	Thx

	Craig.

	Thx

	Craig.

>	any others ?

	i looked at some of the modules, it looks like they're using
	dynamic endpoints. if you use rpccp show mapping, you can see the
	endpoints. i also looked at some of the source code as well, they're
	using the standard call to rpc_ep_register after getting bindings
	from the runtime.

garry

	(that's in the R1.0.3 code base)